diff --git a/public/content/translations/ur/about/index.md b/public/content/translations/ur/about/index.md new file mode 100644 index 00000000000..4a850c70921 --- /dev/null +++ b/public/content/translations/ur/about/index.md @@ -0,0 +1,134 @@ +--- +title: "ہمارے بارے میں" +description: "ethereum.org کی ٹیم، کمیونٹی اور مشن کے بارے میں" +lang: ur-in +--- + +# ethereum.org کے بارے میں {#about-ethereumorg} + +ethereum.org ایتھیریم کمیونٹی کے لیے ایک عوامی، اوپن سورس وسیلہ ہے جس میں کوئی بھی حصہ ڈال سکتا ہے۔ ہمارے پاس ایک چھوٹی کور ٹیم ہے جو دنیا بھر کے ہزاروں کمیونٹی ممبران کے تعاون سے سائٹ کو برقرار رکھنے اور اسے تیار کرنے کے لیے وقف ہے۔ + +**ethereum.org سے کوئی بھی آپ سے کبھی رابطہ نہیں کرے گا۔ جواب نہ دیں۔** + +## ناموں پر ایک نوٹ {#a-note-on-names} + +ایتھیریم کے منظر نامے میں لوگوں کا ناموں کے بارے میں الجھن میں پڑنا عام بات ہے، جو اس بارے میں ناقص ذہنی ماڈل کا باعث بن سکتا ہے کہ ایتھیریم کیسے کام کرتا ہے۔ چیزوں کو واضح کرنے کے لیے یہاں ایک فوری وضاحت کنندہ ہے: + +### ایتھیریم {#ethereum} + +ایتھیریم ایک عوامی نیٹ ورک، ایک بلاک چین، اور ایک اوپن سورس پروٹوکول ہے -- جسے دسیوں ہزار ڈیولپرز، نوڈ آپریٹرز، ETH ہولڈرز اور صارفین کی عالمی برادری کے ذریعے چلایا، منظم، اور ملکیت میں رکھا جاتا ہے۔ + +[ایتھیریم کے بارے میں مزید](/what-is-ethereum/) + +[Ethereum governance کے بارے میں مزید](/governance/) + +### ایتھر (ETH) {#ether-or-eth} + +ایتھر (جو اس کے ٹکر کی علامت، ETH سے بھی جانا جاتا ہے) ایتھیریم پر لین دین کی جانے والی مقامی کرنسی ہے۔ ایتھیریم نیٹ ورک کے استعمال کی ادائیگی کے لیے (ٹرانزیکشن فیس کی شکل میں) ETH کی ضرورت ہے۔ ETH کا استعمال اسٹیکنگ کے ساتھ نیٹ ورک کو محفوظ بنانے کے لیے بھی کیا جاتا ہے۔ جب لوگ ایتھیریم کی قیمت کے بارے میں بات کرتے ہیں، تو وہ اثاثہ ETH کا حوالہ دے رہے ہوتے ہیں۔ + +[ETH کے بارے میں مزید](/what-is-ether/) + +[ETH کی اسٹیکنگ پر مزید](/staking/) + +### ایتھیریم فاؤنڈیشن {#ethereum-foundation} + +ایک غیر منافع بخش تنظیم، جو ابتدائی طور پر ETH کی کراؤڈ سیل کے ذریعے فنڈ کی گئی تھی، ایتھیریم نیٹ ورک اور ایکو سسٹم کی مدد کے لیے وقف ہے۔ + +[ایتھیریم فاؤنڈیشن کے بارے میں مزید](/foundation/) + +### ethereum.org {#ethereum-org} + +ایتھیریم کمیونٹی کے لیے ایک عوامی، اوپن سورس ویب سائٹ اور تعلیمی وسیلہ۔ ethereum.org کی قیادت ایک چھوٹی کور ٹیم کرتی ہے، جسے ایتھیریم فاؤنڈیشن نے فنڈ دیا ہے، جس میں دنیا بھر کے ہزاروں کمیونٹی ممبران کا تعاون شامل ہے۔ + +یہ صفحہ ethereum.org کے بارے میں مزید معلومات کا احاطہ کرتا ہے۔ + +## ہمارا مشن {#our-mission} + +**ethereum.org کا مشن ایتھیریم کی بڑھتی ہوئی کمیونٹی کے لیے بہترین پورٹل بننا ہے** + +ہم ایتھیریم سے متعلق تمام موضوعات کے لیے سمجھنے میں آسان تعلیمی وسیلہ بنانے کی کوشش کرتے ہیں، جو نئے صارفین کو ایتھیریم اور اس کے کلیدی تصورات سے واقف ہونے میں مدد کرنے کے لیے ڈیزائن کیا گیا ہے۔ ہم چاہتے ہیں کہ: + +- ٹیکنالوجی سے ناواقف کسی بھی شخص کو ایتھیریم کی وضاحت کریں +- نئے صارفین کو ETH اور ایتھیریم کے ساتھ شروعات کرنے میں مدد کریں +- نئے ڈیولپرز کو تعمیر شروع کرنے میں مدد کریں +- ایتھیریم کی دنیا میں اپ ڈیٹس کا احاطہ کریں +- کمیونٹی کے ذریعہ بنائے گئے وسائل کی نمائش کریں +- ایتھیریم کی تعلیم کو زیادہ سے زیادہ زبانوں تک پہنچائیں + +اس مشن کو حاصل کرنے کے لیے، ہماری ٹیم ethereum.org پر دو بنیادی اہداف پر توجہ مرکوز کرتی ہے: + +### 1۔ ethereum.org کے وزیٹرس کے لیے صارف کے تجربے کو بہتر بنائیں {#visitors} + +- مواد کو وسعت دیں، بہتر بنائیں، اور اپ ٹو ڈیٹ رکھیں +- لوکلائزیشن اور ویب ڈیولپمنٹ کے بہترین طریقوں کے ذریعے استعمال اور رسائی کو بہتر بنائیں +- سروے، کوئز، اور web3 انٹیگریشن جیسی خصوصیات کے ذریعے صارف کی مصروفیت میں اضافہ کریں +- ویب سائٹ کو ہلکا اور کارکردگی والا رکھیں + +### 2۔ ہمارے تعاون کنندگان کی کمیونٹی کو بڑھائیں، مضبوط کریں، اور بااختیار بنائیں {#community} + +- ویب سائٹ پر تعاون کنندگان کی کل تعداد میں اضافہ کریں +- مصروفیت، اعترافات، اور انعامات کے ذریعے تعاون کنندگان کو برقرار رکھنے میں بہتری لائیں +- کمیونٹی کے ممبران کو تیزی سے اہم شراکتیں کرنے کے لیے بااختیار بنائیں +- شراکتوں کے زیادہ تنوع کو آسان بنائیں: کوڈ، مواد، ڈیزائن، ترجمہ، اعتدال +- کوڈبیس کو جدید، صاف، اور اچھی طرح سے دستاویزی رکھیں + +## بنیادی اصول {#core-principles} + +ہمارے کچھ بنیادی اصول ہیں جو ہمارے مشن کو پورا کرنے میں ہماری رہنمائی میں مدد کرتے ہیں۔ + +### 1۔ ethereum.org ایتھیریم 🌏 کا ایک پورٹل ہے {#core-principles-1} + +ہم چاہتے ہیں کہ ہمارے صارفین کی دلچسپی بڑھے اور ان کے سوالات کے جوابات ملیں۔ لہذا ہمارے پورٹل کو معلومات، "جادوئی لمحات" اور وہاں موجود شاندار کمیونٹی وسائل کے لنکس کو یکجا کرنے کی ضرورت ہے۔ ہمارے مواد کا مقصد ایک "آن بورڈنگ پورٹل" بننا ہے نہ کہ پہلے سے موجود وسیع وسائل کا متبادل۔ ہم کمیونٹی کے بنائے ہوئے وسائل کی حمایت اور ان کے ساتھ مربوط ہونے کے خواہشمند ہیں، انہیں مزید مرئیت دیتے ہیں اور انہیں مزید قابل دریافت بناتے ہیں۔ +[ایتھیریم کی کمیونٹی](/community/) اس کے مرکز میں ہے: ہمیں نہ صرف کمیونٹی کی خدمت کرنے کی ضرورت ہے، بلکہ ان کے ساتھ کام کرنے اور ان کے تاثرات کو شامل کرنے کی بھی ضرورت ہے۔ ویب سائٹ صرف اس کمیونٹی کے لیے نہیں ہے جو ہمارے پاس ابھی ہے بلکہ اس کمیونٹی کے لیے بھی ہے جس میں ہم ترقی کی امید رکھتے ہیں۔ ہمیں یاد رکھنا چاہیے کہ ہماری کمیونٹی عالمی ہے، جس میں بہت سی زبانوں، علاقوں اور ثقافتوں کے لوگ شامل ہیں۔ + +### 2۔ ethereum.org ہمیشہ ترقی کر رہا ہے 🛠 {#core-principles-2} + +ایتھیریم اور کمیونٹی ہمیشہ ترقی کر رہے ہیں، لہذا ethereum.org بھی ترقی کرے گا۔ اسی لیے سائٹ کا ایک سادہ ڈیزائن سسٹم اور ماڈیولر ڈھانچہ ہے۔ جیسے جیسے ہم اس بارے میں مزید سیکھتے ہیں کہ لوگ سائٹ کا استعمال کیسے کرتے ہیں اور کمیونٹی اس سے کیا چاہتی ہے، ہم تکراری تبدیلیاں کرتے ہیں۔ +ہم اوپن سورس ہیں، تعاون کنندگان کی ایک کمیونٹی کے ساتھ، لہذا آپ بھی تبدیلیوں کی تجویز دے سکتے ہیں یا ہماری مدد کر سکتے ہیں۔ +[تعاون کے بارے میں جانیں](/contributing/) + +### 3۔ ethereum.org کوئی عام پروڈکٹ ویب سائٹ نہیں ہے 🦄 {#core-principles-3} + +ایتھیریم ایک بڑی چیز ہے: اس میں ایک کمیونٹی، ایک ٹیکنالوجی، نظریات اور آئیڈیالوجیز کا ایک مجموعہ، اور بہت کچھ شامل ہے۔ +اس کا مطلب ہے کہ ویب سائٹ کو بہت سے مختلف صارف کے سفر کو سنبھالنے کی ضرورت ہے، "ایک ڈیولپر جو ایک مخصوص ٹول چاہتا ہے" سے لے کر "ایک نیا آنے والا جس نے ابھی کچھ ETH خریدا ہے اور نہیں جانتا کہ والیٹ کیا ہے"۔ +"بلاک چین پلیٹ فارم کے لیے بہترین ویب سائٹ کون سی ہے؟" ایک کھلا سوال ہے - ہم سرخیل ہیں۔ اسے بنانے کے لیے تجربات کی ضرورت ہے۔ + +## پروڈکٹ روڈ میپ {#roadmap} + +اپنے کام کو مزید قابل رسائی بنانے اور کمیونٹی کے مزید تعاون کو فروغ دینے کے لیے، ethereum.org کور ٹیم ہمارے [شکل اپ سائیکل](https://www.productplan.com/glossary/shape-up-method/) روڈ میپ کے اہداف کا ایک جائزہ شائع کرتی ہے۔ + +[ہمارا 2025 سائیکل 1 پروڈکٹ روڈ میپ دیکھیں](https://github.com/ethereum/ethereum-org-website/issues/14726) + +**کیسا لگا؟** ہم ہمیشہ اپنے روڈ میپ پر آپ کے تاثرات کی تعریف کرتے ہیں - اگر کوئی ایسی چیز ہے جس پر آپ کے خیال میں ہمیں کام کرنا چاہئے، تو براہ کرم ہمیں بتائیں! ہم کمیونٹی میں کسی سے بھی آئیڈیاز اور PRs کا خیرمقدم کرتے ہیں۔ + +**شامل ہونا چاہتے ہیں؟** [تعاون کے بارے میں مزید جانیں](/contributing/)، [ہمیں ٹوئٹر پر ٹیگ کریں](https://x.com/ethdotorg)، یا [ہمارے ڈسکارڈ سرور](https://discord.gg/ethereum-org) پر کمیونٹی مباحثوں میں شامل ہوں۔ + +## ڈیزائن کے اصول {#design-principles} + +ہم سائٹ پر اپنے مواد اور ڈیزائن کے فیصلوں کی رہنمائی کے لیے [ڈیزائن کے اصولوں](/contributing/design-principles/) کا ایک مجموعہ استعمال کرتے ہیں۔ + +## ڈیزائن سسٹم {#design-system} + +ہم نے خصوصیات کو زیادہ تیزی سے فراہم کرنے اور کمیونٹی کے ممبران کو ethereum.org کے کھلے ڈیزائن میں حصہ لینے کی اجازت دینے کے لیے ایک [ڈیزائن سسٹم](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) بنایا اور جاری کیا۔ + +شامل ہونا چاہتے ہیں؟[Figma پر فالو کریں](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System)، the [GitHub issue](https://github.com/ethereum/ethereum-org-website/issues/6284) اور ہمارے [#design Discord channel](https://discord.gg/ethereum-org) میں گفتگو میں شامل ہوں۔ + +## اسٹائل گائیڈ {#style-guide} + +ہمارے پاس مواد لکھنے کے کچھ پہلوؤں کو معیاری بنانے کے لیے ایک [اسٹائل گائیڈ](/contributing/style-guide/) ہے تاکہ تعاون کے عمل کو ہموار بنایا جا سکے۔ + +اگر آپ [سائٹ میں تعاون](/contributing/) کرنا چاہتے ہیں تو یقینی بنائیں کہ آپ [ہمارے اصول](/contributing/design-principles/) اور [ہمارا اسٹائل گائیڈ](/contributing/style-guide/) پڑھیں۔ + +ہم اپنے ڈیزائن کے اصولوں، ڈیزائن سسٹم اور اسٹائل گائیڈ پر تاثرات کا خیرمقدم کرتے ہیں۔ یاد رکھیں، ethereum.org کمیونٹی کے لیے، کمیونٹی کے ذریعے ہے۔ + +## لائسنس {#license} + +ethereum.org ویب سائٹ اوپن سورس ہے اور [MIT لائسنس](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) کے تحت بنائی گئی ہے جب تک کہ دوسری صورت میں بیان نہ کیا گیا ہو۔ ethereum.org کے [استعمال کی شرائط](/terms-of-use/) پر مزید۔ + +## کھلی نوکریاں {#open-jobs} + +اگرچہ یہ ویب سائٹ اوپن سورس ہے اور کوئی بھی اس پر کام کر سکتا ہے، ہمارے پاس ethereum.org اور دیگر Ethereum Foundation ویب پروجیکٹس کے لیے ایک وقف ٹیم ہے۔ + +ہم یہاں کسی بھی نوکری کے مواقع پوسٹ کریں گے۔ اگر آپ کو یہاں اپنے لیے کوئی کردار نظر نہیں آتا ہے، تو [ہمارے ڈسکارڈ سرور](https://discord.gg/ethereum-org) پر جائیں اور ہمیں بتائیں کہ آپ ہمارے ساتھ کیسے کام کرنا چاہیں گے! + +ethereum.org ٹیم سے آگے دیکھ رہے ہیں؟ [ایتھیریم سے متعلق دیگر نوکریاں دیکھیں](/community/get-involved/#ethereum-jobs/)۔ diff --git a/public/content/translations/ur/ai-agents/index.md b/public/content/translations/ur/ai-agents/index.md new file mode 100644 index 00000000000..51e4c8dc3e9 --- /dev/null +++ b/public/content/translations/ur/ai-agents/index.md @@ -0,0 +1,144 @@ +--- +title: Ai-agents +metaTitle: "AI ایجنٹس | ایتھریم پر AI ایجنٹس" +description: "ایتھریم پر AI ایجنٹس کا ایک جائزہ" +lang: ur-in +template: use-cases +emoji: ":robot:" +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: "لوگ ٹرمینل ٹیبل پر جمع ہوئے" +summaryPoint1: "AI جو بلاک چین کے ساتھ تعامل کرتا ہے اور آزادانہ طور پر تجارت کرتا ہے" +summaryPoint2: "آن چین والٹس اور فنڈز کو کنٹرول کرتا ہے" +summaryPoint3: "کام کے لیے انسانوں یا دوسرے ایجنٹوں کو بھرتی کرتا ہے" +buttons: + - content: AI ایجنٹس کیا ہیں؟ + toId: what-are-ai-agents + - content: ایجنٹس دریافت کریں + toId: ai-agents-on-ethereum + isSecondary: false +--- + +ایک AI اسسٹنٹ کے ساتھ ایتھریم کو نیویگیٹ کرنے کا تصور کریں جو 24/7 آن چین مارکیٹ کے رجحانات کا مطالعہ کرتا ہے، سوالات کے جوابات دیتا ہے، اور یہاں تک کہ آپ کی طرف سے ٹرانزیکشنز بھی انجام دیتا ہے۔ AI ایجنٹس کی دنیا میں خوش آمدید—آپ کی ڈیجیٹل زندگی کو آسان بنانے کے لیے ڈیزائن کیے گئے ذہین سسٹمز۔ + +ایتھریم پر، ہم ورچوئل انفلوئنسرز اور خود مختار مواد تخلیق کاروں سے لے کر ریئل ٹائم مارکیٹ تجزیہ پلیٹ فارمز تک AI ایجنٹس کی اختراعات دیکھ رہے ہیں، جو صارفین کو بصیرت، تفریح، اور آپریشنل کارکردگی فراہم کرکے بااختیار بناتے ہیں۔ + +## AI ایجنٹس کیا ہیں؟ {#what-are-ai-agents} + +AI ایجنٹس سافٹ ویئر پروگرام ہیں جو کام انجام دینے یا اپنے فیصلے کرنے کے لیے مصنوعی ذہانت کا استعمال کرتے ہیں۔ وہ ڈیٹا سے سیکھتے ہیں، تبدیلیوں کے مطابق ڈھالتے ہیں، اور پیچیدہ کاموں کو سنبھالتے ہیں۔ وہ بغیر رکے کام کرتے ہیں اور فوری طور پر مواقع کا پتہ لگا سکتے ہیں۔ + +### AI ایجنٹس بلاک چینز کے ساتھ کیسے کام کرتے ہیں {#how-ai-agents-work-with-blockchains} + +روایتی مالیات میں، AI ایجنٹس اکثر محدود ڈیٹا ان پٹس کے ساتھ مرکزی ماحول میں کام کرتے ہیں۔ یہ ان کی خود مختار طور پر سیکھنے یا اثاثوں کا انتظام کرنے کی صلاحیت میں رکاوٹ بنتا ہے۔ + +اس کے برعکس، ایتھریم کا غیر مرکزی ایکو سسٹم کئی اہم فوائد پیش کرتا ہے: + +- شفاف ڈیٹا: ریئل ٹائم بلاک چین معلومات تک رسائی۔ +- اثاثوں کی حقیقی ملکیت: ڈیجیٹل اثاثے مکمل طور پر AI ایجنٹس کی ملکیت ہیں۔ +- مضبوط آن چین فعالیت: AI ایجنٹس کو ٹرانزیکشنز انجام دینے، اسمارٹ معاہدوں کے ساتھ تعامل کرنے، لیکویڈیٹی فراہم کرنے، اور پروٹوکولز کے پار تعاون کرنے کے قابل بناتا ہے۔ + +یہ عوامل AI ایجنٹس کو سادہ بوٹس سے متحرک، خود کو بہتر بنانے والے سسٹمز میں تبدیل کرتے ہیں جو متعدد شعبوں میں اہم قدر پیش کرتے ہیں: + + + + + + + +## قابل تصدیق AI {#verifiable-ai} + +آف چین چلنے والے AI ایجنٹس اکثر "بلیک باکس" کی طرح برتاؤ کرتے ہیں—ان کی استدلال، ان پٹس، اور آؤٹ پٹس کی آزادانہ طور پر تصدیق نہیں کی جا سکتی۔ ایتھریم اسے بدل دیتا ہے۔ ایجنٹ کے رویے کو آن چین اینکر کرکے، ڈیولپرز ایسے ایجنٹس بنا سکتے ہیں جو _ٹرسٹ لیس_، _شفاف_، اور _معاشی طور پر خود مختار_ ہیں۔ ایسے ایجنٹوں کے اقدامات کا آڈٹ کیا جا سکتا ہے، انہیں محدود کیا جا سکتا ہے، اور ثابت کیا جا سکتا ہے۔ + +### قابل تصدیق استنباط {#verifiable-inference} + +AI استنباط روایتی طور پر آف چین ہوتا ہے، جہاں عمل درآمد سستا ہے لیکن ماڈل کا عمل درآمد غیر شفاف ہے۔ ایتھریم پر، ڈیولپرز کئی تکنیکوں کا استعمال کرتے ہوئے قابل تصدیق کمپیوٹیشن کے ساتھ ایجنٹوں کو جوڑ سکتے ہیں: + +- [**zkML (زیرو نالج مشین لرننگ)**](https://opengradient.medium.com/a-gentle-introduction-to-zkml-8049a0e10a04) ایجنٹس کو یہ ثابت کرنے دیتا ہے کہ ایک ماڈل صحیح طریقے سے عمل میں لایا گیا تھا بغیر ماڈل یا ان پٹس کو ظاہر کیے۔ +- [**TEE (ٹرسٹیڈ ایگزیکیوشن انوائرمنٹ) تصدیقات**](https://en.wikipedia.org/wiki/Trusted_execution_environment) ہارڈ ویئر کی حمایت یافتہ ثبوتوں کی اجازت دیتی ہیں کہ ایک ایجنٹ نے ایک مخصوص ماڈل یا کوڈ پاتھ چلایا۔ +- **آن چین امیوٹیبلٹی** یقینی بناتی ہے کہ ان ثبوتوں اور تصدیقوں کا حوالہ دیا جا سکتا ہے، دوبارہ چلایا جا سکتا ہے، اور کسی بھی معاہدے یا ایجنٹ کے ذریعہ ان پر بھروسہ کیا جا سکتا ہے۔ + +## x402 کے ساتھ ادائیگیاں اور تجارت {#x402} + +[x402 پروٹوکول](https://www.x402.org/)، جو ایتھریم اور L2s پر تعینات ہے، ایجنٹس کو وسائل کے لیے ادائیگی کرنے اور انسانی مداخلت کے بغیر معاشی طور پر تعامل کرنے کا ایک مقامی طریقہ فراہم کرتا ہے۔ ایجنٹس کر سکتے ہیں: + +- اسٹیبل کوائنز کا استعمال کرتے ہوئے کمپیوٹ، ڈیٹا، اور API کالز کے لیے ادائیگی کریں +- دوسرے ایجنٹوں یا خدمات سے تصدیقات کی درخواست کریں یا تصدیق کریں +- ایجنٹ سے ایجنٹ تجارت میں حصہ لیں، کمپیوٹ، ڈیٹا، یا ماڈل آؤٹ پٹ خریدیں اور بیچیں + +x402 ایتھریم کو خود مختار ایجنٹوں کے لیے ایک قابل پروگرام معاشی پرت میں تبدیل کرتا ہے، جو اکاؤنٹس، سبسکرپشنز، یا مرکزی بلنگ کے بجائے فی استعمال ادائیگی کے تعاملات کو قابل بناتا ہے۔ + +### ایجنٹک فنانس سیکیورٹی {#agentic-finance-security} + +خود مختار ایجنٹوں کو گائیڈریلز کی ضرورت ہوتی ہے۔ ایتھریم انہیں والٹ اور معاہدے کی سطح پر فراہم کرتا ہے: + +- [اسمارٹ اکاؤنٹس (EIP-4337)](https://eips.ethereum.org/EIPS/eip-4337) ڈیولپرز کو خرچ کی حدیں، وائٹ لسٹ، سیشن کیز، اور تفصیلی اجازتیں نافذ کرنے دیتے ہیں۔ +- اسمارٹ معاہدوں میں پروگرام شدہ پابندیاں اس بات کو محدود کر سکتی ہیں کہ ایک ایجنٹ کو کیا کرنے کی اجازت ہے۔ +- استنباط پر مبنی حدود (مثال کے طور پر، ایک زیادہ خطرے والے عمل کو انجام دینے سے پہلے zkML ثبوت کی ضرورت) حفاظت کی ایک اور پرت کا اضافہ کرتی ہیں۔ + +یہ کنٹرولز خود مختار ایجنٹوں کی تعیناتی کو قابل بناتے ہیں جو لامحدود نہیں ہیں۔ + +### آن چین رجسٹریاں: ERC-8004 {#erc-8004} + +[ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) ایک ابھرتا ہوا معیار ہے (فی الحال ہم مرتبہ جائزہ میں ہے) جو ایجنٹ کی شناخت، صلاحیتوں، اور تصدیقوں کے لیے آن چین رجسٹریوں کی تجویز کرتا ہے۔ + +اگر اپنایا گیا تو، یہ فراہم کر سکتا ہے: + +- ایجنٹوں کی ایک مشترکہ، ٹرسٹ لیس ڈائرکٹری +- معیاری تصدیقی فارمیٹس +- براہ راست ایتھریم مین نیٹ پر "ٹرسٹ لیس ایجنٹ انفراسٹرکچر" کے لیے ایک بنیاد + +اس سے ایجنٹوں کے لیے ایک مکمل طور پر غیر مرکزی ماحول میں ایک دوسرے کو دریافت کرنا، تصدیق کرنا، اور ان کے ساتھ لین دین کرنا آسان ہو جائے گا۔ + +## ایتھریم پر AI ایجنٹس {#ai-agents-on-ethereum} + +ہم AI ایجنٹس کی مکمل صلاحیت کو تلاش کرنا شروع کر رہے ہیں، اور پروجیکٹس پہلے ہی AI اور بلاک چین کے درمیان ہم آہنگی سے فائدہ اٹھا رہے ہیں—خاص طور پر شفافیت اور منیٹائزیشن میں۔ + + + +پوڈ کاسٹ مہمان کے طور پر لونا کی پہلی نمائش + + + +## ایجنٹ کے زیر کنٹرول والٹس {#agent-controlled-wallets} + +لونا یا AIXBT جیسے ایجنٹس اپنے آن چین والٹ کو کنٹرول کرتے ہیں ([AIXBT کا والٹ](https://clusters.xyz/aixbt), [لونا کا والٹ](https://zapper.xyz/account/0x0d177181e3763b20d47dc3a72dd584368bd8bf43)) جو انہیں مداحوں کو ٹپ دینے اور معاشی سرگرمیوں میں حصہ لینے کے قابل بناتا ہے۔ + +لونا کی X سوشل مہم #LunaMuralChallenge کے دوران، لونا نے اپنے بیس والٹ کے ذریعے فاتحین کو منتخب کیا اور انعام دیا — جو کرپٹو انعام کے لیے انسانوں کو بھرتی کرنے والے AI کی پہلی مثال ہے۔ + + + + +

جاننا اچھا ہے

+

AI ایجنٹس اور متعلقہ ٹولز ابھی ابتدائی ترقی میں ہیں اور بہت تجرباتی ہیں—احتیاط کے ساتھ استعمال کریں۔

+
+ +
+ +## چیٹ کمانڈز کا استعمال کرتے ہوئے اپنے والٹ کو کنٹرول کریں {#control-your-wallet-using-chat-commands} + +آپ DeFi کے پیچیدہ انٹرفیس کو چھوڑ سکتے ہیں اور سادہ چیٹ کمانڈز کے ساتھ اپنے کرپٹو کا نظم کر سکتے ہیں۔ + +یہ بدیہی نقطہ نظر لین دین کو تیز، آسان، اور غلطیوں کا کم شکار بناتا ہے جیسے غلط پتے پر فنڈز بھیجنا یا فیس کے لیے زیادہ ادائیگی کرنا۔ + + + +## AI ایجنٹس بمقابلہ AI بوٹس {#ai-agents-vs-ai-bots} + +AI ایجنٹس اور AI بوٹس کے درمیان فرق کبھی کبھی الجھا سکتا ہے، کیونکہ دونوں ان پٹ کی بنیاد پر خودکار کارروائیاں انجام دیتے ہیں۔ + +- AI بوٹس خودکار معاونین کی طرح ہیں — وہ معمول کے کاموں کو انجام دینے کے لیے مخصوص، پہلے سے پروگرام شدہ ہدایات پر عمل کرتے ہیں۔ +- AI ایجنٹس زیادہ ذہین ساتھیوں کی طرح ہیں — وہ تجربے سے سیکھتے ہیں، نئی معلومات کے مطابق ڈھالتے ہیں، اور خود فیصلے کرتے ہیں۔ + +| | Ai-agents | AI بوٹس | +| ---------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------- | +| **تعاملات** | پیچیدہ، موافق، خود مختار | سادہ، پہلے سے طے شدہ دائرہ کار، ہارڈ کوڈڈ | +| **سیکھنا** | مسلسل سیکھتا ہے، ریئل ٹائم میں نئے ڈیٹا کے ساتھ تجربہ کر سکتا ہے اور اس کے مطابق ڈھال سکتا ہے | پہلے سے تربیت یافتہ ڈیٹا یا مقررہ اصولوں پر کام کرتا ہے | +| **کام کی تکمیل** | وسیع تر مقاصد کو حاصل کرنے کا مقصد ہے | صرف مخصوص کاموں پر توجہ مرکوز کرتا ہے | + +## گہرائی میں جائیں {#dive-deeper} + + + +## آپ اپنا AI ایجنٹ بنا سکتے ہیں {#you-can-build-your-own-ai-agent} + + diff --git a/public/content/translations/ur/bridges/index.md b/public/content/translations/ur/bridges/index.md new file mode 100644 index 00000000000..6835e05063a --- /dev/null +++ b/public/content/translations/ur/bridges/index.md @@ -0,0 +1,145 @@ +--- +title: "بلاک چین برجز کا تعارف" +description: "برجز صارفین کو اپنے فنڈز مختلف بلاک چینز میں منتقل کرنے کی اجازت دیتے ہیں" +lang: ur-in +--- + +# بلاک چین برجز {#prerequisites} + +_Web3، L1 بلاک چینز اور L2 اسکیلنگ سلوشنز کے ایک ایکو سسٹم میں تبدیل ہو گیا ہے، جن میں سے ہر ایک کو منفرد صلاحیتوں اور ٹریڈ-آفس کے ساتھ ڈیزائن کیا گیا ہے۔ جیسے جیسے بلاک چین پروٹوکولز کی تعداد بڑھتی ہے، ویسے ہی چینز کے درمیان اثاثوں کو منتقل کرنے کا مطالبہ بھی بڑھتا ہے۔اس مطالبے کو پورا کرنے کے لیے، ہمیں برجز کی ضرورت ہے۔_ + + + +## برجز کیا ہیں؟ {#what-are-bridges} + +بلاک چین برجز بالکل اسی طرح کام کرتے ہیں جیسے ہم طبعی دنیا میں برجز کو جانتے ہیں۔ جس طرح ایک طبعی برج دو طبعی مقامات کو جوڑتا ہے، اسی طرح ایک بلاک چین برج دو بلاک چین ایکو سسٹمز کو جوڑتا ہے۔ **برجز معلومات اور اثاثوں کی منتقلی کے ذریعے بلاک چینز کے درمیان مواصلات کو آسان بناتے ہیں**۔ + +آئیے ایک مثال پر غور کریں: + +آپ USA سے ہیں اور یورپ کے سفر کا منصوبہ بنا رہے ہیں۔ آپ کے پاس USD ہیں، لیکن آپ کو خرچ کرنے کے لیے EUR کی ضرورت ہے۔ اپنے USD کو EUR میں تبدیل کرنے کے لیے آپ ایک چھوٹی سی فیس کے عوض کرنسی ایکسچینج کا استعمال کر سکتے ہیں۔ + +لیکن، اگر آپ ایک مختلف [blockchain](/glossary/#blockchain) استعمال کرنے کے لیے اسی طرح کا تبادلہ کرنا چاہتے ہیں تو آپ کیا کریں گے؟ فرض کریں کہ آپ Ethereum Mainnet پر [ETH](/glossary/#ether) کا تبادلہ [Arbitrum](https://arbitrum.io/) پر ETH سے کرنا چاہتے ہیں۔ EUR کے لیے کیے گئے کرنسی تبادلے کی طرح، ہمیں اپنے ETH کو Ethereum سے Arbitrum میں منتقل کرنے کے لیے ایک میکانزم کی ضرورت ہے۔ برجز اس طرح کے لین دین کو ممکن بناتے ہیں۔ اس معاملے میں، [Arbitrum کا ایک مقامی برج ہے](https://portal.arbitrum.io/bridge) جو Mainnet سے Arbitrum پر ETH منتقل کر سکتا ہے۔ + +## ہمیں برجز کی ضرورت کیوں ہے؟ {#why-do-we-need-bridges} + +تمام بلاک چینز کی اپنی حدود ہوتی ہیں۔ Ethereum کو اسکیل کرنے اور طلب کو پورا کرنے کے لیے، اسے [rollups](/glossary/#rollups) کی ضرورت پڑی ہے۔ متبادل کے طور پر، Solana اور Avalanche جیسے L1s کو زیادہ تھروپٹ کو فعال کرنے کے لیے مختلف طریقے سے ڈیزائن کیا گیا ہے لیکن وکندریقرت کی قیمت پر۔ + +تاہم، تمام بلاک چینز کو الگ تھلگ ماحول میں تیار کیا جاتا ہے اور ان کے اصول اور [consensus](/glossary/#consensus) میکانزم مختلف ہوتے ہیں۔ اس کا مطلب ہے کہ وہ مقامی طور پر بات چیت نہیں کر سکتے ہیں، اور ٹوکنز بلاک چینز کے درمیان آزادانہ طور پر منتقل نہیں ہو سکتے ہیں۔ + +برجز بلاک چینز کو جوڑنے کے لیے موجود ہیں، جو ان کے درمیان معلومات اور ٹوکنز کی منتقلی کی اجازت دیتے ہیں۔ + +**برجز فعال کرتے ہیں**: + +- اثاثوں اور معلومات کی کراس چین منتقلی۔ +- [dapps](/glossary/#dapp) کو مختلف بلاک چینز کی طاقتوں تک رسائی حاصل کرنے کے لیے – اس طرح ان کی صلاحیتوں میں اضافہ ہوتا ہے (کیونکہ اب پروٹوکولز کے پاس جدت کے لیے زیادہ ڈیزائن کی جگہ ہے)۔ +- صارفین کو نئے پلیٹ فارمز تک رسائی حاصل کرنے اور مختلف چینز کے فوائد سے استفادہ کرنے کے لیے۔ +- مختلف بلاک چین ایکو سسٹمز کے ڈیولپرز کو صارفین کے لیے نئے پلیٹ فارمز بنانے اور تعاون کرنے کے لیے۔ + +[لیئر 2 میں ٹوکنز کو کیسے برج کریں](/guides/how-to-use-a-bridge/) + + + +## برج کے استعمال کے معاملات {#bridge-use-cases} + +ذیل میں کچھ منظرنامے ہیں جہاں آپ برج کا استعمال کر سکتے ہیں: + +### کم ٹرانزیکشن فیس {#transaction-fees} + +فرض کریں کہ آپ کے پاس Ethereum Mainnet پر ETH ہے لیکن آپ مختلف dapps کو دریافت کرنے کے لیے سستی ٹرانزیکشن فیس چاہتے ہیں۔ اپنے ETH کو Mainnet سے Ethereum L2 رول اپ میں برج کر کے، آپ کم ٹرانزیکشن فیس سے لطف اندوز ہو سکتے ہیں۔ + +### دیگر بلاک چینز پر Dapps {#dapps-other-chains} + +اگر آپ USDT فراہم کرنے کے لیے Ethereum Mainnet پر Aave کا استعمال کر رہے ہیں لیکن Polygon پر Aave کا استعمال کرتے ہوئے USDT فراہم کرنے پر آپ کو ملنے والی سود کی شرح زیادہ ہے۔ + +### بلاک چین ایکو سسٹمز کو دریافت کریں {#explore-ecosystems} + +اگر آپ کے پاس Ethereum Mainnet پر ETH ہے اور آپ ان کے مقامی dapps کو آزمانے کے لیے ایک alt L1 کو دریافت کرنا چاہتے ہیں۔ آپ اپنے ETH کو Ethereum Mainnet سے alt L1 میں منتقل کرنے کے لیے ایک برج کا استعمال کر سکتے ہیں۔ + +### مقامی کرپٹو اثاثوں کے مالک بنیں {#own-native} + +فرض کریں کہ آپ مقامی Bitcoin (BTC) کے مالک بننا چاہتے ہیں، لیکن آپ کے پاس صرف Ethereum Mainnet پر فنڈز ہیں۔ Ethereum پر BTC کی رسائی حاصل کرنے کے لیے، آپ Wrapped Bitcoin (WBTC) خرید سکتے ہیں۔ تاہم، WBTC ایک [ERC-20](/glossary/#erc-20) ٹوکن ہے جو Ethereum نیٹ ورک کا مقامی ہے، جس کا مطلب ہے کہ یہ Bitcoin کا ایک Ethereum ورژن ہے نہ کہ Bitcoin بلاک چین پر اصل اثاثہ۔ مقامی BTC کا مالک بننے کے لیے، آپ کو ایک برج کا استعمال کرتے ہوئے اپنے اثاثوں کو Ethereum سے Bitcoin میں برج کرنا ہوگا۔ یہ آپ کے WBTC کو برج کرے گا اور اسے مقامی BTC میں تبدیل کر دے گا۔ متبادل طور پر، آپ BTC کے مالک ہو سکتے ہیں اور اسے Ethereum [DeFi](/glossary/#defi) پروٹوکولز میں استعمال کرنا چاہتے ہیں۔ اس کے لیے دوسری طرف سے برجنگ کی ضرورت ہوگی، BTC سے WBTC تک جسے پھر Ethereum پر ایک اثاثہ کے طور پر استعمال کیا جا سکتا ہے۔ + + + + + + آپ مندرجہ بالا سب کچھ ایک [مرکزی ایکسچینج](/get-eth) کا استعمال کر کے بھی کر سکتے ہیں۔ تاہم، جب تک کہ آپ کے فنڈز پہلے سے ہی کسی ایکسچینج پر نہ ہوں، اس میں کئی مراحل شامل ہوں گے، اور آپ کے لیے برج کا استعمال کرنا زیادہ بہتر ہوگا۔ + + + + + + +## برجز کی اقسام {#types-of-bridge} + +برجز کے کئی قسم کے ڈیزائن اور پیچیدگیاں ہوتی ہیں۔ عام طور پر، برجز دو زمروں میں آتے ہیں: ٹرسٹڈ اور ٹرسٹ لیس برجز۔ + +| ٹرسٹڈ برجز | ٹرسٹ لیس برجز | +| ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | +| ٹرسٹڈ برجز اپنے آپریشنز کے لیے ایک مرکزی ادارے یا نظام پر انحصار کرتے ہیں۔ | ٹرسٹ لیس برجز اسمارٹ کنٹریکٹس اور الگورتھم کا استعمال کرتے ہوئے کام کرتے ہیں۔ | +| ان کے پاس فنڈز کی تحویل اور برج کی سیکورٹی کے حوالے سے اعتماد کے مفروضے ہوتے ہیں۔ صارفین زیادہ تر برج آپریٹر کی ساکھ پر انحصار کرتے ہیں۔ | وہ ٹرسٹ لیس ہیں، یعنی، برج کی سیکورٹی وہی ہے جو بنیادی بلاک چین کی ہے۔ | +| صارفین کو اپنے کرپٹو اثاثوں پر کنٹرول چھوڑنے کی ضرورت ہے۔ | [smart contracts](/glossary/#smart-contract) کے ذریعے، ٹرسٹ لیس برجز صارفین کو اپنے فنڈز پر کنٹرول برقرار رکھنے کے قابل بناتے ہیں۔ | + +مختصراً، ہم کہہ سکتے ہیں کہ ٹرسٹڈ برجز میں اعتماد کے مفروضے ہوتے ہیں، جبکہ ٹرسٹ لیس برجز اعتماد کو کم کرتے ہیں اور بنیادی ڈومینز سے باہر نئے اعتماد کے مفروضے نہیں بناتے۔ یہاں یہ بتایا گیا ہے کہ ان شرائط کو کیسے بیان کیا جا سکتا ہے: + +- **ٹرسٹ لیس**: بنیادی ڈومینز کے مساوی سیکورٹی کا حامل۔ جیسا کہ [اس مضمون میں ارجن بھوپتانی نے بیان کیا ہے۔](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17) +- **اعتماد کے مفروضے:** سسٹم میں بیرونی تصدیق کنندگان کو شامل کر کے بنیادی ڈومینز کی سیکورٹی سے دور جانا، اس طرح اسے کرپٹو-اقتصادی طور پر کم محفوظ بنانا۔ + +دونوں طریقوں کے درمیان کلیدی فرق کی بہتر تفہیم پیدا کرنے کے لیے، آئیے ایک مثال لیتے ہیں: + +تصور کریں کہ آپ ایئرپورٹ کے سیکورٹی چیک پوائنٹ پر ہیں۔ چیک پوائنٹس کی دو قسمیں ہیں: + +1. مینوئل چیک پوائنٹس — اہلکاروں کے ذریعے چلائے جاتے ہیں جو بورڈنگ پاس حوالے کرنے سے پہلے آپ کے ٹکٹ اور شناخت کی تمام تفصیلات کو دستی طور پر چیک کرتے ہیں۔ +2. سیلف چیک ان — ایک مشین کے ذریعے چلایا جاتا ہے جہاں آپ اپنی فلائٹ کی تفصیلات ڈالتے ہیں اور اگر سب کچھ ٹھیک ہو تو بورڈنگ پاس حاصل کرتے ہیں۔ + +ایک مینوئل چیک پوائنٹ ایک ٹرسٹڈ ماڈل کی طرح ہے کیونکہ یہ اپنے آپریشنز کے لیے کسی تیسرے فریق، یعنی اہلکاروں پر منحصر ہے۔ ایک صارف کے طور پر، آپ صحیح فیصلے کرنے اور اپنی نجی معلومات کو صحیح طریقے سے استعمال کرنے کے لیے اہلکاروں پر بھروسہ کرتے ہیں۔ + +سیلف چیک ان ایک ٹرسٹ لیس ماڈل کی طرح ہے کیونکہ یہ آپریٹر کے کردار کو ہٹاتا ہے اور اپنے آپریشنز کے لیے ٹیکنالوجی کا استعمال کرتا ہے۔ صارفین ہمیشہ اپنے ڈیٹا پر کنٹرول رکھتے ہیں اور انہیں اپنی نجی معلومات کے ساتھ کسی تیسرے فریق پر بھروسہ کرنے کی ضرورت نہیں ہوتی۔ + +بہت سے برجنگ سلوشنز ان دو انتہاؤں کے درمیان ماڈلز کو اپناتے ہیں جن میں ٹرسٹ لیسنس کی مختلف ڈگریاں ہوتی ہیں۔ + + + +## برجز کا استعمال کریں {#use-bridge} + +برجز کا استعمال آپ کو اپنے اثاثوں کو مختلف بلاک چینز میں منتقل کرنے کی اجازت دیتا ہے۔ یہاں کچھ وسائل ہیں جو آپ کو برجز تلاش کرنے اور استعمال کرنے میں مدد کر سکتے ہیں: + +- **[L2BEAT برجز کا خلاصہ](https://l2beat.com/bridges/summary) & [L2BEAT برجز کے خطرات کا تجزیہ](https://l2beat.com/bridges/summary)**: مختلف برجز کا ایک جامع خلاصہ، جس میں مارکیٹ شیئر، برج کی قسم، اور منزل کی چینز کی تفصیلات شامل ہیں۔ L2BEAT کے پاس برجز کے لیے خطرات کا تجزیہ بھی ہے، جو صارفین کو برج کا انتخاب کرتے وقت باخبر فیصلے کرنے میں مدد کرتا ہے۔ +- **[DefiLlama برج کا خلاصہ](https://defillama.com/bridges/Ethereum)**: Ethereum نیٹ ورکس میں برج والیوم کا خلاصہ۔ + + + +## برجز استعمال کرنے کا خطرہ {#bridge-risk} + +برجز ترقی کے ابتدائی مراحل میں ہیں۔ یہ ممکن ہے کہ بہترین برج ڈیزائن ابھی تک دریافت نہیں ہوا ہے۔ کسی بھی قسم کے برج کے ساتھ تعامل میں خطرہ ہوتا ہے: + +- **اسمارٹ کنٹریکٹ کا خطرہ —** کوڈ میں کسی بگ کا خطرہ جس کی وجہ سے صارف کے فنڈز ضائع ہو سکتے ہیں +- **ٹیکنالوجی کا خطرہ —** سافٹ ویئر کی ناکامی، بگ والا کوڈ، انسانی غلطی، اسپام، اور بدنیتی پر مبنی حملے ممکنہ طور پر صارف کے آپریشنز میں خلل ڈال سکتے ہیں + +مزید برآں، چونکہ ٹرسٹڈ برجز اعتماد کے مفروضے شامل کرتے ہیں، ان میں اضافی خطرات ہوتے ہیں جیسے: + +- **سنسرشپ کا خطرہ —** برج آپریٹرز نظریاتی طور پر صارفین کو برج کا استعمال کرتے ہوئے اپنے اثاثوں کی منتقلی سے روک سکتے ہیں +- **تحویل کا خطرہ —** برج آپریٹرز صارفین کے فنڈز چرانے کے لیے ملی بھگت کر سکتے ہیں + +صارف کے فنڈز کو خطرہ ہے اگر: + +- اسمارٹ کنٹریکٹ میں کوئی بگ ہو +- صارف کوئی غلطی کرتا ہے +- بنیادی بلاک چین ہیک ہو جاتا ہے +- ایک ٹرسٹڈ برج میں برج آپریٹرز کی نیت بدنیتی پر مبنی ہو +- برج ہیک ہو جاتا ہے + +حال ہی میں ایک ہیک سولانا کا ورم ہول برج تھا، [جہاں ہیک کے دوران 120k wETH (325 ملین امریکی ڈالر) چوری ہو گئے تھے](https://rekt.news/wormhole-rekt/)۔ [بلاک چینز میں بہت سے سرفہرست ہیکس میں برجز شامل تھے](https://rekt.news/leaderboard/)۔ + +Ethereum L2s پر صارفین کو آن بورڈ کرنے کے لیے برجز بہت اہم ہیں، اور یہاں تک کہ ان صارفین کے لیے بھی جو مختلف ایکو سسٹمز کو دریافت کرنا چاہتے ہیں۔ تاہم، برجز کے ساتھ تعامل میں شامل خطرات کو دیکھتے ہوئے، صارفین کو ان ٹریڈ-آفس کو سمجھنا چاہیے جو برجز کر رہے ہیں۔ یہ [کراس چین سیکورٹی کے لیے کچھ حکمت عملیاں](https://debridge.com/learn/blog/10-strategies-for-cross-chain-security/) ہیں۔ + + + +## مزید پڑھیں {#further-reading} + +- [EIP-5164: کراس چین ایگزیکیوشن](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) - _18 جون، 2022 - برینڈن ایسلسٹائن_ +- [L2Bridge رسک فریم ورک](https://gov.l2beat.com/t/l2bridge-risk-framework/31) - _5 جولائی، 2022 - بارٹیک کیپوسزیوسکی_ +- ["مستقبل ملٹی چین کیوں ہوگا، لیکن یہ کراس چین نہیں ہوگا۔"](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) - _8 جنوری، 2022 - وائٹلک بٹیرن_ +- [محفوظ کراس چین انٹرآپریبلٹی کے لیے مشترکہ سیکورٹی کا استعمال: لگرینج اسٹیٹ کمیٹیاں اور اس سے آگے](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - _12 جون، 2024 - ایمانوئل اووسیکا_ +- [رول اپ انٹرآپریبلٹی سلوشنز کی حالت](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - _20 جون، 2024 - ایلکس ہُک_ + diff --git a/public/content/translations/ur/community/code-of-conduct/index.md b/public/content/translations/ur/community/code-of-conduct/index.md new file mode 100644 index 00000000000..3d050c317e5 --- /dev/null +++ b/public/content/translations/ur/community/code-of-conduct/index.md @@ -0,0 +1,77 @@ +--- +title: "ضابطہ اخلاق" +description: "بنیادی معیارات جن کے لیے ہم ethereum.org اسپیسز میں کوشش کرتے ہیں۔" +lang: ur-in +--- + +# ضابطہ اخلاق {#code-of-conduct} + +## مشن {#mission} + +Ethereum کے لیے سب سے جامع اور قابل رسائی علمی مرکز کو تیار کرنا اور برقرار رکھنا۔ + +## اقدار {#values} + +ethereum.org کمیونٹی بننے کی کوشش کرتی ہے: + +- تعلیمی، جس کا مقصد ہر کسی کو Ethereum سمجھنے میں مدد کرنا ہے +- جامع +- قابل رسائی +- کمیونٹی سے چلنے والا +- Ethereum کی بنیادی ٹیکنالوجی اور استعمال کے معاملات پر مرکوز +- Ethereum کے تصورات اور ڈیزائن کے اصولوں پر مرکوز + +## ہم کیا نہیں ہیں {#what-we-are-not} + +- Ethereum فاؤنڈیشن کی ویب سائٹ +- کسی بھی قسم کی سرمایہ کاری یا منافع خوری کو فروغ دینے کا پلیٹ فارم +- انفرادی پروجیکٹس یا تنظیموں کو بلند کرنے یا ان کی توثیق کرنے کا پلیٹ فارم +- ایک DEX، CEX یا کسی دوسری قسم کا مالیاتی پلیٹ فارم +- ایک ایسا پلیٹ فارم جو کسی بھی قسم کا مالی یا قانونی مشورہ دیتا ہے + +## ضابطہ اخلاق {#code-of-conduct} + +### عہد {#pledge} + +کھلی شرکت ethereum.org کے اخلاقیات کا مرکز ہے۔ ہم ایک ویب سائٹ اور کمیونٹی ہیں جسے ہزاروں شراکت داروں کے ذریعے برقرار رکھا جاتا ہے، اور یہ تب ہی ممکن ہے جب ہم ایک خوش آئند، شرکت پر مبنی ماحول کو برقرار رکھیں۔ اس مقصد کے لیے، اس سائٹ کے شراکت دار تمام ethereum.org پلیٹ فارمز اور کمیونٹی اسپیسز میں تمام شرکاء کے لیے ہراسانی سے پاک ماحول کو برقرار رکھنے کا عہد کرتے ہیں۔ ethereum.org کمیونٹی ہر اس شخص کا خیرمقدم کرتی ہے اور اسے اہمیت دیتی ہے جو تعمیری اور دوستانہ طریقے سے حصہ لینا چاہتا ہے، چاہے اس کی عمر، معذوری، نسل، جنسی خصوصیات، صنفی شناخت، تجربے کی سطح، مہارت کا شعبہ، تعلیم، سماجی و اقتصادی حیثیت، قومیت، ذاتی ظاہری شکل، نسل، مذہب یا تنوع کا کوئی اور پہلو کچھ بھی ہو۔ + +### دائرہ کار {#scope} + +یہ ضابطہ اخلاق تمام ethereum.org اسپیسز (جیسے GitHub, Discord, Figma, Crowdin, X (سابقہ ٹویٹر) اور دیگر آن لائن پلیٹ فارمز) پر لاگو ہوتا ہے، اور یہ اس وقت بھی لاگو ہوتا ہے جب کمیونٹی کی نمائندگی حقیقی دنیا کی عوامی جگہوں جیسے میٹ اپس، کانفرنسوں اور ایونٹس میں کی جاتی ہے۔ + +### ہمارے معیارات {#our-standards} + +مثبت ماحول پیدا کرنے میں معاون رویے کی مثالوں میں شامل ہیں: + +- خوش آئند اور جامع زبان کا استعمال +- مختلف نقطہ نظر اور تجربات کا احترام کرنا +- تعمیری تنقید کو شائستگی سے قبول کرنا اور/یا ہمدردی سے فراہم کرنا +- تنازعات یا اختلافات کو حل کرتے وقت پرسکون اور پیشہ ورانہ طور پر کام کرنا +- کمیونٹی کے دیگر اراکین کے ساتھ ہمدردی اور رواداری کا مظاہرہ کرنا +- کمیونٹی میں نئی آوازوں کی حوصلہ افزائی اور انہیں بڑھاوا دینا + +شرکاء کے ناقابل قبول رویے کی مثالوں میں شامل ہیں: + +- جسمانی تشدد، جسمانی تشدد کی دھمکی دینا یا کسی بھی قسم کے جسمانی تشدد کی حوصلہ افزائی کرنا +- جنسی زبان یا منظر کشی کا استعمال کرنا یا ناپسندیدہ جنسی توجہ مسلط کرنا +- کسی دوسرے فرد کی نقالی کرنا یا کسی فرد یا تنظیم کے ساتھ بے ایمانی سے وابستگی کا دعویٰ کرنا +- ٹرولنگ، توہین آمیز/تضحیک آمیز تبصرے، اور ذاتی یا سیاسی حملے +- عوامی یا نجی چینلز میں کمیونٹی کے دیگر اراکین کو ہراساں کرنا +- واضح اجازت کے بغیر دوسروں کی نجی معلومات، جیسے جسمانی یا الیکٹرانک پتہ، شائع کرنا +- سوشل انجینئرنگ، اسکیمنگ یا کمیونٹی کے دیگر اراکین کو کسی اور طرح سے جوڑ توڑ کرنا +- ذاتی مالی یا غیر مالی فائدے کے لیے سرمایہ کاری، ٹوکنز، پروجیکٹس یا کسی اور چیز کو فروغ دینا +- غیر موضوعی مواد کے ساتھ سرورز کو اسپیم کرنا +- کمیونٹی ماڈریٹرز کی درخواستوں یا انتباہات کو نظر انداز کرنا +- ایسے دوسرے طرز عمل میں مشغول ہونا جسے پیشہ ورانہ ماحول میں نامناسب سمجھا جا سکتا ہے + +### رپورٹنگ {#reporting} + +ضابطہ اخلاق کی خلاف ورزیاں عام طور پر کمیونٹی کو نظر آئیں گی کیونکہ ہم ہر چیز کھلے، عوامی چینلز میں کرنے کی کوشش کرتے ہیں، جس سے کمیونٹی کے اراکین خود نگرانی کر سکتے ہیں۔ + +تاہم، اگر کچھ ایسا ہوتا ہے جس پر آپ کو توجہ کی ضرورت محسوس ہوتی ہے، تو آپ اسے کسی ایسے شخص کے سامنے اٹھا سکتے ہیں جس کا ماڈریشن رول ہو (مثال کے طور پر، ڈسکارڈ گائیڈ) تاکہ وہ تحقیقات میں مدد کر سکیں اور مناسب جواب پر عمل درآمد کر سکیں۔ + +رپورٹ کرتے وقت، براہ کرم زیادہ سے زیادہ تفصیلات شامل کریں، بشمول مخصوص مثالیں اور ٹائم اسٹیمپس۔ اس سے منصفانہ نتیجہ کو یقینی بنانے میں مدد ملے گی۔ + +### نفاذ {#enforcement} + +شدت کے لحاظ سے، ضابطہ اخلاق کی خلاف ورزی کرنے والے لوگوں کو ethereum.org کمیونٹیز سے انتباہات، عارضی پابندیاں یا مستقل پابندیاں مل سکتی ہیں۔ diff --git a/public/content/translations/ur/community/events/organizing/index.md b/public/content/translations/ur/community/events/organizing/index.md new file mode 100644 index 00000000000..d635e73bb9f --- /dev/null +++ b/public/content/translations/ur/community/events/organizing/index.md @@ -0,0 +1,221 @@ +--- +title: "ایتھیریم ایونٹ کا انعقاد" +description: "ایتھیریم ایونٹ کا انعقاد کیسے کریں" +lang: ur-in +hideEditButton: true +--- + +# ایتھیریم ایونٹ کا انعقاد کیسے کریں {#how-to-organize-an-ethereum-event} + +ایتھیریم ایکو سسٹم کو بڑھانے کے مرکز میں ایک مضبوط اور متحرک کمیونٹی کی تعمیر ہے۔ چاہے آپ میٹ اپس، ورکشاپس، یا ایک مکمل کانفرنس کا انعقاد کرنے کا منصوبہ بنا رہے ہوں، آپ کے ایونٹ کی کامیابی آپ کے مقامی نیٹ ورک کے اندر رابطوں اور مشغولیت پر منحصر ہے۔ یہ گائیڈ آپ کو ایک فعال ایتھیریم کمیونٹی کے لیے بنیاد رکھنے میں مدد کرے گا اور ایک یادگار اور مؤثر کانفرنس کے انعقاد کے عمل میں آپ کی قدم بہ قدم رہنمائی کرے گا۔ + +## خود سے پوچھیں، کیا کوئی ایتھیریم کمیونٹی ہے؟ {#ask-yourself-is-there-an-ethereum-community} + +ایک کامیاب ایتھیریم کانفرنس ایک فعال اور مصروف کمیونٹی پر مبنی ہوتی ہے۔ اگر آپ کے پاس پہلے سے ہی ایک ہے، تو آپ گیم میں آگے ہیں — لیکن اگر آپ کے پاس نہیں ہے، تو ضروری پیشگی قدم اس بنیاد کی تعمیر کرنا ہے۔ ایک سین اور کمیونٹی کے درمیان فرق کرنا ضروری ہے: ایک سین میں ایک مخصوص علاقے میں موجود کمپنیاں اور افراد شامل ہو سکتے ہیں، لیکن وہ اکثر صرف کبھی کبھار مشترکہ اقدامات کے ساتھ آزادانہ طور پر کام کرتے ہیں — جیسے کہ بہت سی جگہوں پر روایتی ویب 2 ایکو سسٹم۔ دوسری طرف، ایک کمیونٹی ایک دوسرے سے جڑے ہوئے لوگوں اور تنظیموں کا ایک نیٹ ورک ہے جو ایک دوسرے کے ساتھ تعاون اور مدد کرتے ہیں، جو اکثر ویب 3 ایکو سسٹم میں دیکھا جاتا ہے۔ + +**آپ کے پہلے اقدامات یہ ہونے چاہئیں:** + +- مقامی اسٹارٹ اپس اور کمپنیوں کو دریافت کریں — اپنے شہر یا ملک میں مضبوط، فعال کمپنیوں کا ہونا اکثر کمیونٹی بنانے کے لیے سب سے اہم شرط ہوتی ہے۔ +- چیک کریں کہ کیا پہلے سے کچھ میٹ اپس ہیں — ethereum.org [ایونٹس پیج](https://ethereum.org/community/events/) +- [ethereum.org ویب سائٹ](https://ethereum.org/community/events/) اور ethereum.org Discord — یہ چیک کرنے کے لیے کہ کیا مقامی ایتھیریم ایونٹس، ڈیولپرز، اور شراکت دار ہیں۔ +- Luma اور Meetup.com — یہ دیکھنے کے لیے کہ کیا آپ کے علاقے میں ایتھیریم سے متعلق ایونٹس یا وسیع تر ویب 3 ایونٹس ہو رہے ہیں۔ +- X — اس جگہ میں مقامی حامیوں یا اثر و رسوخ رکھنے والوں کو تلاش کرنے کی کوشش کریں۔ + +اگر آپ کو ان میں سے زیادہ تر عناصر مل جاتے ہیں، تو یہ ایک مضبوط علامت ہے کہ کمیونٹی بنانے کے حالات موجود ہیں — لیکن ضروری نہیں کہ کمیونٹی پہلے سے ہی موجود ہو۔ اگلا قدم ان اداکاروں کو منظم کرنے، مشغول کرنے اور ان کی پرورش کرنے، تعاون اور طویل مدتی ترقی کے مواقع پیدا کرنے کا اہم کام ہے۔ + +### اگر نہیں، تو اسے کیسے بنایا جائے {#if-not-how-to-build-it} + +اگر آپ کو احساس ہو کہ ان میں سے بہت سے عناصر غائب ہیں، تو پریشان نہ ہوں — شروع سے کمیونٹی بنانا ایک مشکل لیکن گہرا فائدہ مند عمل ہے۔ ایک مضبوط ایتھیریم کمیونٹی راتوں رات ظاہر نہیں ہوتی؛ اس کے لیے صبر، مستقل مزاجی اور ایک واضح وژن کی ضرورت ہوتی ہے۔ یہاں یہ ہے کہ آپ کیسے شروع کر سکتے ہیں: + +- **ایک کمیونیکیشن چینل قائم کریں** — یہ ٹیلی گرام، سگنل، واٹس ایپ، وی چیٹ، یا ڈسکارڈ سرور ہو سکتا ہے، جو بھی آپ کے مقام پر زیادہ مقبول ہو، تاکہ لوگ جڑ سکیں، سوالات پوچھ سکیں، اور وسائل کا اشتراک کر سکیں۔ +- **اپنے ابتدائی اپنانے والوں کو تلاش کریں۔** کچھ ایسے لوگوں کی شناخت کریں جو ایتھیریم اور ویب 3 کے بارے میں پرجوش ہیں۔ وہ آپ کے بنیادی حامی اور ساتھی بن جائیں گے۔ +- **چھوٹے، مستقل ایونٹس کی میزبانی کریں۔** غیر رسمی میٹ اپس، اسٹڈی گروپس، یا ورکشاپس سے شروع کریں۔ مستقل مزاجی کلیدی ہے — چاہے شروع میں گروپ چھوٹا ہی کیوں نہ ہو، باقاعدہ ایونٹس اعتماد اور رفتار پیدا کرتے ہیں۔ +- **مقامی کمپنیوں**، تعلیمی اداروں، یا کو-ورکنگ اسپیسز سے رابطہ کرنے کی کوشش کریں تاکہ وہ آپ کو مفت جگہ فراہم کر سکیں۔ اگر آپ کو اپنے ملک سے اسپیکر نہیں ملتے ہیں، تو آن لائن اسپیکرز کو مدعو کریں لیکن لوگوں کو جسمانی طور پر اکٹھا کریں۔ اپنے سامعین کو جسمانی طور پر ایک جگہ پر موجود رکھنا بہت ضروری ہے۔ +- **موجودہ ٹیک کمیونٹیز کے ساتھ تعاون کریں۔** اگر پہلے سے ہی ڈیولپر گروپس، اسٹارٹ اپ ایکو سسٹمز، یا بلاک چین میٹ اپس موجود ہیں، تو ان کے ساتھ شراکت کریں تاکہ ایتھیریم کے موضوعات متعارف کرائے جا سکیں اور اپنی پہنچ کو بڑھایا جا سکے۔ +- **ایتھیریم کی صلاحیت کے بارے میں تعلیمی مواد شیئر کریں۔** +- **عالمی برادریوں تک پہنچیں۔** تعاون، رہنمائی، اور ممکنہ اشتراک کے لیے دنیا بھر میں قائم ایتھیریم گروپس اور پروجیکٹس سے جڑیں۔ دنیا بھر کی ایتھیریم کمیونٹیز میں کم از کم ایک چیز مشترک ہے: وہ سب مدد کرنے کے لیے بے چین ہیں۔ +- **فنڈنگ حاصل کرنے کی کوشش کریں** — چاہے مقامی ویب 3 کمپنیوں سے ہو یا کچھ گرانٹس پروگرام جیسے کہ [ESP](https://esp.ethereum.foundation/) کے ذریعے۔ + +### اگر ہاں، تو اسے کیسے برقرار رکھا جائے اور بڑھایا جائے {#if-yes-how-to-maintain-and-grow-it} + +ایک بار جب آپ کی ایک قائم شدہ کمیونٹی ہو جائے، تو کام رکتا نہیں ہے — درحقیقت، یہ ابھی شروع ہوا ہے۔ کمیونٹی کو فعال، مصروف اور بڑھتے رہنے کے لیے مسلسل کوشش اور تخلیقی صلاحیتوں کی ضرورت ہوتی ہے۔ کمیونٹی کو شامل رکھنے کے لیے کلیدی عناصر میں سے ایک یہ ہے کہ آپ کو مسلسل نئے فارمیٹس اور آئیڈیاز کے ساتھ تجربہ کرنا چاہیے۔ + +ایک متحرک ایتھیریم کمیونٹی کو برقرار رکھنے کے لیے کچھ حکمت عملیاں یہ ہیں: + +- **اپنے ایونٹ فارمیٹس کو متنوع بنائیں:** صرف ایک قسم کے اجتماع پر قائم نہ رہیں۔ میٹ اپس، مختصر ہیکاتھنز، پینل ڈسکشنز، اور نیٹ ورکنگ ایونٹس کے ساتھ چیزوں کو ملائیں۔ آپ کو-ورک دنوں یا تعلیمی کورسز کا اہتمام کرنے کی کوشش کر سکتے ہیں۔ +- **موضوعات کو متنوع بنائیں:** ایتھیریم صرف ایک ٹیکنالوجی نہیں ہے؛ یہ اقدار کا ایک مجموعہ بھی ہے جس میں قانونی، مارکیٹنگ اور کاروبار شامل ہے۔ +- **اپنی کمیونٹی سے** فیڈ بیک اور آئیڈیاز طلب کریں۔ +- **مختلف سامعین کے طبقات** کے ساتھ مشغول ہوں۔ مواد اور ایونٹس کو تجربے کی مختلف سطحوں کے مطابق بنائیں — پہلی بار ایتھیریم کو دریافت کرنے والے ابتدائی افراد سے لے کر تجربہ کار ڈیولپرز اور کاروباری افراد تک۔ + +سیکھنے، تعاون اور ترقی کے متنوع مواقع فراہم کرکے، آپ اس بات کو یقینی بناتے ہیں کہ آپ کی کمیونٹی فعال رہے اور کانفرنس کے انعقاد جیسی بڑی پہل کے لیے تیار رہے۔ + +## ایونٹ {#event} + +### ایونٹ کا اہتمام کرنے کا صحیح وقت کب ہے؟ {#when-is-the-right-time-to-organize-an-event} + +ایک کامیاب ایتھیریم کانفرنس یا کمیونٹی ایونٹ کے انعقاد کے لیے محتاط وقت اور غور و فکر کی ضرورت ہوتی ہے۔ صحیح لمحہ مختلف عوامل پر منحصر ہوتا ہے جو ایونٹ کی مجموعی کامیابی میں حصہ ڈالتے ہیں۔ + +آپ کو کمیونٹی کی پختگی، مارکیٹ کے حالات، آپ کے پاس ٹیم ہے یا نہیں، اور مقامی منظر (مثلاً ممکنہ اسپانسرز) ہے یا نہیں، ان سب کو مدنظر رکھنا چاہیے۔ + +### KYC — اپنی کمیونٹی کو جانیں {#kyc-know-your-community} + +ایونٹ کا انعقاد کرنے میں سب سے اہم اقدامات میں سے ایک اپنی کمیونٹی کو سمجھنا ہے۔ بالکل اسی طرح جیسے مالیاتی خدمات میں 'اپنے کسٹمر کو جانیں' (KYC)، 'اپنی کمیونٹی کو جانیں' (KYC) کا مطلب ہے اپنے مقامی سامعین کی مخصوص ضروریات، ترجیحات اور خصوصیات کو سمجھنے کے لیے وقت نکالنا۔ یہ سمجھ آپ کو کانفرنس کو اس کی کامیابی اور مطابقت کو یقینی بنانے کے لیے تیار کرنے میں مدد دے گی۔ + +فوری طور پر ایک بڑے پیمانے پر ایونٹ کا ہدف رکھنا پرکشش ہے، لیکن چھوٹے سے شروع کرنا اکثر بہترین طریقہ ہوتا ہے۔ آپ جان جائیں گے کہ آپ کے لیے بہترین حل کیا ہے اگر آپ اپنی کمیونٹی کی حالت اور کچھ دیگر پہلوؤں کا معروضی طور پر جائزہ لیں جو آپ کو غیر متعلقہ لگ سکتے ہیں، جیسے: کیا آپ کا ملک ایک مشہور سیاحتی مقام ہے یا رہائش کی لاگت۔ + +پہلے سال میں، آپ کے سامعین کا سب سے بڑا حصہ ایک مقامی کمیونٹی ہوگا، لہذا پہلے سال میں ایک بڑے ایونٹ کا انعقاد کرنے کے لیے آپ جو کچھ بھی کریں گے وہ اس کمیونٹی کی ضروریات اور سائز کو پورا کرنے والا ہونا چاہیے۔ + +### کہاں سے شروع کریں {#where-to-start} + +جب کانفرنس کا انعقاد کرنے کی بات آتی ہے، تو پہلے اقدامات بہت زیادہ بھاری لگ سکتے ہیں۔ لیکن ایک واضح منصوبے اور ڈھانچے کے ساتھ، آپ اس عمل کو قابل انتظام کاموں میں توڑ سکتے ہیں۔ ہم ان میں سے ہر ایک کو توڑ دیں گے۔ + +ایک منظم نقطہ نظر کے ساتھ شروع کرنا آپ کو منظم رہنے اور اپنے ایونٹ کے انعقاد کے مختلف مراحل سے گزرتے ہوئے تناؤ کو کم کرنے میں مدد کرے گا۔ آپ کا ہر فیصلہ آپ کو ایک ایسا تجربہ فراہم کرنے کے قریب لانا چاہیے جو آپ کی کمیونٹی کی ضروریات کو پورا کرتا ہو۔ + +**سب سے پہلی چیز واضح کرداروں اور ذمہ داریوں کے ساتھ ایک منتظم ٹیم بنانا ہے۔** + +پروگرام بنانے یا اسپانسرز تک پہنچنے سے پہلے ایک اور اہم قدم تاریخ کا انتخاب کرنا ہے۔ اگرچہ یہ ایک آسان قدم لگتا ہے، کچھ اہم عوامل ہیں جن پر آپ کو پہلے سے غور کرنا چاہیے۔ ان میں سے کچھ یہ ہیں: + +- **بڑی کانفرنسوں** یا ایونٹس کے ساتھ متضاد تاریخوں سے گریز کریں +- **مقامی حالات و واقعات پر غور کریں** (جیسے سال کا موسم، بڑی چھٹیاں، وغیرہ) +- **مارکیٹ کے حالات کو مدنظر رکھیں** +- **خود کو ہر چیز کو منظم کرنے کے لیے کافی وقت دیں** — کم از کم نو مہینے + +### ٹیم کیسے جمع کریں {#how-to-assemble-a-team} + +ایسے لوگوں کا انتخاب کریں جو آپ کے وژن کو بانٹتے ہوں اور آپ کی صلاحیتوں کو پورا کرتے ہوں۔ کچھ ٹیمیں اجتماعی طور پر کام کرتی ہیں، جبکہ دیگر کے کردار متعین ہوتے ہیں — معلوم کریں کہ آپ کے لیے کیا بہتر کام کرتا ہے۔ باقاعدہ مواصلات اور واضح توقعات ضروری ہیں۔ اگرچہ ایونٹ کی منصوبہ بندی کے لیے کمیونیکیشن پلیٹ فارمز پر انحصار کرنا پرکشش ہے، ہم تجویز کرتے ہیں کہ کیا کرنا ہے اسے منظم کرنے اور ٹریک کرنے کے لیے ایک ٹاسک مینجمنٹ پلیٹ فارم (جیسے Notion، Basecamp، Trello، Asana، یا یہاں تک کہ پرانے اچھے Google Sheets) کا انتخاب کریں۔ ایک اچھی طرح سے کام کرنے والی اور اچھی طرح سے منظم ٹیم کا ہونا بہت ضروری ہے۔ + +مختلف ایتھیریم آرگنائزر ٹیموں کے اپنی ٹیموں میں مختلف کردار ہوتے ہیں، لیکن ان سب میں مشترک لوگ ہیں جو لاجسٹکس، بجٹ، مارکیٹنگ، پروگرام، ڈیزائن اور شراکت داری پر کام کر رہے ہیں۔ + +### پروگرام: ایک کامیاب ایونٹ کا ایک کلیدی عنصر {#the-program-a-key-element-of-a-successful-event} + +جب واقعی ایک قیمتی اور یادگار کانفرنس کا انعقاد کرنے کی بات آتی ہے، تو **پروگرام ہی سب کچھ ہے**۔ یہ وہ شعبہ نہیں ہے جہاں آپ سمجھوتہ کرنے کے متحمل ہو سکیں۔ جبکہ اسپانسرز اہم ہوتے ہیں اور اکثر ایونٹ کی فنانسنگ کے لیے اہم ہوتے ہیں، سامعین کے تجربے اور ان کو ملنے والی قدر کو ہمیشہ ترجیح دی جانی چاہیے۔ پروموشنل مواد اور لامتناہی اسپانسر پچز سے بھرا ہوا پروگرام آپ کے حاضرین کو الگ تھلگ کر دے گا اور آپ کے ایونٹ کی ساکھ کو کمزور کر دے گا۔ + +ہر سیشن، پینل، اور ورکشاپ کو کمیونٹی کو مطلع، متاثر، اور مشغول کرنا چاہیے۔ اپنے سامعین کی بات سنیں—ان کی دلچسپیوں، ضروریات اور چیلنجوں کو سمجھیں۔ کون سے موضوعات ان کے ساتھ گونجتے ہیں؟ ایک ہی وقت میں، پروگرام کو متحرک رکھنے کے لیے تازہ نقطہ نظر اور اختراعی فارمیٹس متعارف کروائیں۔ معروف اور رجحان ساز موضوعات کو جدید آئیڈیاز کے ساتھ متوازن کریں، ایک جامع ایجنڈا کو یقینی بناتے ہوئے جو ایتھیریم ایکو سسٹم کے مختلف پہلوؤں کا احاطہ کرتا ہے—تکنیکی گہرائیوں اور کمیونٹی بنانے والے سیشنز سے لے کر پالیسی بحثوں اور عملی ورکشاپس تک۔ اس کے علاوہ، کانفرنس کی زبان پر غور کریں — جبکہ زیادہ تر ایتھیریم ایونٹس میں انگریزی پہلے سے طے شدہ ہے، مقامی زبان میں سیشن پیش کرنے سے ایونٹ علاقائی ڈیولپرز اور شائقین کے لیے زیادہ قابل رسائی ہو سکتا ہے۔ + +**اسپیکرز کا انتخاب کرتے وقت، کانفرنس سے کم از کم چھ ماہ قبل کال کھولیں تاکہ اعلیٰ معیار کی گذارشات کو راغب کیا جا سکے اور ایجنڈے کی درستگی کے لیے کافی وقت دیا جا سکے۔** اسپیکر کے انتخاب کے لیے ذمہ دار شخص کو صنعت میں نمایاں تجربہ اور ایکو سسٹم کی گہری سمجھ ہونی چاہیے۔ یہ یقینی بناتا ہے کہ وہ قیمتی، بصیرت انگیز شراکتوں کی نشاندہی کر سکتے ہیں اور مواد کے اعلیٰ معیار کو برقرار رکھ سکتے ہیں۔ + +### مالی مدد کہاں سے حاصل کریں {#where-to-find-financial-support} + +ایک اعلیٰ معیار کی کانفرنس کا انعقاد کرنے میں خاطر خواہ اخراجات آتے ہیں — مقام کا کرایہ، پروموشنل مواد، خوراک و مشروبات، پروڈکشن، اور ان گنت دیگر اخراجات۔ ابتدائی طور پر مالی مدد حاصل کرنا ضروری ہے تاکہ یہ یقینی بنایا جا سکے کہ آپ کا ایونٹ پیشہ ورانہ معیارات پر پورا اترتا ہے اور آپ کے حاضرین کو ایک بہترین تجربہ فراہم کرتا ہے۔ + +#### اسپانسرشپ ڈیک کیسے بنائیں؟ {#how-to-create-a-sponsorship-deck} + +سب سے پہلے، آپ کو ایک ڈیک کی ضرورت ہوگی۔ **دوسرے کانفرنس کے منتظمین سے مشورہ طلب کریں**، یہاں تک کہ ان کے ڈیکس کو شیئر کرنے کے لیے بھی تاکہ آپ اس کی بنیاد پر اپنے پیکجز بنا سکیں۔ پیکجز کی قیمتوں کے تعین میں آپ کو حقیقت پسند ہونا چاہیے اور اخراجات کو پورا کرنے کا مقصد رکھنا چاہیے، نہ کہ پیسہ کمانے کا، خاص طور پر شروع میں۔ + +**ہر اسپانسرشپ ڈیک کو ایونٹ کا ایک واضح اور مجبور کرنے والا جائزہ فراہم کرنا چاہیے**، اس بات کو یقینی بناتے ہوئے کہ ممکنہ اسپانسرز اس کے دائرہ کار، فوکس اور قدر کو سمجھیں۔ بنیادی باتوں سے شروع کریں—مقام، تاریخ، اور منتظم ٹیم کے بارے میں تفصیلات—ساکھ قائم کرنے کے لیے۔ پھر، ایونٹ کے بنیادی فوکس کو نمایاں کریں، کیونکہ مختلف ایتھیریم کانفرنسیں مختلف سامعین کو پورا کرتی ہیں۔ کچھ بہت زیادہ بلڈر پر مبنی ہیں، جن میں گہری تکنیکی بحثیں شامل ہیں، جبکہ دیگر DeFi، DAOs، یا پالیسی موضوعات پر زیادہ توجہ دے سکتے ہیں۔ + +صرف ایونٹ کی وضاحت سے آگے، واضح توقعات مقرر کریں۔ **حاضرین کی متوقع تعداد اور پہلے سے تصدیق شدہ کسی بھی کلیدی اسپیکرز کا خاکہ پیش کریں**، کیونکہ اس سے اسپانسرز کو اپنی ممکنہ پہنچ کا اندازہ لگانے میں مدد ملتی ہے۔ سب سے اہم بات، واضح طور پر بیان کریں کہ وہ اپنی اسپانسرشپ کے بدلے کیا حاصل کریں گے—بوتھ کی جگہ، بولنے کے مواقع، سوشل میڈیا پروموشن، برانڈنگ کی مرئیت، یا خصوصی نیٹ ورکنگ تک رسائی۔ ایک اچھی طرح سے منظم ڈیک نہ صرف مطلع کرتا ہے بلکہ ممکنہ اسپانسرز کو آپ کے ایونٹ کا حصہ بننے کے موقع کے بارے میں پرجوش بھی کرتا ہے۔ + +#### آپ کے ایونٹ کی حمایت کون کر سکتا ہے؟ {#who-might-support-your-event} + +اپنے شہر یا ملک میں ایتھیریم اور وسیع تر ٹیک ایکو سسٹم کے اندر کمپنیوں سے رابطہ کرکے شروع کریں۔ ان **تنظیموں کی اکثر مقامی ایونٹس کی حمایت میں گہری دلچسپی ہوتی ہے** جو کمیونٹی کی ترقی اور جدت کو فروغ دیتے ہیں۔ وہ مقامی ایکو سسٹم میں سرمایہ کاری کی قدر کو پہچاننے اور آپ کی کانفرنس کو ہنر، شراکت داروں اور صارفین سے جڑنے کے ایک موقع کے طور پر دیکھنے کا زیادہ امکان رکھتے ہیں۔ + +ایک بار جب آپ مقامی مدد حاصل کر لیں، تو ویب 3 اسپیس میں عالمی کھلاڑیوں تک اپنی پہنچ کو بڑھائیں۔ **قائم شدہ پروٹوکول، DAOs، اور ایکو سسٹم فنڈز اکثر کمیونٹی سے چلنے والے ایونٹس کے لیے بجٹ مختص کرتے ہیں**۔ یہ پہلی بار منتظمین کے لیے تھوڑا مشکل ہو سکتا ہے، کیونکہ انہوں نے ابھی تک دکھانے کے لیے کوئی ٹریک ریکارڈ نہیں بنایا ہے لیکن ایک مجبور اسپانسرشپ پیکیج بنانے کی کوشش کریں جو آپ کے ایونٹ کی حمایت کے فوائد کو واضح طور پر بیان کرتا ہو — برانڈ کی مرئیت، بولنے کے مواقع، اور ایک ٹارگٹڈ سامعین کے ساتھ بامعنی مشغولیت۔ اپنی منفرد قدر تلاش کرنے کی کوشش کریں جو دوسروں کے پاس نہ ہو۔ + +#### اپنے ایونٹ کو فنڈ دینے کے متبادل طریقے {#alternative-forms-of-funding-your-event} + +گرانٹس ایک اور ممکنہ فنڈنگ کا ذریعہ ہے جسے بہت سے منتظمین نظر انداز کر دیتے ہیں۔ Ethereum فاؤنڈیشن کے [ایکو سسٹم سپورٹ پروگرام](https://esp.ethereum.foundation/) (ESP) اور [دیگر گرانٹ اقدامات](https://ethereum.org/community/grants/#ethereum-grants) جیسے پروگرام کمیونٹی سے چلنے والے ایونٹس کی حمایت کے لیے موجود ہیں۔ + +مالی اسپانسرشپ سے ہٹ کر، خاص طور پر خوراک اور مشروبات کے لیے، ان-کائنڈ پارٹنرشپس پر غور کریں۔ وہ برانڈز جو مقامی ثقافت یا ٹیک کمیونٹی کے ساتھ ہم آہنگ ہیں آپ کے ایونٹ کے لیے بہترین شراکت دار ہو سکتے ہیں۔ کافی برانڈز، مشروبات کمپنیاں، یا یہاں تک کہ مقامی پزیریا ایونٹ میں مرئیت کے بدلے مصنوعات فراہم کرنے پر راضی ہو سکتے ہیں۔ یہ تعاون حاضرین کے تجربے کو بڑھاتے ہوئے لاگت کو کم کرنے میں مدد کر سکتے ہیں۔ + +چونکہ ہم مالیات کے بارے میں بات کر رہے ہیں، یہ یاد رکھیں: ہر ڈالر جو آپ ایک غیر معمولی حاضرین کا تجربہ بنانے میں لگاتے ہیں وہ تیزی سے ادا کرے گا۔ اعلیٰ معیار کی پروڈکشن، آرام دہ مقامات، سوچ سمجھ کر بنایا گیا سویگ، اور اچھی طرح سے منظم سائیڈ ایونٹس ایک یادگار تجربے میں حصہ ڈالتے ہیں جس کے بارے میں شرکاء کانفرنس ختم ہونے کے بہت بعد تک بات کریں گے۔ خوش حاضرین آپ کے سب سے بڑے حامی بن جاتے ہیں اور آپ کے ایونٹ کی طویل مدتی کامیابی کو یقینی بناتے ہیں۔ + +### لاجسٹکس {#logistics} + +فنڈنگ حاصل کرنے کے متوازی طور پر آپ کی بنیادی توجہ لاجسٹکس پر ہونی چاہیے۔ ایک اچھی طرح سے منظم کانفرنس میں مقام کے سیٹ اپ سے لے کر حاضرین کے تجربے تک، متعدد شعبوں میں باریک بینی سے منصوبہ بندی کی ضرورت ہوتی ہے۔ ایونٹ کے انعقاد میں ٹھوس تجربہ رکھنے والا کوئی شخص — ضروری نہیں کہ ویب 3 ایونٹس، بلکہ عام طور پر ایونٹس — ایک بہت بڑا فرق پیدا کر سکتا ہے۔ ایک تجربہ کار لاجسٹکس لیڈ ممکنہ مسائل کا پہلے سے اندازہ لگا سکتا ہے اور انہیں مسائل بننے سے پہلے حل کر سکتا ہے، جس سے وقت، پیسہ اور تناؤ کی بچت ہوتی ہے۔ + +لاجسٹکس کے لیے ذمہ دار شخص کو ایک مقام، پروڈکشن کمپنی، اور خوراک، مشروبات، اور مرچ کے لیے مختلف وینڈرز کا انتخاب کرنا چاہیے، ساتھ ہی ایک استعمال میں آسان آن لائن ٹکٹنگ سسٹم بھی جو حاضرین کو کرپٹو میں بھی رجسٹر کرنے اور ادائیگی کرنے کی اجازت دیتا ہے۔ + +### مقام کا انفراسٹرکچر {#location-infrastructure} + +اپنی کانفرنس کے لیے مقام کا انتخاب کرتے وقت، مقام سے آگے سوچنا اور وسیع تر شہر اور ملک کے انفراسٹرکچر پر غور کرنا ضروری ہے۔ موسم، نقل و حرکت، حفاظت، اور سیاسی ماحول جیسے عوامل حاضرین کے تجربے کو تشکیل دینے میں ایک بہت بڑا کردار ادا کرتے ہیں۔ + +کم معروف مقامات کے لیے، یہ خاص طور پر اہم ہو جاتا ہے۔ دنیا بھر سے حاضرین اور اسپانسرز کو یہ اعتماد محسوس کرنے کی ضرورت ہے کہ وہ آسانی اور محفوظ طریقے سے سفر کر سکتے ہیں۔ ائیرپورٹ کنیکٹیویٹی، پبلک ٹرانسپورٹیشن، اور رہائش کے اختیارات جیسے پہلوؤں پر غور کریں۔ اس خطے کے ثقافتی اور سیاسی ماحول پر غور کرنا بھی دانشمندی ہے تاکہ کسی بھی ایسی پیچیدگی سے بچا جا سکے جو بین الاقوامی شرکاء کو روک سکتی ہے، جیسے ویزا پالیسی۔ + +### ایونٹ کو کیسے فروغ دیا جائے {#how-to-promote-the-event} + +اپنے ایونٹ کو مؤثر طریقے سے فروغ دینا صحیح سامعین کو راغب کرنے اور جوش و خروش پیدا کرنے کی کلید ہے۔ ایک سوچی سمجھی پروموشن حکمت عملی اس بات کو یقینی بناتی ہے کہ آپ کی کانفرنس کو وہ مرئیت اور مشغولیت ملے جس کی وہ مستحق ہے۔ ڈیزائن آپ کے برانڈ میں بھی ایک اہم کردار ادا کرتا ہے، لہذا آپ کو یقینی طور پر اس کے لیے بھی بجٹ بنانا چاہیے۔ + +#### سوشل میڈیا {#social-media} + +X.com آپ کے سوشل میڈیا پروموشن کی ریڑھ کی ہڈی ہوگی۔ وہاں پوسٹ کرنے میں فعال اور مستقل رہنے کی کوشش کریں، لیکن مختلف گفتگوؤں میں بھی مشغول ہوں، اپنے ذاتی اکاؤنٹ اور اپنی تنظیم کے اکاؤنٹ دونوں کے ساتھ۔ + +اگرچہ LinkedIn پروموشن کے لیے سب سے واضح انتخاب نہیں لگتا، آپ وہاں بالکل مختلف سامعین، یا یہاں تک کہ کچھ اسپانسرز تک پہنچ سکتے ہیں۔ + +#### دیگر ایتھیریم کمیونٹیز کے ساتھ شراکت داری {#partnerships-with-other-ethereum-communities} + +مختلف ایتھیریم آرگنائزرز کے ساتھ شراکت داری موجودہ نیٹ ورکس میں ٹیپ کرکے آپ کی پہنچ کو بڑھانے میں مدد کر سکتی ہے، خاص طور پر جب آپ شروع سے شروع کر رہے ہوں۔ کمیونٹی ڈسکاؤنٹ پیش کریں، دوسرے ایونٹس کے ساتھ کراس پروموٹ کریں، اور شراکت داروں کو سائیڈ ایونٹس یا ورکشاپس کی مشترکہ میزبانی کے لیے مدعو کریں۔ + +#### یونیورسٹی آؤٹ ریچ {#university-outreach} + +ایونٹ کو فروغ دینے کے لیے طلباء کلبوں یا پروفیسروں کے ذریعے شہر میں تکنیکی اور معاشیات کے شعبوں سے رابطہ کریں۔ یونیورسٹیوں کے ساتھ مشغول ہونا نوجوان ٹیلنٹ، محققین، اور مستقبل کے صنعت کے پیشہ ور افراد کو راغب کرنے میں مدد کر سکتا ہے، جس سے اکیڈمیا اور ایتھیریم ایکو سسٹم کے درمیان ایک مضبوط تعلق کو فروغ ملتا ہے۔ یہ خاص طور پر بہت اچھا ہے اگر آپ ایک ہیکاتھون کا اہتمام کر رہے ہیں، کیونکہ طلباء اکثر تازہ آئیڈیاز، جوش و خروش، اور ایک مضبوط تکنیکی بنیاد لاتے ہیں۔ + +#### میڈیا {#media} + +ایونٹ کوریج کے لیے ویب 3 پر مرکوز میڈیا آؤٹ لیٹس اور نیوز لیٹرز تک پہنچیں۔ اگرچہ Web3 میڈیا اپنے PR مضامین کے لیے ادائیگی کی توقع کرتا ہے، آپ انہیں مفت ٹکٹ یا کچھ اعلیٰ پروفائل اسپیکرز اور اسپانسرز کے ساتھ انٹرویو پیش کر سکتے ہیں اگر آپ کے پاس ادا شدہ پروموشن کے لیے بجٹ نہیں ہے۔ ایک پریس ریلیز اور کچھ ویژولز کے ساتھ ایک PR پیکیج بنائیں جو سوشل میڈیا یا کسی ویب سائٹ پر مختلف فارمیٹس میں پروموشن کے لیے تیار ہو۔ اس کے علاوہ، مقامی صحافیوں یا یہاں تک کہ مواد تخلیق کاروں (جب تک کہ ان کی اچھی ساکھ ہو) تک دائرہ کار کو وسیع کریں جو ٹیک کا احاطہ کر سکتے ہیں، کیونکہ یہ ایونٹ کو بڑے سامعین کے سامنے پیش کرنے کے لیے اہم ہو سکتا ہے۔ اس سے کرپٹو انڈسٹری اور وسیع تر عوام کے درمیان فرق کو پر کرنے میں مدد ملتی ہے، جس سے مرکزی دھارے کی ٹیک اور کاروباری برادریوں سے دلچسپی پیدا ہوتی ہے۔ + +### کیا آپ کو بھی ہیکاتھون کا اہتمام کرنا چاہیے؟ {#should-you-organize-a-hackathon-as-well} + +ہیکاتھون کا اہتمام کرنا فائدہ مند ہو سکتا ہے کیونکہ ہیکاتھون ڈیولپر کمیونٹی کو مشغول کرنے اور جدت کو فروغ دینے کا ایک بہترین طریقہ ہو سکتا ہے۔ یہ تعاون کرنے اور پروجیکٹس بنانے کے لیے عملی مواقع بھی فراہم کرتا ہے، جو ایکو سسٹم کے لیے ٹھوس نتائج کا باعث بن سکتے ہیں۔ ہیکاتھون ان ڈیولپرز کو راغب کرتے ہیں جو عام طور پر کانفرنسوں میں شرکت نہیں کرتے لیکن نئے آئیڈیاز بنانے اور جانچنے کے چیلنج کے خواہشمند ہوتے ہیں۔ اگر آپ کی کانفرنس کا مقصد ڈیولپرز، جدت، اور عملی پروجیکٹس ہیں، تو ہیکاتھون کی میزبانی ایک قدرتی فٹ ہے۔ + +لیکن، ایک کا اہتمام کرنے سے پہلے، غور کریں کہ کیا آپ کے پاس کافی وسائل اور وقت ہے۔ **ایک ہیکاتھون کو وقت، افرادی قوت، اور مالی سرمایہ کاری کے لحاظ سے خاطر خواہ وسائل کی ضرورت ہوتی ہے**۔ یقینی بنائیں کہ آپ کے پاس اسے سنبھالنے کے لیے ایک وقف ٹیم ہے، خاص طور پر اگر آپ کانفرنس کا بھی انتظام کر رہے ہیں۔ اس کے علاوہ، چیک کریں کہ کیا آپ کی کمیونٹی میں دلچسپی ہے۔ اگر آپ کی کمیونٹی زیادہ بلڈر پر مبنی ہے، تو شاید اسے منظم کرنا معنی خیز ہے۔ + +اگرچہ اسے منظم کرنے کے بہت سے فوائد ہیں، اس بات کو مدنظر رکھیں کہ، کانفرنس کے پیمانے پر منحصر ہے، ایک ہیکاتھون شامل کرنا بھاری پڑ سکتا ہے۔ آپ کو یہ اندازہ لگانا چاہیے کہ کیا دونوں کا انتظام کسی ایک کے معیار کو کمزور کرے گا۔ آپ ایک چھوٹے، مرکوز ہیکاتھون کا انتخاب کر سکتے ہیں یا مختلف مہینوں میں ایونٹس کو ترتیب دے سکتے ہیں۔ + +### (تقریباً ناگزیر) چیلنجز جن کا آپ کو سامنا کرنا پڑے گا {#almost-inevitable-challenges-that-you-will-face} + +کانفرنس کا انعقاد کرتے وقت سب سے بڑے چیلنجوں میں سے ایک، خاص طور پر ایتھیریم اسپیس میں، کافی فنڈنگ حاصل کرنا ہے۔ **بہت سے ایونٹ کے منتظمین مقام کے اخراجات**، کیٹرنگ، اور دیگر لاجسٹیکل اخراجات کو پورا کرنے کے لیے درکار سرمایہ اکٹھا کرنے کے لیے جدوجہد کرتے ہیں۔ اسپانسرشپ اکثر ضروری ہوتی ہے، لیکن تعلقات استوار کرنے اور کمپنیوں کو آپ کے ایونٹ میں سرمایہ کاری کرنے کے لیے قائل کرنے میں وقت لگ سکتا ہے۔ مزید برآں، مارکیٹ کے مندی کے دوران اسپانسرز کو راغب کرنے میں دشواری بڑھ سکتی ہے، کیونکہ کمپنیاں غیر بنیادی سرگرمیوں میں سرمایہ کاری کرنے کے لیے کم تیار ہو سکتی ہیں۔ + +بجٹ کا مؤثر طریقے سے انتظام کرنا کلیدی ہے۔ **غیر متوقع اخراجات**، جیسے آخری منٹ میں مقام کی تبدیلیاں اور اضافی ایونٹ ٹیک کی ضروریات، آپ کے بجٹ کو تیزی سے اڑا سکتی ہیں۔ + +نئے ایونٹس کے لیے، **اعلیٰ معیار کے اسپیکرز حاصل کرنا خاص طور پر مشکل ہو سکتا ہے**۔ ایتھیریم اسپیس میں قائم شدہ فکری رہنماؤں یا اثر و رسوخ رکھنے والوں کے پاس پہلے سے ہی مکمل شیڈول ہو سکتے ہیں اور وہ ثابت شدہ ٹریک ریکارڈ کے بغیر کسی نئے ایونٹ کے لیے عہد کرنے میں ہچکچا سکتے ہیں۔ ایونٹ سے بہت پہلے نیٹ ورکنگ اور ممکنہ اسپیکرز تک پہنچنے میں وقت گزارنے کے لیے تیار رہیں۔ + +اس کے علاوہ، جب اسپیکرز کی بات آتی ہے، تو ان کے ساتھ واضح اور مسلسل مواصلات رکھیں — پریزنٹیشن بھیجنے کی آخری تاریخ مقرر کریں اور کسی بھی آخری منٹ کی تبدیلیوں سے گریز کریں۔ + +ایک کامیاب کانفرنس کے لیے ایک وقف ٹیم کی ضرورت ہوتی ہے جو لاجسٹکس، مارکیٹنگ، اسپانسرشپ، تکنیکی مدد، اور حاضرین کے انتظام کو سنبھال سکے۔ ٹیک ایونٹس کے انعقاد میں تجربہ رکھنے والے افراد کو تلاش کرنا مشکل ہو سکتا ہے، خاص طور پر اگر آپ ایک چھوٹے بجٹ کے ساتھ کام کر رہے ہیں یا، زیادہ تر معاملات میں، بغیر بجٹ کے، لیکن رضاکارانہ بنیادوں پر۔ + +### آپ کو یہ اکیلے نہیں کرنا چاہیے۔ آپ کو رضاکاروں کی ضرورت ہے۔ {#you-shouldnt-do-it-alone-you-need-volunteers} + +ایک ایتھیریم ایونٹ کا انعقاد کرنے کے لیے لاجسٹکس، رجسٹریشن، اسپیکر کوآرڈینیشن، حاضرین کی مدد، اور بہت کچھ سنبھالنے کے لیے ایک متنوع اور وقف ٹیم کی ضرورت ہوتی ہے۔ ٹیم کے سائز صرف 3 سے 15 افراد تک ہونے کے ساتھ، یہ واضح ہو جاتا ہے کہ ایونٹ کے ہموار چلانے کے لیے رضاکار ضروری ہیں۔ + +رضاکار اکثر بہت سی کانفرنسوں کی ریڑھ کی ہڈی ہوتے ہیں، جو اہم مدد فراہم کرتے ہیں، خاص طور پر جب آپ محدود بجٹ کے ساتھ کام کر رہے ہوں۔ وہ رجسٹریشن ڈیسک سنبھالنے سے لے کر ایونٹ سیٹ اپ میں مدد کرنے تک ہر چیز کو سنبھال سکتے ہیں، اس بات کو یقینی بناتے ہوئے کہ ایونٹ ہر ممکن حد تک ہموار طریقے سے چلے۔ + +جبکہ رضاکاروں کو مالی معاوضہ پیش کرنا مشکل ہے، انہیں قدر کی کوئی چیز فراہم کرنا ضروری ہے جو ان کے تجربے کو قابل قدر بنائے گی۔ انہیں نیٹ ورکنگ کے مواقع، مہارت کی ترقی، کچھ خصوصی مراعات، سرٹیفکیٹ یا سفارش کے خطوط پیش کرنے پر غور کریں۔ + +### ایونٹ کے منتظمین کے لیے تعمیل کے لوازمات {#compliance-essentials-for-event-organizers} + +ایونٹ کا انعقاد کرتے وقت، کئی ضروری قانونی اور لاجسٹیکل تحفظات کو ذہن میں رکھنا ضروری ہے: + +- **اسپانسرشپ کا معاہدہ** – یقینی بنائیں کہ آپ کے پاس اسپانسرز کے لیے ایک واضح معاہدہ ہے، جس میں ایک اچھی طرح سے بیان کردہ منسوخی کی پالیسی بھی شامل ہے۔ +- **ضابطہ اخلاق** – ایک ضابطہ اخلاق تیار کریں جو مخصوص ایونٹ کی قسم (کانفرنس/ہیکاتھون، ہیکر ہاؤسز وغیرہ) کے مطابق ہو۔ +- **رازداری کی پالیسی** – ڈیٹا پروٹیکشن ریگولیشنز اور امیج کی تعمیل کے لیے اپنی ویب سائٹ کے لیے ایک رازداری کی پالیسی کا مسودہ تیار کریں۔ +- **مقامی حکام کو اطلاع** – یہاں تک کہ اگر آپ کا ایونٹ ایک بند اجتماع ہے، تو اسے مقامی پولیس اسٹیشن کو رپورٹ کرنے کا مشورہ دیا جاتا ہے۔ +- **ٹکٹنگ کا معاہدہ** – شرائط اور ذمہ داریوں کو واضح کرنے کے لیے اپنے ٹکٹنگ سروس فراہم کنندہ کے ساتھ ایک رسمی معاہدہ قائم کریں۔ +- **ریگولیٹری تعمیل** – پہلے سے چیک کریں کہ جس ملک میں آپ کانفرنس کی میزبانی کر رہے ہیں وہاں کرپٹو انڈسٹری کے لیے مخصوص ضوابط یا پابندیاں ہیں۔ +- **مرچنڈائز کے لیے کسٹمز کلیئرنس** – اگر آپ اسپانسر مرچنڈائز درآمد کر رہے ہیں، تو اس عمل کو مؤثر طریقے سے سنبھالنے کے لیے ایک کسٹمز ایجنٹ کی خدمات حاصل کرنے کی سفارش کی جاتی ہے۔ +- **فوٹوگرافی اور میڈیا پالیسی** – فوٹوگرافی اور میڈیا کوریج پر رہنما خطوط کو واضح طور پر بیان کریں، اس بات کو یقینی بناتے ہوئے کہ شرکاء کو رضامندی اور آپٹ آؤٹ کے اختیارات کے بارے میں مطلع کیا جائے۔ + +## ایونٹ کے بعد: آگے کیا؟ {#what's-next} {#after-the-event-whats-next} + +ایونٹ کے اختتام کے بعد، حاضرین، اسپیکرز، اور اسپانسرز سے فیڈ بیک اکٹھا کرنا اور ایک اندرونی رپورٹ بنانا بہت ضروری ہے تاکہ آپ مستقبل کے ایونٹس کے لیے بہتر طور پر تیار ہو سکیں۔ اس سے یہ شناخت کرنے میں مدد ملتی ہے کہ کیا اچھا ہوا اور کہاں بہتری کی جا سکتی ہے۔ قیمتی بصیرتیں اکٹھا کرنے کے لیے سروے یا ون آن ون انٹرویوز کا استعمال کریں جو مستقبل کی تکرار کی رہنمائی کریں گے۔ کسی بھی غلطی یا ناکارہی کے شعبوں کا جائزہ لینے کے لیے وقت نکالیں، کیونکہ انہیں اگلی کانفرنس میں بچایا جا سکتا ہے، جس سے عمل ہموار ہو جاتا ہے۔ + +کلیدی بات یہ ہے کہ رفتار کو زندہ رکھا جائے۔ اپنی کمیونٹی کے ساتھ مشغول رہنا جاری رکھیں، ان کے فیڈ بیک کی بنیاد پر آپ کی پیشرفت کے بارے میں اپ ڈیٹس شیئر کریں، اور اگلے ایونٹ کے لیے جوش و خروش پیدا کریں۔ اس تعلق کو برقرار رکھتے ہوئے، آپ اس بات کو یقینی بناتے ہیں کہ کانفرنس کا اثر ایونٹ سے آگے بڑھے، تعلقات کو مضبوط بنائے اور مستقبل کی کامیابی کے لیے اسٹیج تیار کرے۔ + +## اعتراف {#acknowledgement} + +ان تمام لوگوں کا بہت بہت شکریہ جنہوں نے اپنی بصیرت کا اشتراک کرکے اس مضمون میں حصہ ڈالا: سلاوو فابسیک از ETHBratislava؛ لولا از ETH Kipu اور ETH Latam؛ تنجا ملاڈینووک از ETH Belgrade، جوآن ڈیوڈ از Ethereum Bogota؛ مونیکا زاجک از ETHWarsaw؛ رافیلی اوریفائس از NapulETH؛ ژاؤ وو(لنگ) از ETH ریاض؛ مارکو از urbe.eth؛ کاؤلان والش از ETH Dublin؛ ایلکس میلز از ETHCluj؛ اور سٹینکو ڈیوک از ETH سلووینیا۔ + +## وسائل {#resources} + +پوڈ کاسٹ: A-Z سے ETH ایونٹ کا انعقاد اور فروغ کیسے کریں: + +- [ETHWarsaw کیس اسٹڈی، از آؤٹ آف آرڈینری](https://www.youtube.com/watch?v=io2Dx1ouz8o) + +ٹویٹر اسپیس: + +- [ETH کمیونٹی AMA](https://x.com/NapulETH/status/1905732699094151623) + +مضامین: + +- [ETHKL کی تعمیر، از ڈینی ایچ۔](https://sekto.tech/ethkl24) +- [POKT ایونٹس پلے بک](https://docs.pokt.network/community/pokt-events-playbook) diff --git a/public/content/translations/ur/community/get-involved/index.md b/public/content/translations/ur/community/get-involved/index.md new file mode 100644 index 00000000000..f5a0668d519 --- /dev/null +++ b/public/content/translations/ur/community/get-involved/index.md @@ -0,0 +1,132 @@ +--- +title: "میں کس طرح شامل ہو سکتا ہوں؟" +description: "ایتھیریم کمیونٹی میں شامل ہونے کا طریقہ۔" +lang: ur-in +--- + +# میں کس طرح شامل ہو سکتا ہوں؟ {#get-involved} + +ایتھیریم کمیونٹی میں کئی مختلف پس منظر اور مہارتوں کے حامل لوگ شامل ہیں۔ چاہے آپ ایک ڈیولپر ہوں، ایک فنکار ہوں، یا ایک اکاؤنٹنٹ ہوں، شامل ہونے کے طریقے موجود ہیں۔ یہاں تجاویز کی ایک فہرست ہے جو آپ کو شروع کرنے میں مدد دے سکتی ہے۔ + +ہمارے [ضابطہ اخلاق](/community/code-of-conduct) میں ethereum.org کے مشن اور اقدار کے بارے میں پڑھ کر شروعات کریں۔ + +## ڈیولپرز ‍ {#developers} + +- [ethereum.org/developers/](/developers/) پر ایتھیریم کے بارے میں جانیں اور اسے آزمائیں۔ +- اپنے قریب [ETHGlobal](http://ethglobal.co/) ہیکاتھون میں شرکت کریں! +- [اپنی مہارت کے شعبے یا پسند کی پروگرامنگ زبان سے متعلق پروجیکٹس](/developers/docs/programming-languages/) دیکھیں۔ +- [Consensus and Execution Layer کالز](https://www.youtube.com/@EthereumProtocol/streams) دیکھیں یا ان میں حصہ لیں۔ +- [Ecosystem Support Program's wishlist](https://esp.ethereum.foundation/wishlist/) - ٹولنگ، ڈاکیومنٹیشن، اور انفراسٹرکچر کے وہ شعبے جہاں ایتھیریم ایکو سسٹم سپورٹ پروگرام فعال طور پر گرانٹ کی درخواستیں طلب کر رہا ہے۔ +- [Web3Bridge](https://www.web3bridgeafrica.com) - پورے افریقہ میں سینکڑوں ڈیولپرز اور کمیونٹی ممبران کی شناخت، تربیت اور مدد کرنے کے لیے ان کی پہل میں خواہشمند web3 کمیونٹی میں شامل ہوں۔ +- [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) میں شامل ہوں۔ +- [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu) میں شامل ہوں۔ + +## محققین اور ماہرین تعلیم ‍ {#researchers-and-academics} + +کیا آپ کا پس منظر ریاضی، کرپٹوگرافی، یا اقتصادیات میں ہے؟ آپ کو ایتھیریم ایکو سسٹم کے اندر کیے جانے والے کچھ جدید ترین کام میں دلچسپی ہو سکتی ہے۔ + +- [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) میں شامل ہوں۔ +- ایتھیریم امپروومنٹ پروپوزل لکھیں یا اس کا جائزہ لیں۔ + - ایک EIP لکھیں۔ + 1. [Ethereum Magicians](https://ethereum-magicians.org) پر اپنا خیال جمع کرائیں۔ + 2. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) پڑھیں - **جی ہاں، یہ _پوری_ دستاویز ہے۔** + 3. EIP-1 میں دی گئی ہدایات پر عمل کریں۔ اپنا ڈرافٹ لکھتے وقت اس کا حوالہ دیں۔ + - [EIP ایڈیٹر](https://eips.ethereum.org/EIPS/eip-5069) بننے کا طریقہ سیکھیں۔ + - آپ ابھی EIPs کا پیئر-ریویو کر سکتے ہیں! [`e-review` ٹیگ کے ساتھ کھلے PRs](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review) دیکھیں۔ `discussion-to` لنک پر تکنیکی فیڈبیک فراہم کریں۔ + - [EIP گورننس](https://github.com/ethereum-cat-herders/EIPIP) میں حصہ لیں۔ + - [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu) میں شامل ہوں۔ + - [EIPs کے بارے میں مزید](/eips/) +- [Challenges.ethereum.org](https://challenges.ethereum.org/) - اعلیٰ قدر والی ریسرچ باؤنٹیز کا ایک سلسلہ، جہاں آپ >$100,000 USD کما سکتے ہیں۔ +- [Ethresear.ch](https://ethresear.ch) - تحقیق کے لیے ایتھیریم کا بنیادی فورم، اور کرپٹو اکنامکس کے لیے دنیا کا سب سے بااثر فورم۔ +- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - محققین کے ساتھ ایک جاری سوال و جواب کا سلسلہ۔ جیسے ہی ہر اگلا حصہ کھلتا ہے، کوئی بھی سوالات پوسٹ کر سکتا ہے۔ +- [Ecosystem Support Program's wishlist](https://esp.ethereum.foundation/wishlist/) - تحقیق کے وہ شعبے جہاں ایتھیریم ایکو سسٹم سپورٹ پروگرام فعال طور پر گرانٹ کی درخواستیں طلب کر رہا ہے۔ +- [AllWalletDevs](https://allwallet.dev) - ایتھیریم ڈیولپرز، ڈیزائنرز، اور دلچسپی رکھنے والے صارفین کے لیے ایک فورم تاکہ وہ باقاعدگی سے اکٹھے ہوں اور والیٹس پر تبادلہ خیال کریں۔ + +[تحقیق کے مزید فعال شعبوں کو دریافت کریں](/community/research/)۔ + +## غیر تکنیکی مہارتیں ‍ {#non-technical} + +اگر آپ ڈیولپر نہیں ہیں، تو یہ جاننا مشکل ہو سکتا ہے کہ ایتھیریم میں کہاں سے شروعات کی جائے۔ یہاں کچھ تجاویز ہیں، ساتھ ہی مخصوص پیشہ ورانہ پس منظر کے لیے وسائل بھی ہیں۔ + +### اپنے شہر میں ایک میٹ اپ منعقد کریں {#meetups} + +- یقین نہیں ہے کہ کیسے شروعات کریں؟ [BUIDL نیٹ ورک](https://consensys.net/developers/buidlnetwork/) مدد کر سکتا ہے۔ + +### ایتھیریم کے بارے میں مواد لکھیں {#write-content} + +- ایتھیریم کو اچھے مصنفین کی ضرورت ہے جو اس کی قدر کو سادہ زبان میں بیان کر سکیں۔ +- اپنے مضامین شائع کرنے کے لیے تیار نہیں ہیں؟ کمیونٹی کے وسائل پر موجودہ مواد میں حصہ ڈالنے پر غور کریں، یا [ethereum.org کے لیے نئے مواد کی تجویز دیں](/contributing/)! + +### کمیونٹی کالز کے لیے نوٹس لینے کی پیشکش کریں {#take-notes} + +- بہت سی اوپن سورس کمیونٹی کالز ہوتی ہیں، اور نوٹس لینے والوں کا ہونا ایک بہت بڑی مدد ہے۔ اگر آپ دلچسپی رکھتے ہیں تو، [Ethereum Cat Herders discord](https://discord.com/invite/Nz6rtfJ8Cu) میں شامل ہوں، اور اپنا تعارف کرائیں! + +### ایتھیریم کے مواد کا اپنی مادری زبان میں ترجمہ کریں {#translate-ethereum} + +- ethereum.org ایک ٹرانسلیشن پروگرام کو برقرار رکھتا ہے جو ویب سائٹ اور دیگر وسائل کا کئی مختلف زبانوں میں ترجمہ کرتا ہے۔ +- [یہاں](/contributing/translation-program) شامل ہونے کا طریقہ معلوم کریں۔ + +### ایک نوڈ چلائیں {#run-a-node} + +ایتھیریم کو مزید وکندریقرت بنانے میں مدد کرنے کے لیے ہزاروں نوڈ آپریٹرز میں شامل ہوں۔ + +- [نوڈ چلانے کے طریقے کے بارے میں مزید](/developers/docs/nodes-and-clients/run-a-node/) + +### اپنا ETH اسٹیک کریں {#staking} + +اپنا ETH اسٹیک کر کے آپ ایتھیریم نیٹ ورک کو محفوظ بنانے میں مدد کرتے ہوئے انعامات کما سکتے ہیں۔ + +- [اسٹیکنگ کے بارے میں مزید](/staking/) + +### پروجیکٹس کو سپورٹ کریں {#support-projects} + +ایتھیریم ایکو سسٹم عوامی اشیاء اور مؤثر پروجیکٹس کو فنڈ دینے کے مشن پر ہے۔ بہت چھوٹے عطیات کے ساتھ آپ اپنی حمایت کا اظہار کر سکتے ہیں اور اہم کام کو پایہ تکمیل تک پہنچانے کی اجازت دے سکتے ہیں۔ + +- [Gitcoin](https://gitcoin.co/fund) +- [clr.fund](https://clr.fund/#/about) + +## مالیاتی پیشہ ور اور اکاؤنٹنٹس ‍ {#financial-professionals} + +- ایتھیریم "وکندریقرت فنانس" ایکو سسٹم کا گھر ہے - پروٹوکولز اور ایپلیکیشنز کا ایک نیٹ ورک جو ایک متبادل مالیاتی نظام پیش کرتا ہے۔ اگر آپ ایک مالیاتی پیشہ ور ہیں، تو [DeFi Llama](https://defillama.com/) یا [DeFiPrime](https://defiprime.com) پر کچھ DeFi ایپس دیکھیں۔ +- اکاؤنٹنٹ؟ ایتھیریم پر موجود اثاثے - ETH، ٹوکنز، DeFi، وغیرہ - بہت سے نئے اکاؤنٹنگ مسائل متعارف کراتے ہیں۔ آپ کچھ ایسے پروجیکٹس کو دیکھ کر شروعات کر سکتے ہیں جن کا مقصد کرپٹو کرنسی کے صارفین کو ان کے بک کیپنگ اور اکاؤنٹنگ کے چیلنجز کو حل کرنے میں مدد کرنا ہے، جیسے [Rotki](https://rotki.com/) + +## پروڈکٹ مینیجرز ‍ {#product-managers} + +- ایتھیریم ایکو سسٹم کو آپ کی صلاحیتوں کی ضرورت ہے! بہت سی کمپنیاں پروڈکٹ مینیجر کے کرداروں کے لیے بھرتی کر رہی ہیں۔ اگر آپ کسی اوپن سورس پروجیکٹ میں حصہ ڈال کر شروعات کرنا چاہتے ہیں تو، [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) یا [RaidGuild](https://www.raidguild.org/) سے رابطہ کریں۔ + +## مارکیٹنگ ‍ {#marketing} + +- ایتھیریم ایکو سسٹم میں مارکیٹنگ اور کمیونیکیشن کی بہت سی پوزیشنیں ہیں! + +## ایتھیریم نوکریاں {#ethereum-jobs} + +**ایتھیریم میں کام کرنے والی نوکری تلاش کرنا چاہتے ہیں؟** + +- [ethereum.org نوکریاں](/about/#open-jobs) +- [ایتھیریم فاؤنڈیشن جاب بورڈ](https://jobs.ashbyhq.com/ethereum-foundation) +- [JobStash](https://jobstash.xyz) +- [ایتھیریم جاب بورڈ](https://www.ethereumjobboard.com/) +- [کرپٹو کرنسی نوکریاں](https://cryptocurrencyjobs.co/ethereum/) +- [Careers at ConsenSys](https://consensys.net/careers/) +- [کرپٹو جابز لسٹ](https://cryptojobslist.com/ethereum-jobs) +- [Bankless jobs board](https://pallet.xyz/list/bankless/jobs) +- [Web3 نوکریاں](https://web3.career) +- [Web3 آرمی](https://web3army.xyz/) +- [Crypto Valley Jobs](https://cryptovalley.jobs/) +- [ایتھیریم نوکریاں](https://startup.jobs/ethereum-jobs) + +## ایک DAO میں شامل ہوں {#decentralized-autonomous-organizations-daos} + +"DAOs" وکندریقرت خود مختار تنظیمیں ہیں۔ یہ گروپس تنظیم اور تعاون کو آسان بنانے کے لیے ایتھیریم ٹیکنالوجی کا فائدہ اٹھاتے ہیں۔ مثال کے طور پر، رکنیت کو کنٹرول کرنے، تجاویز پر ووٹنگ کرنے، یا جمع شدہ اثاثوں کا انتظام کرنے کے لیے۔ جبکہ DAOs ابھی بھی تجرباتی ہیں، وہ آپ کے لیے ایسے گروپس تلاش کرنے، ساتھی تلاش کرنے، اور ایتھیریم کمیونٹی پر اپنے اثر و رسوخ کو بڑھانے کے مواقع فراہم کرتے ہیں۔ [DAOs کے بارے میں مزید](/dao/) + +- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _غیر تکنیکی شعبے میں DAO کے تصور کو فروغ دیں اور لوگوں کو DAO کے ذریعے قدر پیدا کرنے میں مدد کریں_ +- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _تعمیر کرنے والوں کی کمیونٹی جو انٹرنیٹ کی اجتماعی ملکیت پر یقین رکھتی ہے_ +- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - _فری لانسر Web3 ڈیولپمنٹ کا مجموعہ جو ایک DAO کے طور پر کام کرتا ہے_ +- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) - _DAOhaus کی کمیونٹی گورننس_ +- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - _قانونی انجینئرنگ_ +- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - _پری سیڈ کرپٹو پروجیکٹس کے لیے وینچر_ +- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - _ڈیجی فزیکل ملبوسات کے برانڈز_ +- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - _ایتھیریم ڈیولپمنٹ کی فنڈنگ پر مرکوز کمیونٹی_ +- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - _Web3 بلڈرز کا مجموعہ_ + +براہ کرم یاد رکھیں کہ جب بھی اور جیسے بھی آپ ethereum.org میں حصہ ڈالتے ہیں، ethereum.org کے [ضابطہ اخلاق](/community/code-of-conduct) کی پابندی کریں! diff --git a/public/content/translations/ur/community/grants/index.md b/public/content/translations/ur/community/grants/index.md new file mode 100644 index 00000000000..8da7b77a15b --- /dev/null +++ b/public/content/translations/ur/community/grants/index.md @@ -0,0 +1,68 @@ +--- +title: "ایتھیریم فاؤنڈیشن اور کمیونٹی گرانٹ پروگرام" +description: "ایتھیریم ایکو سسٹم میں گرانٹ پروگراموں کی ایک فہرست۔" +lang: ur-in +--- + +# ایتھیریم گرانٹس {#ethereum-grants} + +نیچے دیے گئے پروگرام ایتھیریم ایکو سسٹم کی کامیابی اور ترقی کو فروغ دینے کے لیے کام کرنے والے پروجیکٹس کے لیے مختلف قسم کی فنڈنگ گرانٹس پیش کرتے ہیں۔ اپنے اگلے ایتھیریم پروجیکٹ کو کامیاب بنانے میں مدد کے لیے فنڈز تلاش کرنے اور درخواست دینے کے لیے اسے ایک گائیڈ کے طور پر استعمال کریں۔ + +یہ فہرست ہماری کمیونٹی کے ذریعہ تیار کی گئی ہے۔ اگر کچھ غائب یا غلط ہے تو، براہ کرم اس صفحہ میں ترمیم کریں! + + + +
فاؤنڈرز، کیا آپ کو اپنے کاروبار کو تیز کرنے میں مدد کی ضرورت ہے؟ [فاؤنڈرز سپورٹ پر جائیں](/founders/)
+
+ +## وسیع ایتھیریم ایکو سسٹم {#broad-ethereum-ecosystem} + +یہ پروگرام وسیع پیمانے پر پروجیکٹس کو گرانٹس پیش کرکے وسیع ایتھیریم ایکو سسٹم کی حمایت کرتے ہیں۔ ان میں اسکیل ایبلٹی، کمیونٹی بلڈنگ، سیکورٹی، پرائیویسی، اور بہت کچھ کے حل شامل ہیں۔ یہ گرانٹس کسی ایک ایتھیریم پلیٹ فارم کے لیے مخصوص نہیں ہیں اور اگر آپ کو یقین نہیں ہے تو شروع کرنے کے لیے یہ ایک اچھی جگہ ہے۔ + +- [EF ایکو سسٹم سپورٹ پروگرام](https://esp.ethereum.foundation) - _ایتھیریم کو فائدہ پہنچانے والے اوپن سورس پروجیکٹس کی فنڈنگ، جس میں یونیورسل ٹولز، انفراسٹرکچر، تحقیق اور عوامی سامان پر خصوصی توجہ دی گئی ہے_ +- [اکیڈمک گرانٹس](https://esp.ethereum.foundation/academic-grants) - _ایتھیریم سے متعلقہ تعلیمی کام کی حمایت کے لیے گرانٹس_ + +## گرانٹ لسٹ ایگریگیٹرز اور پلیٹ فارمز {#grant-list-aggregators} + +یہ وسائل ایتھیریم ایکو سسٹم میں گرانٹ کے مختلف مواقع کو مرتب اور منظم کرتے ہیں، جس سے آپ کے پروجیکٹ کی ضروریات سے مماثل فنڈنگ کے مواقع تلاش کرنا آسان ہو جاتا ہے۔ ہم نے آپ کی مخصوص فنڈنگ کی ضروریات کی بنیاد پر انتہائی متعلقہ وسائل تلاش کرنے میں آپ کی مدد کے لیے انہیں شخصیت کے لحاظ سے ترتیب دیا ہے۔ + +### تمام گرانٹ کے متلاشیوں کے لیے: جامع ڈائرکٹریاں {#comprehensive-directories} + +یہ عمومی پلیٹ فارم پورے Web3 اسپیس میں گرانٹس کی وسیع کوریج پیش کرتے ہیں اور فنڈنگ کی تلاش میں کسی کے لیے بھی مفید نقطہ آغاز ہیں: + +- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworks نے تمام گرانٹس، RFPs، اور بگ باؤنٹیز کی ایک جامع ڈائرکٹری مرتب کی ہے۔_ +- [Blockchain Grants](https://www.blockchaingrants.org/) - _بلاک چین اور کرپٹو گرانٹس کی ڈائرکٹری_ +- [Karma Funding Map](https://gap.karmahq.xyz/funding-map) - تمام web3 گرانٹ پروگراموں کی ڈائرکٹری، جو ہفتہ وار بنیادوں پر اپ ڈیٹ ہوتی ہے + +### ڈویلپرز اور بلڈرز کے لیے {#for-developers-and-builders} + +- [Grant Programs Viewer](https://airtable.com/shr86elKgWTSCP4AY) - _گرانٹ پروگراموں کا عوامی Airtable ڈیٹا بیس_ +- [Web3 Grants Spreadsheet](https://docs.google.com/spreadsheets/d/1c8koZCI-GLnD8MG-eFcXPOBCNu1v8-aXIfwAAvc7AMc/edit#gid=0) - _Web3 گرانٹ کے مواقع کی گوگل اسپریڈ شیٹ_ +- [Arbitrum Grants](https://arbitrum.foundation/grants) — Arbitrum DAO اور [The Arbitrum Foundation](https://arbitrum.foundation/) + +### DeFi پروجیکٹس اور مالیاتی ایپلیکیشنز کے لیے {#for-defi-projects} + +- [LlamaoGrants](https://wiki.defillama.com/wiki/LlamaoGrants) - _DeFi Llama کی گرانٹ پروگرام ڈائرکٹری_ +- [AlphaGrowth Grants](https://alphagrowth.io/crypto-web3-grants-list) - _کرپٹو اور Web3 گرانٹس کی جامع فہرست_ +- [Uniswap Foundation Grants](https://www.uniswapfoundation.org/build) - _Unichain اور Uniswap v4 گرانٹس اور DeFi بلڈرز کے لیے سپورٹ_ + +### DAO شراکت داروں اور گورننس کے اختراع کاروں کے لیے {#for-dao-contributors} + +کمیونٹی سے چلنے والے پروجیکٹس اور گورننس کے تجربات کے لیے وسائل: + +- [DAO Grants](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _گرانٹس پیش کرنے والی تنظیموں کی گوگل اسپریڈ شیٹ_ +- [MetaGov Database](https://docs.google.com/spreadsheets/d/1e5g-dlWWsK2DZoZGBgfxyfGNSddLk-V7sLEgfPjEhbA/edit#gid=780420708) - _جامع Web3 گرانٹس کا نقشہ_ + +### عوامی سامان اور اثر {#public-goods-and-impact} + +یہ پروگرام ان منصوبوں کی فنڈنگ پر توجہ مرکوز کرتے ہیں جو وسیع تر کمیونٹی، عوامی سامان، اور اثر انگیز اقدامات کو فائدہ پہنچاتے ہیں۔ ان میں گرانٹ فراہم کرنے والے، نیز عطیہ کے پلیٹ فارم شامل ہیں جو آن چین فنڈنگ مختص کرنے کے طریقہ کار کا استعمال کرتے ہیں بشمول [quadratic funding](/defi/#quadratic-funding): + +- [Gitcoin](https://www.gitcoin.co/program) - _Gitcoin گرانٹس ایتھیریم ایکو سسٹم میں اوپن سورس پروجیکٹس اور عوامی سامان کی فنڈنگ کے لیے متعدد سرمائے کی تقسیم کے طریقہ کار کا استعمال کرتا ہے_ +- [Octant](https://octant.app/home) - _عوامی سامان کی فنڈنگ کا ایکو سسٹم جو مشترکہ بھلائی اور انفرادی مالیاتی بااختیاریت کو متوازن کرتا ہے_ +- [Giveth](https://giveth.io/) - _کرپٹو عطیہ پلیٹ فارم جو بغیر کسی اضافی فیس کے اچھے پروجیکٹس سے براہ راست عطیات کو قابل بناتا ہے_ +- [Artizen](https://artizen.fund/) - _فن، سائنس، ٹیکنالوجی اور ثقافت کے محاذ پر نئے پروجیکٹس کے لیے فنڈز سے مماثل تخلیق کاروں کی مدد کرنا_ +- [Quadratic Accelerator](https://qacc.giveth.io/) - _اسٹارٹ اپ ایکسلریٹر پروگرام جو عوامی بھلائی کے لیے فائدہ مند پروجیکٹس کی حمایت کے لیے quadratic فنڈنگ کا استعمال کرتا ہے_ + +## ایتھیریم میں کام کریں {#work-in-ethereum} + +اپنا پروجیکٹ شروع کرنے کے لیے تیار نہیں ہیں؟ سینکڑوں کمپنیاں فعال طور پر پرجوش افراد کی تلاش میں ہیں جو ایتھیریم ایکو سسٹم میں کام کریں اور اس میں اپنا حصہ ڈالیں۔ مزید معلومات کی تلاش ہے؟ [ایتھیریم سے متعلقہ ملازمتیں دیکھیں](/community/get-involved/#ethereum-jobs) diff --git a/public/content/translations/ur/community/language-resources/index.md b/public/content/translations/ur/community/language-resources/index.md new file mode 100644 index 00000000000..13175adf067 --- /dev/null +++ b/public/content/translations/ur/community/language-resources/index.md @@ -0,0 +1,153 @@ +--- +title: "زبان کے ذرائع" +description: "ایتھیریم کے بارے میں جاننے کے لیے غیر انگریزی وسائل" +lang: ur-in +--- + +# زبان کے وسائل {#language-resources} + +ایتھیریم کمیونٹی عالمی ہے اور لاکھوں غیر انگریزی بولنے والوں پر مشتمل ہے۔ + +ہمارا مقصد تمام زبانوں میں تعلیمی مواد فراہم کرنا ہے اور زبان کی رکاوٹوں کو دور کرنے میں مدد کرنا ہے جو پوری دنیا سے لوگوں کو ایتھیریم میں شامل کرنے کو ایک چیلنج بناتی ہیں۔ + +اگر آپ اپنی مادری زبان میں پڑھنا پسند کرتے ہیں یا کسی ایسے شخص کو جانتے ہیں جو انگریزی نہیں بولتا، تو آپ ذیل میں مفید غیر انگریزی وسائل کی ایک فہرست تلاش کرسکتے ہیں۔ لاکھوں ایتھیریم کے شوقین ان آن لائن فورمز میں خبریں بانٹنے، حالیہ پیشرفتوں کے بارے میں بات کرنے، تکنیکی مسائل پر بحث کرنے، اور مستقبل کا تصور کرنے کے لیے جمع ہوتے ہیں۔ + +اپنی زبان میں کسی تعلیمی وسیلہ کے بارے میں جانتے ہیں؟ [ایک مسئلہ کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new/choose) اسے فہرست میں شامل کرنے کے لیے! + +## Ethereum.org کے وسائل {#ethereum-org} + +Ethereum.org کا 40 سے زیادہ زبانوں میں مقامی طور پر ترجمہ کیا گیا ہے جسے آپ ہمارے زبانوں کے سلیکٹر مینو کا استعمال کرکے تلاش کرسکتے ہیں، جو ہر صفحے کے اوپری حصے میں واقع ہے۔ + +![زبان سلیکٹر مینو](./language-selector-menu.png) + +اگر آپ دو لسانی ہیں اور مزید لوگوں تک پہنچنے میں ہماری مدد کرنا چاہتے ہیں، تو آپ [ethereum.org ترجمہ پروگرام](/contributing/translation-program/#translation-program) میں بھی شامل ہوسکتے ہیں اور ویب سائٹ کا ترجمہ کرنے میں ہماری مدد کر سکتے ہیں۔ + +## کمیونٹی وسائل {#community} + +### برازیلی پرتگالی {#br-pt} + +**خبریں** + +- [BeInCrypto](http://www.beincrypto.com.br) - کرپٹوکرنسی کی خبریں اور مضامین، بشمول ایکسچینجز کی فہرست، برازیل میں دستیاب +- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - Cointelegraph کا برازیلی ورژن، ایک بڑا کرپٹوکرنسی نیوز آؤٹ لیٹ +- [Livecoins](http://www.livecoins.com.br/ethereum) - کرپٹوکرنسی کی خبریں اور ٹولز +- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - کرپٹوکرنسی کی خبریں اور رپورٹیں +- [Modular Crypto](https://modularcrypto.xyz/) - کرپٹوکرنسی کی خبریں اور تعلیمی مضامین + +**تعلیم** + +- [web3dev](https://www.web3dev.com.br/) - ویب 3 ڈویلپرز کے لیے مواد کا مرکز اور Discord کمیونٹی۔ +- [Web3Brasil](https://github.com/web3brasil/web3brasil) - Web3 اور DeFi سیکھنے کے وسائل +- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - کرپٹوکرنسی کی خبریں اور تعلیم، بشمول 'نئے سیکھنے والوں کے لیے ایتھیریم' اور 'نئے سیکھنے والوں کے لیے DeFi' +- [CriptoAtivos](http://www.criptoativos.wiki.br/) - کرپٹوکرنسی کی دنیا سے بصیرت، تعلیم اور بلاگ +- [Cointimes](http://www.cointimes.com.br/) - کرپٹوکرنسی کی خبریں اور تعلیم +- [Web3 starter pack](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - ایک گائیڈ جو اکثر پوچھے جانے والے اور بنیادی کرپٹو سوالات کے جوابات دیتا ہے + +### چینی {#zh} + +**عمومی وسائل** + +- [Ethereum.cn](https://www.ethereum.cn/) - کمیونٹی کے زیر انتظام مواد، جس میں کنسینسس لیئر اپ گریڈ، تمام کور ڈیو میٹنگ نوٹس، لیئر 2، وغیرہ شامل ہیں۔ +- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - بنیادی باتوں سے لے کر جدید ایتھیریم موضوعات تک سب کچھ سیکھیں +- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - کمیونٹی کے زیر انتظام مواد، جس میں ایتھیریم، DeFi، NFT، Web3 سے متعلق علم شامل ہے +- [123ETH](https://123eth.org/) - ایتھیریم ایکو سسٹم کا ایک پورٹل +- [Zhen Xiao](http://zhenxiao.com/blockchain/) - کرپٹوکرنسی اور اس کی ایپلی کیشنز کے بارے میں مفت آن لائن کورسز +- [Ethereum Whitepaper](/zh/whitepaper/) - ایتھیریم وائٹ پیپر کا چینی ورژن + +**ایتھیریم ایکو سسٹم** + +- [ETHPlanet](https://www.ethplanet.org/) - آن لائن اور ذاتی ہیکاتھون، یونیورسٹی کے طلباء کو تربیت کی پیشکش +- [PrimitivesLane](https://www.primitiveslane.org/) - ایک غیر منافع بخش تحقیقی گروپ، جو بلاک چین ٹیکنالوجی پر مرکوز ہے +- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - ایک کمیونٹی جو تعلیمی ایتھیریم مواد کا ترجمہ کرنے کے لیے وقف ہے + +**ڈویلپرز کے لیے** + +- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - مرکزی دھارے میں شامل dapp پروجیکٹس کا مطالعہ کرنے اور ہر ہفتے خیالات اور تبصرے بانٹنے کے لیے ایک لرننگ گروپ +- [LearnBlockchain](https://learnblockchain.cn/) - ڈویلپرز کے لیے ایک کمیونٹی، جو بلاک چین ٹیکنالوجی کے بارے میں معلومات کا اشتراک کرتی ہے + +**کرپٹوگرافی کے محققین کے لیے** + +- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - ایک WeChat اکاؤنٹ، جو کرپٹوگرافی، سیکیورٹی وغیرہ کی وضاحت کرتا ہے۔ +- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - ایک WeChat اکاؤنٹ، جو zk ٹیکنالوجی کی وضاحت کرتا ہے + +### چیک {#cs} + +- [Gwei.cz](https://gwei.cz) - Web3 کے ارد گرد مقامی کمیونٹی، تعلیمی مواد تخلیق کرتی ہے، آن لائن اور ذاتی تقریبات کا اہتمام کرتی ہے +- [Gwei.cz Příručka](https://prirucka.gwei.cz/) - نئے سیکھنے والوں کے لیے ایتھیریم گائیڈ +- [DAO Příručka](https://dao.gwei.cz/) - DAOs کے لیے نئے سیکھنے والوں کی گائیڈ +- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - چیک میں Mastering Ethereum + +### فرانسیسی {#fr} + +- [Ethereum France](https://www.ethereum-france.com/) - Ethereum France تقریبات کا اہتمام کرتا ہے، مواد تخلیق کرتا ہے اور ایتھیریم کے ارد گرد بات چیت کی حوصلہ افزائی کرتا ہے +- [Ethereum.fr](https://ethereum.fr/) - ایتھیریم کی خبریں اور تعلیم +- [BanklessFR](https://banklessfr.substack.com/) - فرانسیسی میں Bankless نیوز لیٹر +- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - ایتھیریم سب پیج کے ساتھ کرپٹوکرنسی فورم + +### جرمن {#de} + +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - Solidity کا استعمال +- [Microsoft Learn (smart contracts)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - Solidity کے ساتھ ایتھیریم سمارٹ کنٹریکٹ لکھنا +- [Microsoft Learn (Ethereum networks)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - ایتھیریم نیٹ ورکس سے جڑیں اور انہیں تعینات کریں +- [Microsoft Learn (blockchains)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - بلاک چین ڈیولپمنٹ میں داخلہ + +### عبرانی {#he} + +- [Udi Wertheimer - بٹ کوائنرز ایتھیریم سے کیا سیکھ سکتے ہیں](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/) +- [Omer Greismen (OpenZeppelin) - ہم نے 15 بلین ڈالر کے سمارٹ کنٹریکٹ ہیک کو کیسے روکا](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/) +- [Shy Datika (INX) - ٹوکنائزیشن اور سیکیورٹیز کا مستقبل، بشمول کیا ایتھیریم ایک سیکیورٹی ہے](https://www.cryptojungle.co.il/shy-datika-tokenization/) +- [Roy Confino (Lemonade) - انشورنس @ ایتھیریم](https://www.cryptojungle.co.il/roy-confino-insurance/) +- [Idan Ofrat (Fireblocks) - ادارہ جاتی اپناؤ](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/) +- [Gal Weizman (MetaMask) - MetaMask کیا ہے](https://www.cryptojungle.co.il/gal-weizman-metamask/) +- [Dror Aviely (Consensys) - ایتھیریم کا مرکز](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/) +- [Nir Rozin - کرپٹوپنک ہونا](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/) +- [Adan Kedem - گیمنگ اور میٹاورس](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/) +- [Uri Kolodny (Starkware) - ایتھیریم اور بلاک چین لیئرز](https://www.cryptojungle.co.il/uri-kolodny-starkware/) +- [Udi Wertheimer - ایتھیریم 2.0 بمقابلہ مقابلہ](https://www.cryptojungle.co.il/udi-on-eth2/) +- [Ben Samocha (myself) - ایتھیریم 2.0 - ایک موقع؟](https://www.cryptojungle.co.il/etherurm2-week-summary/) +- [Alon Muroch (Bloxstaking) - ایتھیریم 2.0 کیا ہے؟](https://www.cryptojungle.co.il/alon-moroch-eth2/) +- [Eilon Aviv (Collider Ventures) - ایتھیریم 2.0 کے ساتھ کیا غلط ہو سکتا ہے](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/) +- [Eilon Aviv (Collider Ventures) - ہمیں ایتھیریم 2.0 کی ضرورت کیوں ہے](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/) + +### اطالوی {#it} + +- [Ethereum Italia](https://www.ethereum-italia.it/) - ایتھیریم کی تعلیم، تقریبات، اور خبریں، سمارٹ کنٹریکٹس اور بلاک چین ٹیکنالوجی پر توجہ مرکوز +- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) - اطالوی میں ایتھیریم پوڈ کاسٹ +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - Solidity کا استعمال کیسے کریں سیکھیں +- [Microsoft Learn (Smart contracts)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - Solidity کا استعمال کرتے ہوئے سمارٹ کنٹریکٹ لکھنے کے بارے میں جانیں +- [Microsoft Learn (dapps)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) - غیر مرکزی ایپلی کیشنز کے ساتھ ایک صارف انٹرفیس بنائیں + +### جاپانی {#ja} + +- [Japan Virtual and Crypto assets Exchange Association](https://jvcea.or.jp/) +- [Japan Cryptoasset Business Association](https://cryptocurrency-association.org/) +- [Get started with blockchain development - Learn | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - یہ سیکھنے کا راستہ آپ کو بلاک چین اور ایتھیریم پلیٹ فارم پر ڈیولپمنٹ سے متعارف کراتا ہے +- [Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) - جاپانی میں Mastering Ethereum +- [Hands-On Smart Contract Development with Solidity and Ethereum](https://www.oreilly.co.jp/books/9784873119342/) - جاپانی میں Hands-On Smart Contract Development with Solidity and Ethereum + +### روسی {#ru} + +- [Cyber Academy](https://cyberacademy.dev) - web3 بنانے والوں کے لیے تعلیمی جگہ +- [Forklog](https://forklog.com) - عمومی طور پر کرپٹو کے بارے میں خبریں اور تعلیمی مضامین، موجودہ ٹیکنالوجیز اور مختلف بلاک چینز کے مستقبل کے اپ گریڈ +- [BeInCrypto](https://ru.beincrypto.com) - خبریں، کرپٹو قیمت کا تجزیہ اور کرپٹو میں ہر چیز کے بارے میں سادہ وضاحتوں کے ساتھ غیر تکنیکی مضامین + +### ہسپانوی {#es} + +- [Ethereum Madrid](https://ethereummadrid.com/) - بلاک چین، DeFi، اور گورننس کورسز، تقریبات اور بلاگ +- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - ہسپانوی میں نئے سیکھنے والوں کے لیے ایتھیریم گائیڈ +- [Tutoriales online](https://tutoriales.online/curso/solidity) - Solidity اور ایتھیریم پر پروگرامنگ سیکھیں +- [Curso Introducción a Ethereum Development](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - Solidity کی بنیادی باتیں، اپنے پہلے سمارٹ کنٹریکٹ کی جانچ اور تعیناتی +- [Curso Introducción a Seguridad y Hacking en Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - حقیقی سمارٹ کنٹریکٹس میں عام کمزوریوں اور سیکیورٹی کے مسائل کو سمجھیں +- [Curso Introducción a DeFi Development](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - جانیں کہ DeFi سمارٹ کنٹریکٹ Solidity میں کیسے کام کرتے ہیں اور اپنا خودکار مارکیٹ میکر بنائیں +- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - ابتدائی سے لے کر جدید تک غیر تکنیکی بلاک چین تعلیم۔ کرپٹو اور ایتھیریم کے بارے میں سب کچھ جانیں۔ + +### ترکی {#tr} + +- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - بلاک چین اور کرپٹوکرنسی پر مرکوز کورس +- [The great renaming: what happened to Eth2?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - عظیم نام کی تبدیلی والے بلاگ پوسٹ کا ترکی ترجمہ، 'Eth2' کی اصطلاح سے دور جانے کی وضاحت + +### ویتنامی {#vi} + +- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - ایتھیریم، dapps، والیٹس اور اکثر پوچھے جانے والے سوالات کا جائزہ +- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - ایتھیریم کی خبروں اور تعلیم کے لیے سب پیجز کے ساتھ ویب پلیٹ فارم +- [Coin68](https://coin68.com/ethereum-tieu-diem/) - ایتھیریم کی خبروں اور تعلیمی مواد کے ساتھ کرپٹوکرنسی پورٹل diff --git a/public/content/translations/ur/community/online/index.md b/public/content/translations/ur/community/online/index.md new file mode 100644 index 00000000000..4bb8b429000 --- /dev/null +++ b/public/content/translations/ur/community/online/index.md @@ -0,0 +1,74 @@ +--- +title: "آن لائن کمیونٹیز" +description: "آن لائن فورمز، چیٹ رومز، اور سوشل میڈیا کمیونٹیز دریافت کریں جہاں Ethereum کے شوقین افراد تبادلہ خیال اور تعاون کے لیے جمع ہوتے ہیں۔" +lang: ur-in +--- + +# آن لائن کمیونٹیز {#online-communities} + +لاکھوں ایتھیریم کے شوقین ان آن لائن فورمز میں خبریں بانٹنے، حالیہ پیشرفتوں کے بارے میں بات کرنے، تکنیکی مسائل پر بحث کرنے، اور مستقبل کا تصور کرنے کے لیے جمع ہوتے ہیں۔ + +## فہرست سازی کی پالیسی {#listing-policy} + +فہرست میں شامل کمیونٹیز کی سالمیت اور قدر کو برقرار رکھنے کے لیے، ethereum.org اہلیت کا تعین کرنے کے لیے ایک سخت پالیسی پر عمل کرتا ہے: + +### اہلیت کے معیار {#eligibility-criteria} + +- **مطابقت**: کمیونٹی کا براہ راست Ethereum اور اس کے ایکو سسٹم سے متعلق ہونا ضروری ہے۔ +- **سرگرمی کی سطح**: کمیونٹی کو باقاعدہ تعاملات، پوسٹس، یا مباحثوں کے ساتھ فعال ہونا چاہیے۔ غیر فعال یا غیر سرگرم کمیونٹیز کو ہٹایا جا سکتا ہے۔ +- **شمولیت**: کمیونٹی کو ایک خوش آئند ماحول کو فروغ دینا چاہیے جو تنوع کا احترام کرے اور تمام پس منظر کے لوگوں کی شرکت کی حوصلہ افزائی کرے۔ +- **غیر تجارتی توجہ**: فہرستیں تجارتی یا تشہیری پلیٹ فارمز کے بجائے کمیونٹی سے چلنے والی جگہوں کے لیے ہیں۔ + +### مواد کے رہنما اصول {#content-guidelines} + +- **مناسب مواد**: کمیونٹیز کے پاس اپنے ماڈریشن کے رہنما اصول ہونے چاہئیں، جس میں اسپام، نفرت انگیز تقریر، ایذا رسانی، یا غیر قانونی سرگرمیوں کو فروغ دینے والے کسی بھی مواد سے گریز کیا جائے۔ +- **زبان**: اگرچہ انگریزی بنیادی زبان ہے، دوسری زبانوں میں کمیونٹیز کو جمع کرانے کی ترغیب دی جاتی ہے جب تک کہ وہ ایک جامع اور قابل احترام ماحول کو برقرار رکھیں۔ +- **شفافیت**: کمیونٹی کے مقصد، قوانین، اور ماڈریٹرز کے بارے میں واضح معلومات اراکین کے لیے دستیاب ہونی چاہئیں۔ + +### دیگر سفارشات {#other-recommendations} + +- **رسائی**: کمیونٹی فورمز کو سائن اپ یا رجسٹریشن کی ضرورت کے بغیر ہر کسی کے پڑھنے کے لیے قابل رسائی ہونا چاہیے۔ +- **ڈسکارڈ سرور کے دعوت نامے**: یہ تجویز کیا جاتا ہے کہ صرف قابل اعتماد ڈسکارڈ سرور کے دعوت نامے ہی ethereum.org میں شامل کیے جائیں۔ مثالی طور پر، ان دعوت ناموں کو ویب سائٹ پر کمیونٹی پیج سے لنک کرنا چاہیے (مثلاً، [ethglobal.com/discord](https://ethglobal.com/discord)) یا کسی آفیشل URL سے ہونا چاہیے (مثلاً، [discord.gg/ethstaker](https://discord.gg/ethstaker) یا [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker))۔ + +اگر آپ کو یقین ہے کہ ان ہدایات کی بنیاد پر کسی کمیونٹی کو شامل یا ہٹایا جانا چاہیے، تو براہ کرم [ہماری GitHub ریپوزٹری پر ایک ایشو کھولیں](https://github.com/ethereum/ethereum-org-website/issues)۔ + +## فورمز {#forums} + +r/ethereum - Ethereum سے متعلق تمام چیزیں +r/ethfinance - Ethereum کا مالی پہلو، بشمول DeFi +r/ethdev - Ethereum کی ڈیولپمنٹ پر مرکوز +r/ethtrader - رجحانات اور مارکیٹ کا تجزیہ +r/ethstaker - Ethereum پر اسٹیکنگ میں دلچسپی رکھنے والے سبھی کا خیرمقدم ہے +Fellowship of Ethereum Magicians - Ethereum میں تکنیکی معیارات پر مبنی کمیونٹی +Ethereum Stackexchange - Ethereum ڈیولپرز کے لیے تبادلہ خیال اور مدد +Ethereum Research - کریپٹو اکنامک ریسرچ کے لیے سب سے زیادہ بااثر میسیج بورڈ + +## چیٹ رومز {#chat-rooms} + +Ethereum Cat Herders - Ethereum کی ڈیولپمنٹ کو پراجیکٹ مینجمنٹ سپورٹ فراہم کرنے پر مبنی کمیونٹی +Ethereum Hackers - ETHGlobal کے زیر انتظام ڈسکارڈ چیٹ: دنیا بھر کے Ethereum ہیکرز کے لیے ایک آن لائن کمیونٹی +CryptoDevs - Ethereum ڈیولپمنٹ پر مرکوز ڈسکارڈ کمیونٹی +EthStaker Discord - موجودہ اور ممکنہ اسٹیکرز کے لیے کمیونٹی کے زیر انتظام رہنمائی، تعلیم، سپورٹ، اور وسائل +Ethereum.org website team - ٹیم اور کمیونٹی کے لوگوں کے ساتھ ethereum.org ویب ڈیولپمنٹ اور ڈیزائن پر بات چیت کے لیے آئیں +Matos Discord - web3 تخلیق کاروں کی کمیونٹی جہاں بلڈرز، صنعتی شخصیات، اور Ethereum کے شوقین افراد اکٹھے ہوتے ہیں۔ ہمیں web3 ڈیولپمنٹ، ڈیزائن اور کلچر کا شوق ہے۔ آئیں ہمارے ساتھ تعمیر کریں۔ +Solidity Gitter - solidity ڈیولپمنٹ کے لیے چیٹ (Gitter) +Solidity Matrix - solidity ڈیولپمنٹ کے لیے چیٹ (Matrix) +Ethereum Stack Exchange - سوال و جواب کا فورم +Peera Community Forum - غیر مرکزی سوال و جواب کا فورم + +## یوٹیوب اور ایکس (سابقہ ٹویٹر) {#youtube-and-twitter} + +Ethereum Foundation - Ethereum فاؤنڈیشن کی تازہ ترین معلومات سے باخبر رہیں +@ethereum - کمیونٹی کے لیے مرکزی Ethereum اکاؤنٹ +@ethereumfndn - Ethereum فاؤنڈیشن کا آفیشل اکاؤنٹ +@ethdotorg - Ethereum کا پورٹل، جو ہماری بڑھتی ہوئی عالمی برادری کے لیے بنایا گیا ہے + + + + +
+ + DAOs کے بارے میں مزید جانیں + +
+
diff --git a/public/content/translations/ur/community/research/index.md b/public/content/translations/ur/community/research/index.md new file mode 100644 index 00000000000..c86bca67c5d --- /dev/null +++ b/public/content/translations/ur/community/research/index.md @@ -0,0 +1,399 @@ +--- +title: "ایتھیریم ریسرچ کے فعال شعبے" +description: "اوپن ریسرچ کے مختلف شعبوں کو دریافت کریں اور جانیں کہ اس میں کیسے شامل ہونا ہے۔" +lang: ur-in +--- + +# ایتھیریم ریسرچ کے فعال شعبے {#active-areas-of-ethereum-research} + +ایتھیریم کی بنیادی خوبیوں میں سے ایک یہ ہے کہ ایک فعال ریسرچ اور انجینئرنگ کمیونٹی اسے مسلسل بہتر بنا رہی ہے۔ دنیا بھر میں بہت سے پرجوش، ہنرمند لوگ ایتھیریم کے بقایا مسائل پر خود کو لاگو کرنا چاہیں گے، لیکن یہ معلوم کرنا ہمیشہ آسان نہیں ہوتا کہ وہ مسائل کیا ہیں۔ یہ صفحہ ایتھیریم کے جدید ترین شعبوں کے لیے ایک کھردری گائیڈ کے طور پر کلیدی فعال تحقیقی شعبوں کا خاکہ پیش کرتا ہے۔ + +## ایتھیریم ریسرچ کیسے کام کرتی ہے {#how-ethereum-research-works} + +ایتھیریم ریسرچ کھلی اور شفاف ہے، جو [غیر مرکزی سائنس (DeSci)](https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science) کے اصولوں کو مجسم کرتی ہے۔ یہاں کا کلچر تحقیقی ٹولز اور آؤٹ پٹس کو ہر ممکن حد تک کھلا اور انٹرایکٹو بنانا ہے، مثال کے طور پر، قابل عمل نوٹ بکس کے ذریعے۔ ایتھیریم ریسرچ تیزی سے آگے بڑھتی ہے، جس میں نئے نتائج کو ہم مرتبہ کے جائزوں کے دور کے بعد روایتی اشاعتوں کے ذریعے کمیونٹی تک پہنچنے کے بجائے [ethresear.ch](https://ethresear.ch/) جیسے فورمز پر کھلے عام پوسٹ اور بحث کی جاتی ہے۔ + +## عمومی تحقیقی وسائل {#general-research-resources} + +مخصوص موضوع سے قطع نظر، [ethresear.ch](https://ethresear.ch) اور [Eth R&D Discord چینل](https://discord.gg/qGpsxSA) پر ایتھیریم ریسرچ کے بارے میں معلومات کا ایک خزانہ موجود ہے۔ یہ وہ بنیادی جگہیں ہیں جہاں ایتھیریم کے محققین جدید ترین خیالات اور ترقی کے مواقع پر تبادلہ خیال کرتے ہیں۔ + +[DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) کی طرف سے مئی 2022 میں شائع ہونے والی یہ رپورٹ ایتھیریم روڈ میپ کا ایک اچھا جائزہ فراہم کرتی ہے۔ + +## فنڈنگ کے ذرائع {#sources-of-funding} + +آپ ایتھیریم ریسرچ میں شامل ہو سکتے ہیں اور اس کے لیے ادائیگی حاصل کر سکتے ہیں! مثال کے طور پر، [ایتھیریم فاؤنڈیشن](/foundation/) نے حال ہی میں ایک [تعلیمی گرانٹس فنڈنگ راؤنڈ](https://esp.ethereum.foundation/academic-grants) چلایا۔ آپ [ایتھیریم گرانٹس کے صفحے](/community/grants/) پر فعال اور آنے والے فنڈنگ کے مواقع کے بارے میں معلومات حاصل کر سکتے ہیں۔ + +## پروٹوکول ریسرچ {#protocol-research} + +پروٹوکول ریسرچ کا تعلق ایتھیریم کی بنیادی تہہ سے ہے - ان اصولوں کا سیٹ جو یہ بتاتا ہے کہ نوڈس کیسے جڑتے ہیں، بات چیت کرتے ہیں، ایتھیریم ڈیٹا کا تبادلہ اور ذخیرہ کرتے ہیں اور بلاکچین کی حالت کے بارے میں اتفاق رائے پر آتے ہیں۔ پروٹوکول ریسرچ کو دو اعلی سطحی زمروں میں تقسیم کیا گیا ہے: اتفاق رائے اور عمل درآمد۔ + +### اتفاق رائے {#consensus} + +اتفاق رائے کی تحقیق کا تعلق [ایتھیریم کے پروف-آف-اسٹیک میکانزم](/developers/docs/consensus-mechanisms/pos/) سے ہے۔ اتفاق رائے پر تحقیق کے کچھ موضوعات یہ ہیں: + +- کمزوریوں کی نشاندہی کرنا اور ان کی اصلاح کرنا؛ +- کرپٹو اکنامک سیکیورٹی کا تعین کرنا؛ +- کلائنٹ کے نفاذ کی سیکیورٹی یا کارکردگی میں اضافہ کرنا؛ +- اور لائٹ کلائنٹس تیار کرنا۔ + +آگے کی سوچ والی تحقیق کے ساتھ ساتھ، پروٹوکول کے کچھ بنیادی ری ڈیزائنز، جیسے کہ سنگل سلاٹ فائنلٹی، پر تحقیق کی جا رہی ہے تاکہ ایتھیریم میں اہم بہتری کی اجازت دی جا سکے۔ مزید برآں، اتفاق رائے والے کلائنٹس کے درمیان پیئر ٹو پیئر نیٹ ورکنگ کی کارکردگی، حفاظت، اور نگرانی بھی اہم تحقیقی موضوعات ہیں۔ + +#### پس منظر کا مطالعہ {#background-reading} + +- [پروف-آف-اسٹیک کا تعارف](/developers/docs/consensus-mechanisms/pos/) +- [Casper-FFG پیپر](https://arxiv.org/abs/1710.09437) +- [Casper-FFG وضاحت کنندہ](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) +- [Gasper پیپر](https://arxiv.org/abs/2003.03052) + +#### حالیہ تحقیق {#recent-research} + +- [Ethresear.ch اتفاق رائے](https://ethresear.ch/c/consensus/29) +- [دستیابی/فائنلٹی کی مخمصہ](https://arxiv.org/abs/2009.04987) +- [سنگل سلاٹ فائنلٹی](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) +- [تجویز کنندہ-بنانے والے کی علیحدگی](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) + +### عمل درآمد {#execution} + +عمل درآمد کی تہہ کا تعلق لین دین کو انجام دینے، [ایتھیریم ورچوئل مشین (EVM)](/developers/docs/evm/) کو چلانے اور اتفاق رائے کی تہہ کو بھیجنے کے لیے عمل درآمد کے پے لوڈز بنانے سے ہے۔ تحقیق کے بہت سے فعال شعبے ہیں، جن میں شامل ہیں: + +- لائٹ کلائنٹ سپورٹ بنانا؛ +- گیس کی حدود پر تحقیق کرنا؛ +- اور نئے ڈیٹا ڈھانچے کو شامل کرنا (مثلاً، Verkle Tries)۔ + +#### پس منظر کا مطالعہ {#background-reading-1} + +- [EVM کا تعارف](/developers/docs/evm) +- [Ethresear.ch عمل درآمد کی تہہ](https://ethresear.ch/c/execution-layer-research/37) + +#### حالیہ تحقیق {#recent-research-1} + +- [ڈیٹا بیس کی اصلاحیں](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) +- [اسٹیٹ کی میعاد ختمی](https://notes.ethereum.org/@vbuterin/state_expiry_eip) +- [اسٹیٹ کی میعاد ختم ہونے کے راستے](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Verkle اور اسٹیٹ کی میعاد ختم ہونے کی تجویز](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) +- [ہسٹری کا انتظام](https://eips.ethereum.org/EIPS/eip-4444) +- [Verkle Trees](https://vitalik.eth.limo/general/2021/06/18/verkle.html) +- [ڈیٹا کی دستیابی کا نمونہ](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) + +## کلائنٹ کی ترقی {#client-development} + +ایتھیریم کلائنٹس ایتھیریم پروٹوکول کے نفاذ ہیں۔ کلائنٹ کی ترقی پروٹوکول ریسرچ کے نتائج کو ان کلائنٹس میں بنا کر حقیقت میں بدل دیتی ہے۔ کلائنٹ کی ترقی میں کلائنٹ کی خصوصیات کو اپ ڈیٹ کرنے کے ساتھ ساتھ مخصوص نفاذ کی تعمیر بھی شامل ہے۔ + +ایک ایتھیریم نوڈ کو دو سافٹ ویئر چلانے کی ضرورت ہوتی ہے: + +1. بلاکچین کے سربراہ کا ٹریک رکھنے، بلاکس کی گپ شپ کرنے اور اتفاق رائے کی منطق کو سنبھالنے کے لیے ایک اتفاق رائے والا کلائنٹ +2. ایتھیریم ورچوئل مشین کو سپورٹ کرنے اور لین دین اور اسمارٹ کنٹریکٹس کو انجام دینے کے لیے ایک ایگزیکیوشن کلائنٹ + +نوڈز اور کلائنٹس کے بارے میں مزید تفصیلات اور تمام موجودہ کلائنٹ کے نفاذ کی فہرست کے لیے [نوڈز اور کلائنٹس کا صفحہ](/developers/docs/nodes-and-clients/) دیکھیں۔ آپ [ہسٹری پیج](/ethereum-forks/) پر تمام ایتھیریم اپ گریڈ کی تاریخ بھی حاصل کر سکتے ہیں۔ + +### ایگزیکیوشن کلائنٹس {#execution-clients} + +- [ایگزیکیوشن کلائنٹ کی تفصیلات](https://github.com/ethereum/execution-specs) +- [ایگزیکیوشن API کی تفصیلات](https://github.com/ethereum/execution-apis) + +### اتفاق رائے والے کلائنٹس {#consensus-clients} + +- [اتفاق رائے والے کلائنٹ کی تفصیلات](https://github.com/ethereum/consensus-specs) +- [Beacon API کی تفصیلات](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) + +## اسکیلنگ اور کارکردگی {#scaling-and-performance} + +ایتھیریم کی اسکیلنگ ایتھیریم کے محققین کے لیے توجہ کا ایک بڑا شعبہ ہے۔ موجودہ طریقوں میں لین دین کو رول اپس پر آف لوڈ کرنا اور ڈیٹا بلابس کا استعمال کرکے انہیں ہر ممکن حد تک سستا بنانا شامل ہے۔ ایتھیریم کی اسکیلنگ کے بارے میں تعارفی معلومات ہمارے [اسکیلنگ پیج](/developers/docs/scaling) پر دستیاب ہے۔ + +### لیئر 2 {#layer-2} + +اب کئی لیئر 2 پروٹوکولز ہیں جو لین دین کو بیچنے اور انہیں ایتھیریم لیئر 1 پر محفوظ کرنے کے لیے مختلف تکنیکوں کا استعمال کرتے ہوئے ایتھیریم کو اسکیل کرتے ہیں۔ یہ ایک بہت تیزی سے بڑھتا ہوا موضوع ہے جس میں تحقیق اور ترقی کی بہت زیادہ صلاحیت ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-2} + +- [لیئر 2 کا تعارف](/layer-2/) +- [Polynya: رول اپس، DA اور ماڈیولر چینز](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d) + +#### حالیہ تحقیق {#recent-research-2} + +- [ترتیب دینے والوں کے لیے Arbitrum کی منصفانہ ترتیب](https://eprint.iacr.org/2021/1465) +- [Ethresear.ch لیئر 2](https://ethresear.ch/c/layer-2/32) +- [رول اپ-سینٹرک روڈ میپ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) +- [L2Beat](https://l2beat.com/) + +### برجز {#bridges} + +لیئر 2 کا ایک خاص شعبہ جس میں مزید تحقیق اور ترقی کی ضرورت ہے وہ محفوظ اور کارکردگی والے برجز ہیں۔ اس میں مختلف لیئر 2s کے درمیان برجز اور لیئر 1 اور لیئر 2 کے درمیان برجز شامل ہیں۔ یہ تحقیق کا ایک خاص طور پر اہم شعبہ ہے کیونکہ برجز کو عام طور پر ہیکرز نشانہ بناتے ہیں۔ + +#### پس منظر کا مطالعہ {#background-reading-3} + +- [بلاکچین برجز کا تعارف](/bridges/) +- [برجز پر وائٹلک](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) +- [بلاکچین برجز مضمون](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) +- [برجز میں لاک شدہ قیمت](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\)) + +#### حالیہ تحقیق {#recent-research-3} + +- [برجز کی توثیق](https://stonecoldpat.github.io/images/validatingbridges.pdf) + +### شارڈنگ {#sharding} + +ایتھیریم کے بلاکچین کی شارڈنگ طویل عرصے سے ترقیاتی روڈ میپ کا حصہ رہی ہے۔ تاہم، "ڈانکشارڈنگ" جیسے نئے اسکیلنگ حل فی الحال مرکزی حیثیت اختیار کر رہے ہیں۔ + +مکمل ڈانکشارڈنگ کا پیش خیمہ جسے پروٹو-ڈانکشارڈنگ کے نام سے جانا جاتا ہے، کینکون-ڈینیب ("ڈینکون") نیٹ ورک اپ گریڈ کے ساتھ لائیو ہوا۔ + +[ڈینکون اپ گریڈ کے بارے میں مزید](/roadmap/dencun/) + +#### پس منظر کا مطالعہ {#background-reading-4} + +- [پروٹو-ڈانکشارڈنگ نوٹس](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) +- [بینک لیس ڈانکشارڈنگ ویڈیو](https://www.youtube.com/watch?v=N5p0TB77flM) +- [ایتھیریم شارڈنگ ریسرچ کمپینڈیم](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) +- [ڈانکشارڈنگ (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe) + +#### حالیہ تحقیق {#recent-research-4} + +- [EIP-4844: پروٹو-ڈانکشارڈنگ](https://eips.ethereum.org/EIPS/eip-4844) +- [شارڈنگ اور ڈیٹا دستیابی کے نمونے پر وائٹلک](https://hackmd.io/@vbuterin/sharding_proposal) + +### ہارڈ ویئر {#hardware} + +معمولی ہارڈ ویئر پر [نوڈز چلانا](/developers/docs/nodes-and-clients/run-a-node/) ایتھیریم کو غیر مرکزی رکھنے کے لیے بنیادی ہے۔ لہذا، نوڈز چلانے کے لیے ہارڈ ویئر کی ضروریات کو کم سے کم کرنے کے لیے فعال تحقیق ایک اہم تحقیقی شعبہ ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-5} + +- [ARM پر ایتھیریم](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) + +#### حالیہ تحقیق {#recent-research-5} + +- [FPGAs پر ecdsa](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738) + +## سیکیورٹی {#security} + +سیکیورٹی ایک وسیع موضوع ہے جس میں اسپام/اسکیم کی روک تھام، والیٹ سیکیورٹی، ہارڈ ویئر سیکیورٹی، کرپٹو-اقتصادی سیکیورٹی، بگ ہنٹنگ اور ایپلی کیشنز اور کلائنٹ سافٹ ویئر کی جانچ اور کلیدی انتظام شامل ہو سکتے ہیں۔ ان شعبوں میں علم میں حصہ ڈالنا مرکزی دھارے میں اپنانے کو متحرک کرنے میں مدد کرے گا۔ + +### کرپٹوگرافی اور ZKP {#cryptography--zkp} + +زیرو-نالج پروفز (ZKP) اور کرپٹوگرافی ایتھیریم اور اس کی ایپلی کیشنز میں رازداری اور سیکیورٹی کی تعمیر کے لیے اہم ہیں۔ زیرو-نالج ایک نسبتاً نوجوان لیکن تیزی سے آگے بڑھنے والا میدان ہے جس میں تحقیق اور ترقی کے بہت سے کھلے مواقع ہیں۔ کچھ امکانات میں [Keccak ہیشنگ الگورتھم](https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview) کے زیادہ موثر نفاذ کو تیار کرنا، موجودہ سے بہتر پولی نومیل کمٹمنٹس تلاش کرنا یا ecdsa پبلک کلیدی جنریشن اور دستخطی تصدیقی سرکٹس کی لاگت کو کم کرنا شامل ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-6} + +- [0xparc بلاگ](https://0xparc.org/blog) +- [zkp.science](https://zkp.science/) +- [زیرو نالج پوڈکاسٹ](https://zeroknowledge.fm/) + +#### حالیہ تحقیق {#recent-research-6} + +- [ایلیپٹک کرو کرپٹوگرافی میں حالیہ پیش رفت](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346) +- [Ethresear.ch ZK](https://ethresear.ch/c/zk-s-nt-arks/13) + +### والیٹس {#wallets} + +ایتھیریم والیٹس براؤزر ایکسٹینشنز، ڈیسک ٹاپ اور موبائل ایپس یا ایتھیریم پر اسمارٹ کنٹریکٹس ہو سکتے ہیں۔ سوشل ریکوری والیٹس پر فعال تحقیق جاری ہے جو انفرادی صارف کے کلیدی انتظام سے وابستہ کچھ خطرات کو کم کرتی ہے۔ والیٹس کی ترقی سے وابستہ تحقیق اکاؤنٹ ابسٹریکشن کی متبادل شکلوں پر ہے، جو کہ نوزائیدہ تحقیق کا ایک اہم شعبہ ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-7} + +- [والیٹس کا تعارف](/wallets/) +- [والیٹ سیکیورٹی کا تعارف](/security/) +- [Ethresear.ch سیکیورٹی](https://ethresear.ch/tag/security) +- [EIP-2938 اکاؤنٹ ابسٹریکشن](https://eips.ethereum.org/EIPS/eip-2938) +- [EIP-4337 اکاؤنٹ ابسٹریکشن](https://eips.ethereum.org/EIPS/eip-4337) + +#### حالیہ تحقیق {#recent-research-7} + +- [تصدیق پر مرکوز اسمارٹ کنٹریکٹ والیٹس](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) +- [اکاؤنٹس کا مستقبل](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) +- [EIP-3074 AUTH اور AUTHCALL Opcodes](https://eips.ethereum.org/EIPS/eip-3074) +- [EOA ایڈریس پر کوڈ شائع کرنا](https://eips.ethereum.org/EIPS/eip-5003) + +## کمیونٹی، تعلیم اور آؤٹ ریچ {#community-education-and-outreach} + +ایتھیریم پر نئے صارفین کو آن بورڈ کرنے کے لیے نئے تعلیمی وسائل اور آؤٹ ریچ کے طریقوں کی ضرورت ہوتی ہے۔ اس میں بلاگ پوسٹس اور مضامین، کتابیں، پوڈکاسٹس، میمز، تدریسی وسائل، تقریبات اور کوئی بھی دوسری چیز شامل ہو سکتی ہے جو کمیونٹیز بناتی ہے، نئے آنے والوں کا خیرمقدم کرتی ہے اور لوگوں کو ایتھیریم کے بارے میں تعلیم دیتی ہے۔ + +### UX/UI {#uxui} + +ایتھیریم پر مزید لوگوں کو آن بورڈ کرنے کے لیے، ایکو سسٹم کو UX/UI کو بہتر بنانا چاہیے۔ اس کے لیے ڈیزائنرز اور پروڈکٹ ماہرین کو والیٹس اور ایپس کے ڈیزائن کا دوبارہ جائزہ لینے کی ضرورت ہوگی۔ + +#### پس منظر کا مطالعہ {#background-reading-8} + +- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24) + +#### حالیہ تحقیق {#recent-research-8} + +- [Web3 ڈیزائن ڈسکارڈ](https://discord.gg/FsCFPMTSm9) +- [Web3 ڈیزائن کے اصول](https://www.web3designprinciples.com/) +- [ایتھیریم میجیشنز UX بحث](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3) + +### معاشیات {#economics} + +ایتھیریم میں معاشیات کی تحقیق وسیع پیمانے پر دو طریقوں پر عمل کرتی ہے: اقتصادی ترغیبات پر انحصار کرنے والے میکانزم کی سیکیورٹی کی توثیق کریں ("مائیکرو اکنامکس") اور پروٹوکولز، ایپلی کیشنز اور صارفین کے درمیان قدر کے بہاؤ کا تجزیہ کریں ("میکرو اکنامکس")۔ ایتھیریم کے مقامی اثاثے (ایتھر) اور اس کے اوپر بنائے گئے ٹوکنز (مثال کے طور پر NFTs اور ERC20 ٹوکنز) سے متعلق پیچیدہ کرپٹو-اقتصادی عوامل ہیں۔ + +#### پس منظر کا مطالعہ {#background-reading-9} + +- [مضبوط ترغیبات کا گروپ](https://rig.ethereum.org/) +- [Devconnect میں ETHconomics ورکشاپ](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm) + +#### حالیہ تحقیق {#recent-research-9} + +- [EIP1559 کا تجرباتی تجزیہ](https://arxiv.org/abs/2201.05574) +- [گردشی سپلائی کا توازن](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954) +- [MEV کی مقدار کا تعین: جنگل کتنا تاریک ہے؟](https://arxiv.org/abs/2101.05511) + +### بلاک اسپیس اور فیس مارکیٹس {#blockspace-fee-markets} + +بلاک اسپیس مارکیٹس آخری صارف کے لین دین کی شمولیت کو کنٹرول کرتی ہیں، یا تو براہ راست ایتھیریم (لیئر 1) پر یا برجڈ نیٹ ورکس پر، مثلاً، رول اپس (لیئر 2)۔ ایتھیریم پر، لین دین کو EIP-1559 کے طور پر پروٹوکول میں تعینات فیس مارکیٹ میں جمع کرایا جاتا ہے، جو چین کو اسپام اور قیمتوں کے بھیڑ سے بچاتا ہے۔ دونوں تہوں پر، لین دین بیرونی اثرات پیدا کر سکتا ہے، جسے میکسیمل ایکسٹریکٹ ایبل ویلیو (MEV) کے نام سے جانا جاتا ہے، جو ان بیرونی اثرات کو پکڑنے یا ان کا انتظام کرنے کے لیے نئے مارکیٹ ڈھانچے کو جنم دیتا ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-10} + +- [ایتھیریم بلاکچین کے لیے لین دین فیس میکانزم ڈیزائن: EIP-1559 کا اقتصادی تجزیہ (Tim Roughgarden, 2020)](https://timroughgarden.org/papers/eip1559.pdf) +- [EIP-1559 کے سیمولیشنز (مضبوط ترغیبات کا گروپ)](https://ethereum.github.io/abm1559) +- [پہلے اصولوں سے رول اپ معاشیات](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url) +- [فلیش بوائز 2.0: غیر مرکزی تبادلے میں فرنٹ رننگ، لین دین کی دوبارہ ترتیب، اور اتفاق رائے میں عدم استحکام](https://arxiv.org/abs/1904.05234) + +#### حالیہ تحقیق {#recent-research-10} + +- [کثیر جہتی EIP-1559 ویڈیو پریزنٹیشن](https://youtu.be/QbR4MTgnCko) +- [کراس ڈومین MEV](http://arxiv.org/abs/2112.01472) +- [MEV نیلامی](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) + +### پروف-آف-اسٹیک ترغیبات {#proof-of-stake-incentives} + +توثیق کنندگان ایتھیریم کے مقامی اثاثے (ایتھر) کو بے ایمانی کے خلاف ضمانت کے طور پر استعمال کرتے ہیں۔ اس کی کرپٹو اکنامکس نیٹ ورک کی سیکیورٹی کا تعین کرتی ہے۔ جدید توثیق کنندگان صریح حملے شروع کرنے کے لیے ترغیبی تہہ کی باریکیوں کا فائدہ اٹھا سکتے ہیں۔ + +#### پس منظر کا مطالعہ {#background-reading-11} + +- [ایتھیریم معاشیات ماسٹر کلاس اور اقتصادی ماڈل](https://github.com/CADLabs/ethereum-economic-model) +- [PoS ترغیبات کے سیمولیشنز (مضبوط ترغیبات کا گروپ)](https://ethereum.github.io/beaconrunner/) + +#### حالیہ تحقیق {#recent-research-11} + +- [تجویز کنندہ/بلڈر کی علیحدگی (PBS) کے تحت لین دین کی سنسرشپ مزاحمت میں اضافہ](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) +- [PoS ایتھیریم پر تین حملے](https://arxiv.org/abs/2110.10086) + +### لیکوئڈ اسٹیکنگ اور ڈیریویٹوز {#liquid-staking-and-derivatives} + +لیکوئڈ اسٹیکنگ 32 ETH سے کم والے صارفین کو DeFi میں استعمال کیے جانے والے اسٹیک شدہ ایتھر کی نمائندگی کرنے والے ٹوکن کے لیے ایتھر کی ادلا بدلی کرکے اسٹیکنگ کی پیداوار حاصل کرنے کی اجازت دیتی ہے۔ تاہم، لیکوئڈ اسٹیکنگ سے وابستہ ترغیبات اور مارکیٹ کی حرکیات اب بھی دریافت کی جا رہی ہیں، نیز ایتھیریم کی سیکیورٹی پر اس کا اثر (مثلاً، مرکزیت کے خطرات)۔ + +#### پس منظر کا مطالعہ {#background-reading-12} + +- [Ethresear.ch لیکوئڈ اسٹیکنگ](https://ethresear.ch/search?q=liquid%20staking) +- [Lido: بے بھروسہ ایتھیریم اسٹیکنگ کا راستہ](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/) +- [راکٹ پول: اسٹیکنگ پروٹوکول کا تعارف](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd) + +#### حالیہ تحقیق {#recent-research-12} + +- [Lido سے واپسی کو سنبھالنا](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) +- [واپسی کی اسناد](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722) +- [لیکوئڈ اسٹیکنگ ڈیریویٹوز کے خطرات](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## جانچ {#testing} + +### باضابطہ تصدیق {#formal-verification} + +باضابطہ تصدیق اس بات کی تصدیق کے لیے کوڈ لکھ رہی ہے کہ ایتھیریم کی اتفاق رائے کی تفصیلات درست اور بگ سے پاک ہیں۔ Python میں لکھی گئی تفصیلات کا ایک قابل عمل ورژن ہے جسے دیکھ بھال اور ترقی کی ضرورت ہے۔ مزید تحقیق تفصیلات کے Python نفاذ کو بہتر بنانے اور ایسے ٹولز شامل کرنے میں مدد کر سکتی ہے جو درستگی کی زیادہ مضبوطی سے تصدیق کر سکتے ہیں اور مسائل کی نشاندہی کر سکتے ہیں۔ + +#### پس منظر کا مطالعہ {#background-reading-13} + +- [باضابطہ تصدیق کا تعارف](https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html) +- [باضابطہ تصدیق (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf) + +#### حالیہ تحقیق {#recent-research-13} + +- [ڈپازٹ کنٹریکٹ کی باضابطہ تصدیق](https://github.com/runtimeverification/deposit-contract-verification) +- [بیکن چین کی تفصیلات کی باضابطہ تصدیق](https://github.com/runtimeverification/deposit-contract-verification) + +## ڈیٹا سائنس اور تجزیات {#data-science-and-analytics} + +مزید ڈیٹا تجزیہ کے ٹولز اور ڈیش بورڈز کی ضرورت ہے جو ایتھیریم پر سرگرمی اور نیٹ ورک کی صحت کے بارے میں تفصیلی معلومات فراہم کریں۔ + +### پس منظر کا مطالعہ {#background-reading-14} + +- [Dune تجزیات](https://dune.com/browse/dashboards) +- [کلائنٹ تنوع ڈیش بورڈ](https://clientdiversity.org/) + +#### حالیہ تحقیق {#recent-research-14} + +- [مضبوط ترغیبات گروپ ڈیٹا تجزیہ](https://rig.ethereum.org/) + +## ایپس اور ٹولنگ {#apps-and-tooling} + +ایپلی کیشن لیئر پروگراموں کے ایک متنوع ایکو سسٹم کو سپورٹ کرتی ہے جو ایتھیریم کی بنیادی تہہ پر لین دین کو طے کرتے ہیں۔ ڈیولپمنٹ ٹیمیں اہم Web2 ایپس کے کمپوز ایبل، اجازت کے بغیر اور سنسرشپ مزاحم ورژن بنانے یا مکمل طور پر نئے Web3-نیٹیو تصورات بنانے کے لیے ایتھیریم سے فائدہ اٹھانے کے نئے طریقے مسلسل تلاش کر رہی ہیں۔ اسی وقت، نئی ٹولنگ تیار کی جا رہی ہے جو ایتھیریم پر dapps کی تعمیر کو کم پیچیدہ بناتی ہے۔ + +### DeFi {#defi} + +غیر مرکزی مالیات (DeFi) ایتھیریم کے اوپر بنائی گئی ایپلی کیشن کی بنیادی کلاسوں میں سے ایک ہے۔ DeFi کا مقصد کمپوز ایبل "منی لیگوز" بنانا ہے جو صارفین کو اسمارٹ کنٹریکٹس کا استعمال کرکے کرپٹو اثاثوں کو ذخیرہ کرنے، منتقل کرنے، قرض دینے، قرض لینے اور سرمایہ کاری کرنے کی اجازت دیتے ہیں۔ DeFi ایک تیزی سے آگے بڑھنے والا میدان ہے جو مسلسل اپ ڈیٹ ہو رہا ہے۔ محفوظ، موثر اور قابل رسائی پروٹوکولز پر تحقیق کی مسلسل ضرورت ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-15} + +- [DeFi](/defi/) +- [Coinbase: DeFi کیا ہے؟](https://www.coinbase.com/learn/crypto-basics/what-is-defi) + +#### حالیہ تحقیق {#recent-research-15} + +- [غیر مرکزی مالیات، مرکزی ملکیت؟](https://arxiv.org/pdf/2012.09306.pdf) +- [امید: ذیلی ڈالر کے لین دین کا راستہ](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) + +### DAOs {#daos} + +ایتھیریم کے لیے ایک مؤثر استعمال کا معاملہ DAOs کے استعمال کے ذریعے غیر مرکزی انداز میں منظم کرنے کی صلاحیت ہے۔ اس بارے میں بہت زیادہ فعال تحقیق جاری ہے کہ ایتھیریم پر DAOs کو کس طرح تیار اور استعمال کیا جا سکتا ہے تاکہ حکمرانی کی بہتر شکلوں کو نافذ کیا جا سکے، ایک بھروسہ کم سے کم کوآرڈینیشن ٹول کے طور پر، روایتی کارپوریشنوں اور تنظیموں سے آگے لوگوں کے اختیارات کو بہت زیادہ بڑھایا جا سکے۔ + +#### پس منظر کا مطالعہ {#background-reading-16} + +- [DAOs کا تعارف](/dao/) +- [Dao Collective](https://daocollective.xyz/) + +#### حالیہ تحقیق {#recent-research-16} + +- [DAO ایکو سسٹم کی میپنگ](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy) + +### ڈویلپر ٹولز {#developer-tools} + +ایتھیریم ڈویلپرز کے لیے ٹولز تیزی سے بہتر ہو رہے ہیں۔ اس عمومی شعبے میں کرنے کے لیے بہت ساری فعال تحقیق اور ترقی ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-17} + +- [پروگرامنگ زبان کے لحاظ سے ٹولنگ](/developers/docs/programming-languages/) +- [ڈویلپر فریم ورک](/developers/docs/frameworks/) +- [اتفاق رائے ڈویلپر ٹولز کی فہرست](https://github.com/ConsenSys/ethereum-developer-tools-list) +- [ٹوکن معیارات](/developers/docs/standards/tokens/) +- [CryptoDevHub: EVM ٹولز](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools) + +#### حالیہ تحقیق {#recent-research-17} + +- [Eth R&D Discord اتفاق رائے ٹولنگ چینل](https://discordapp.com/channels/595666850260713488/746343380900118528) + +### اوریکلز {#oracles} + +اوریکلز آف چین ڈیٹا کو بلاکچین پر بغیر اجازت اور غیر مرکزی طریقے سے درآمد کرتے ہیں۔ اس ڈیٹا کو آن چین حاصل کرنا dapps کو حقیقی دنیا کے مظاہر جیسے حقیقی دنیا کے اثاثوں میں قیمت کے اتار چڑھاؤ، آف چین ایپس میں واقعات، یا موسم میں تبدیلیوں پر بھی رد عمل ظاہر کرنے کے قابل بناتا ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-18} + +- [اوریکلز کا تعارف](/developers/docs/oracles/) + +#### حالیہ تحقیق {#recent-research-18} + +- [بلاکچین اوریکلز کا سروے](https://arxiv.org/pdf/2004.07140.pdf) +- [Chainlink وائٹ پیپر](https://chain.link/whitepaper) + +### ایپ سیکیورٹی {#app-security} + +ایتھیریم پر ہیکس عام طور پر پروٹوکول میں نہیں بلکہ انفرادی ایپلی کیشنز میں کمزوریوں کا فائدہ اٹھاتے ہیں۔ ہیکرز اور ایپ ڈویلپرز نئے حملوں اور دفاع کو تیار کرنے کے لیے ہتھیاروں کی دوڑ میں بند ہیں۔ اس کا مطلب ہے کہ ایپس کو ہیکس سے محفوظ رکھنے کے لیے ہمیشہ اہم تحقیق اور ترقی کی ضرورت ہوتی ہے۔ + +#### پس منظر کا مطالعہ {#background-reading-19} + +- [Wormhole استحصال کی رپورٹ](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/) +- [ایتھیریم کنٹریکٹ ہیک پوسٹ مارٹم کی فہرست](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) +- [Rekt News](https://x.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg) + +#### حالیہ تحقیق {#recent-research-19} + +- [Ethresear.ch ایپلی کیشنز](https://ethresear.ch/c/applications/18) + +### ٹیکنالوجی اسٹیک {#technology-stack} + +پورے ایتھیریم ٹیک اسٹیک کو غیر مرکزی بنانا ایک اہم تحقیقی شعبہ ہے۔ فی الحال، ایتھیریم پر dapps میں عام طور پر مرکزیت کے کچھ نکات ہوتے ہیں کیونکہ وہ مرکزی ٹولنگ یا انفراسٹرکچر پر انحصار کرتے ہیں۔ + +#### پس منظر کا مطالعہ {#background-reading-20} + +- [ایتھیریم اسٹیک](/developers/docs/ethereum-stack/) +- [Coinbase: Web3 اسٹیک کا تعارف](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0) +- [اسمارٹ کنٹریکٹس کا تعارف](/developers/docs/smart-contracts/) +- [غیر مرکزی اسٹوریج کا تعارف](/developers/docs/storage/) + +#### حالیہ تحقیق {#recent-research-20} + +- [اسمارٹ کنٹریکٹ کمپوز ایبلٹی](/developers/docs/smart-contracts/composability/) diff --git a/public/content/translations/ur/community/support/index.md b/public/content/translations/ur/community/support/index.md new file mode 100644 index 00000000000..77d5a0d0c1d --- /dev/null +++ b/public/content/translations/ur/community/support/index.md @@ -0,0 +1,104 @@ +--- +title: "Ethereum سپورٹ" +description: "ایتھیریم ایکوسسٹم میں سپورٹ حاصل کریں۔" +lang: ur-in +--- + +# ایتھیریم سپورٹ {#support} + +## آفیشیل ایتھیریم سپورٹ {#official-support} + +کیا آپ آفیشیل ایتھیریم سپورٹ تلاش کر رہے ہیں؟ پہلی بات جو آپ کو معلوم ہونی چاہئے وہ یہ ہے کہ ایتھیریم ڈی سینٹرالائزڈ ہے۔ اس کا مطلب ہے کہ کوئی بھی مرکزی تنظیم، ادارہ، یا شخص ایتھیریم کا مالک نہیں ہے، اور اسی وجہ سے، کوئی آفیشیل سپورٹ چینل موجود نہیں ہے۔ + +ایتھیریم کی ڈی سینٹرالائزڈ نوعیت کو سمجھنا بہت ضروری ہے کیونکہ **کوئی بھی شخص جو ایتھیریم کے لیے آفیشیل سپورٹ ہونے کا دعویٰ کرتا ہے وہ شاید آپ کے ساتھ دھوکہ دہی کرنے کی کوشش کر رہا ہے!** اسکیمرز سے بہترین تحفظ خود کو تعلیم دینا اور سیکیورٹی کو سنجیدگی سے لینا ہے۔ + + + ایتھیریم سیکیورٹی اور اسکیم سے بچاؤ + + + + ایتھیریم کے بنیادی اصول سیکھیں + + +آفیشیل سپورٹ کی کمی کے باوجود، ایتھیریم ایکوسسٹم میں بہت سے گروپس، کمیونٹیز، اور پروجیکٹس مدد کرنے میں خوش ہیں، اور آپ اس صفحے پر بہت سی مفید معلومات اور وسائل تلاش کر سکتے ہیں۔ اب بھی سوالات ہیں؟ [ethereum.org ڈسکارڈ](https://discord.gg/ethereum-org) میں شامل ہوں، اور ہم مدد کرنے کی کوشش کریں گے۔ + +## اکثر پوچھے جانے والے سوالات {#faq} + +### میں نے غلط والیٹ میں ETH بھیج دیا ہے {#wrong-wallet} + +ایتھیریم پر بھیجی گئی ٹرانزیکشن ناقابل واپسی ہے۔ بدقسمتی سے، اگر آپ نے غلط والیٹ میں ETH بھیج دیا ہے، تو ان فنڈز کو واپس حاصل کرنے کا کوئی طریقہ نہیں ہے۔ کوئی بھی مرکزی تنظیم، ادارہ، یا شخص ایتھیریم کا مالک نہیں ہے، جس کا مطلب ہے کہ کوئی بھی ٹرانزیکشنز کو ریورس نہیں کر سکتا۔ اس لیے، بھیجنے سے پہلے ہمیشہ اپنی ٹرانزیکشنز کو دو بار چیک کرنا بہت ضروری ہے۔ + +### میں اپنا ایتھیریم گیو اوے کیسے کلیم کر سکتا ہوں؟ {#giveaway-scam} + +ایتھیریم گیو اوے اسکیمز ہیں جو آپ کے ETH چرانے کے لیے بنائے گئے ہیں۔ ایسی پیشکشوں سے لالچ میں نہ آئیں جو سچ ہونے کے لیے بہت اچھی لگتی ہیں — اگر آپ کسی گیو اوے ایڈریس پر ETH بھیجتے ہیں، تو آپ کو کوئی گیو اوے نہیں ملے گا، اور آپ اپنے فنڈز واپس حاصل نہیں کر پائیں گے۔ + +[اسکیم سے بچاؤ پر مزید](/security/#common-scams) + +### میری ٹرانزیکشن پھنس گئی ہے {#stuck-transaction} + +ایتھیریم پر ٹرانزیکشنز کبھی کبھی پھنس سکتی ہیں اگر آپ نے نیٹ ورک کی ڈیمانڈ کی وجہ سے مطلوبہ ٹرانزیکشن فیس سے کم فیس جمع کی ہے۔ بہت سے والیٹس اسی ٹرانزیکشن کو زیادہ ٹرانزیکشن فیس کے ساتھ دوبارہ جمع کرانے کا آپشن فراہم کرتے ہیں تاکہ ٹرانزیکشن پر عمل ہو سکے۔ متبادل کے طور پر، آپ اپنے ہی ایڈریس پر ایک ٹرانزیکشن بھیج کر اور پینڈنگ ٹرانزیکشن کے طور پر وہی نونس (nonce) استعمال کرکے ایک پینڈنگ ٹرانزیکشن کو منسوخ کر سکتے ہیں۔ + +[MetaMask پر ایک پینڈنگ ٹرانزیکشن کو کیسے تیز کریں یا منسوخ کریں](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction) + +[پینڈنگ ایتھیریم ٹرانزیکشنز کو کیسے منسوخ کریں](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/) + +### میں ایتھیریم کو کیسے مائن کروں؟ {#mining-ethereum} + +ایتھیریم مائننگ اب ممکن نہیں ہے۔ مائننگ کو بند کر دیا گیا تھا جب ایتھیریم [پروف-آف-ورک](/glossary/#pow) سے [پروف-آف-اسٹیک](/glossary/#pos) پر منتقل ہوا۔ اب، مائنرز کے بجائے، ایتھیریم میں ویلیڈیٹرز ہیں۔ کوئی بھی ETH [اسٹیک](/glossary/#staking) کر سکتا ہے اور نیٹ ورک کو محفوظ بنانے کے لیے ویلیڈیٹر سافٹ ویئر چلا کر اسٹیکنگ ریوارڈز حاصل کر سکتا ہے۔ + +### میں ایک اسٹیکر / ویلیڈیٹر کیسے بن سکتا ہوں؟ {#how-to-stake} + +ایک ویلیڈیٹر بننے کے لیے، آپ کو ایتھیریم ڈیپازٹ کنٹریکٹ میں 32 ETH اسٹیک کرنا ہوگا اور ایک ویلیڈیٹر نوڈ سیٹ اپ کرنا ہوگا۔ مزید معلومات ہمارے [اسٹیکنگ پیجز](/staking) پر اور [اسٹیکنگ لانچ پیڈ](https://launchpad.ethereum.org/) پر دستیاب ہے۔ + +## dapps بنانا {#building-support} + +تعمیر کرنا مشکل ہو سکتا ہے۔ یہاں کچھ ڈیولپمنٹ پر مرکوز جگہیں ہیں جن میں تجربہ کار ایتھیریم ڈیولپرز موجود ہیں جو مدد کرنے میں خوش ہیں۔ + +- [Alchemy University](https://university.alchemy.com/#starter_code) +- [CryptoDevs discord](https://discord.com/invite/5W5tVb3) +- [Ethereum StackExchange](https://ethereum.stackexchange.com/) +- [Web3 University](https://www.web3.university/) +- [LearnWeb3](https://discord.com/invite/learnweb3) + +آپ ہمارے [ایتھیریم ڈیولپر وسائل](/developers/) سیکشن میں ڈاکومنٹیشن اور ڈیولپمنٹ گائیڈز بھی تلاش کر سکتے ہیں۔ + +### ٹولنگ {#dapp-tooling} + +کیا آپ کا سوال کسی خاص ٹول، پروجیکٹ، یا لائبریری سے متعلق ہے؟ زیادہ تر پروجیکٹس کے پاس چیٹ سرورز یا فورمز ہوتے ہیں جو آپ کو سپورٹ کرنے کے لیے وقف ہیں۔ + +یہاں کچھ مشہور مثالیں ہیں: + +- [Solidity](https://gitter.im/ethereum/solidity) +- [ethers.js](https://discord.gg/6jyGVDK6Jx) +- [web3.js](https://discord.gg/GsABYQu4sC) +- [Hardhat](https://discord.gg/xtrMGhmbfZ) +- [Alchemy](http://alchemy.com/discord) +- [Tenderly](https://discord.gg/fBvDJYR) + +## ایک نوڈ چلانا {#node-support} + +اگر آپ ایک نوڈ یا ویلیڈیٹر چلا رہے ہیں، تو یہاں کچھ کمیونٹیز ہیں جو آپ کو شروع کرنے میں مدد کے لیے وقف ہیں۔ + +- [EthStaker discord](https://discord.gg/ethstaker) +- [EthStaker reddit](https://www.reddit.com/r/ethstaker) + +ایتھیریم کلائنٹس بنانے والی زیادہ تر ٹیموں کے پاس بھی وقف، عوامی جگہیں ہوتی ہیں جہاں آپ سپورٹ حاصل کر سکتے ہیں اور سوالات پوچھ سکتے ہیں۔ + +### ایگزیکیوشن کلائنٹس {#execution-clients} + +- [Geth](https://discord.gg/FqDzupGyYf) +- [Nethermind](https://discord.gg/YJx3pm8z5C) +- [Besu](https://discord.gg/p8djYngzKN) +- [Erigon](https://github.com/ledgerwatch/erigon/issues) +- [Reth](https://github.com/paradigmxyz/reth/discussions) + +### کنسینسس کلائنٹس {#consensus-clients} + +- [Prysm](https://discord.gg/prysmaticlabs) +- [Nimbus](https://discord.gg/nSmEH3qgFv) +- [Lighthouse](https://discord.gg/cyAszAh) +- [Teku](https://discord.gg/7hPv2T6) +- [Lodestar](https://discord.gg/aMxzVcr) +- [Grandine](https://discord.gg/H9XCdUSyZd) + +آپ [یہاں ایک نوڈ چلانے کا طریقہ بھی سیکھ سکتے ہیں](/developers/docs/nodes-and-clients/run-a-node/)۔ diff --git a/public/content/translations/ur/contributing/adding-desci-projects/index.md b/public/content/translations/ur/contributing/adding-desci-projects/index.md new file mode 100644 index 00000000000..9b3d813b23f --- /dev/null +++ b/public/content/translations/ur/contributing/adding-desci-projects/index.md @@ -0,0 +1,44 @@ +--- +title: "DeSci پراجیکٹس کو شامل کرنا" +description: "ethereum.org پر DeSci صفحہ پر پروجیکٹس کا لنک شامل کرتے وقت ہم جو پالیسی استعمال کرتے ہیں۔" +lang: ur-in +--- + +# پروجیکٹس شامل کرنا {#adding-projects} + +ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہم مختلف قسم کے پراجیکٹس دکھائیں اور DeSci لینڈ اسکیپ کا ایک اچھا سنیپ شاٹ دیں۔ + +کوئی بھی ethereum.org پر DeSci صفحہ پر فہرست میں شامل کرنے کے لیے کسی پراجیکٹ کی تجویز دینے کے لیے آزاد ہے۔ اسی طرح، کوئی بھی جو کسی ایسے پروجیکٹ کو دیکھتا ہے جو اب متعلقہ نہیں ہے یا ہمارے اہلیت کے معیار پر پورا نہیں اترتا ہے، اسے ہٹانے کی تجویز دینے کے لیے آزاد ہے۔ + +## فیصلے کا فریم ورک {#the-decision-framework} + +### شامل کرنے کے معیارات: لازمی چیزیں {#the-must-haves} + +- **اوپن سورس کوڈ/ڈیٹا** - کوڈ اور ڈیٹا کا کھلا پن DeSci کا ایک بنیادی اصول ہے، اس لیے DeSci پراجیکٹس کو کلوزڈ سورس نہیں ہونا چاہیے۔ کوڈ بیس قابل رسائی ہونا چاہئے اور مثالی طور پر PRs کے لیے کھلا ہونا چاہئے۔ +- **DeSci پراجیکٹس کو واضح طور پر ڈی سینٹرلائزڈ ہونا چاہئے** - اس میں DAO کے ذریعے حکومت کرنا، یا نان-کسٹوڈیل والٹس سمیت ڈی سینٹرلائزڈ ٹیک اسٹیک کے ساتھ تعمیر کرنا شامل ہوسکتا ہے۔ اس میں شاید Ethereum پر قابلِ آڈٹ اسمارٹ کنٹریکٹس شامل ہیں۔ +- **ایماندار اور درست فہرست سازی کی معلومات** - یہ توقع کی جاتی ہے کہ پراجیکٹس سے کوئی بھی تجویز کردہ فہرست ایماندار اور درست معلومات کے ساتھ آئے۔ وہ پروڈکٹس جو فہرست سازی کی معلومات کو غلط ثابت کرتے ہیں، جیسے کہ یہ اعلان کرنا کہ آپ کا پروڈکٹ "اوپن سورس" ہے جب کہ وہ نہیں ہے، ہٹا دیا جائے گا۔ +- **سائنس تک رسائی کو وسیع کرنے کے لیے قابلِ مظاہرہ عزم** - ایک DeSci پراجیکٹ کو یہ بیان کرنے کے قابل ہونا چاہیے کہ وہ سائنس میں عام لوگوں کی شرکت کو کس طرح وسیع کرتے ہیں، نہ کہ صرف ٹوکن/NFT ہولڈرز کے لیے۔ +- **عالمی سطح پر قابل رسائی** - آپ کے پروجیکٹ میں جغرافیائی حدود یا KYC کی ضروریات نہیں ہیں جو کچھ لوگوں کو آپ کی سروس تک رسائی سے خارج کرتی ہیں۔ +- **معلوماتی ویب سائٹ اور دستاویزات** - یہ ضروری ہے کہ پراجیکٹ کی ویب سائٹ پر آنے والے لوگ یہ سمجھ سکیں کہ پراجیکٹ اصل میں کیا کرتا ہے، یہ سائنس کے بنیادی ڈھانچے کو ڈی سینٹرلائز کرنے میں کس طرح حصہ ڈالتا ہے اور اس میں کیسے حصہ لینا ہے۔ +- **پروجیکٹ کو Ethereum ایکو سسٹم کا حصہ ہونا چاہیے** - ethereum.org پر ہم سمجھتے ہیں کہ Ethereum (اور اس کے Layer 2's) DeSci تحریک کے لیے مناسب بنیادی تہہ ہیں۔ +- **پروجیکٹ کافی اچھی طرح سے قائم ہے** - پروجیکٹ کے حقیقی صارفین ہیں جو کئی مہینوں سے پروجیکٹ کی خدمات تک رسائی حاصل کرنے میں کامیاب رہے ہیں۔ + +### پسندیدہ خصوصیات + +- **متعدد زبانوں میں دستیاب** - آپ کا پروجیکٹ متعدد زبانوں میں ترجمہ کیا گیا ہے جس سے دنیا بھر کے صارفین اس تک رسائی حاصل کر سکتے ہیں۔ +- **تعلیمی وسائل** - آپ کے پروڈکٹ میں صارفین کی مدد اور تعلیم کے لیے ایک اچھی طرح سے ڈیزائن کیا گیا آن بورڈنگ تجربہ ہونا چاہیے۔ یا مضامین یا ویڈیوز جیسے کیسے کریں مواد کا ثبوت۔ +- **تھرڈ پارٹی آڈٹ** - آپ کے پروڈکٹ کو کسی قابل اعتماد تھرڈ پارٹی کے ذریعے کمزوریوں کے لیے پیشہ ورانہ طور پر آڈٹ کیا گیا ہے۔ +- **رابطے کا مقام** - پروجیکٹ کے لیے رابطے کا ایک مقام (یہ کسی DAO یا کمیونٹی کے نمائندے کے ذریعے ہوسکتا ہے) تبدیلیاں کیے جانے پر ہمیں درست معلومات حاصل کرنے میں بہت مدد کرے گا۔ اس سے مستقبل کی معلومات اکٹھا کرتے وقت ethereum.org کو اپ ڈیٹ کرنا قابل انتظام رہے گا۔ + +## دیکھ بھال {#maintenance} + +جیسا کہ Ethereum کی فطرت متغیر ہے، ٹیمیں اور پروڈکٹس آتے جاتے رہتے ہیں اور روزانہ جدت ہوتی رہتی ہے، اس لیے ہم اپنے مواد کی معمول کی جانچ پڑتال کریں گے تاکہ: + +- یقینی بنائیں کہ تمام فہرست شدہ پراجیکٹس اب بھی ہمارے معیار پر پورا اترتے ہیں۔ +- تصدیق کریں کہ ایسے کوئی پروڈکٹس نہیں ہیں جن کی تجویز دی گئی ہو جو ہمارے معیار پر موجودہ فہرست میں شامل پروڈکٹس سے زیادہ پورا اترتے ہوں۔ + +Ethereum.org کو اوپن سورس کمیونٹی کے ذریعے برقرار رکھا جاتا ہے اور ہم اسے اپ ٹو ڈیٹ رکھنے میں مدد کے لیے کمیونٹی پر انحصار کرتے ہیں۔ اگر آپ کو فہرست شدہ پراجیکٹس کے بارے میں کوئی ایسی معلومات نظر آتی ہے جسے اپ ڈیٹ کرنے کی ضرورت ہے، تو براہ کرم ہماری GitHub ریپوزٹری پر ایک ایشو یا پل کی درخواست کھولیں۔ + +## استعمال کی شرائط {#terms-of-use} + +براہ کرم ہماری [استعمال کی شرائط](/terms-of-use/) بھی دیکھیں۔ ethereum.org پر معلومات صرف عام معلومات کے مقاصد کے لیے فراہم کی جاتی ہے۔ diff --git a/public/content/translations/ur/contributing/adding-developer-tools/index.md b/public/content/translations/ur/contributing/adding-developer-tools/index.md new file mode 100644 index 00000000000..8665e904a58 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-developer-tools/index.md @@ -0,0 +1,61 @@ +--- +title: "ڈویلپر ٹولز شامل کرنا" +lang: ur-in +description: "ethereum.org پر ڈیولپر ٹولز کی فہرست سازی کے لیے ہمارے معیار" +--- + +# ڈویلپر ٹولز شامل کرنا {#contributing-to-ethereumorg-} + +ہم یہ یقینی بنانا چاہتے ہیں کہ ہم بہترین ممکنہ ڈیولپر وسائل کی فہرست بنائیں تاکہ لوگ اعتماد کے ساتھ تعمیر کر سکیں اور انہیں وہ مدد مل سکے جس کی انہیں ضرورت ہے۔ + +اگر کوئی مددگار ڈیولپر ٹول ہے جو ہم سے چھوٹ گیا ہے، تو بلا جھجھک اسے کسی مناسب جگہ پر تجویز کریں۔ + +ہم فی الحال اپنے [ڈیولپر پورٹل](/developers/) پر ڈیولپر ٹولز کی فہرست بناتے ہیں۔ + +**مناسب صفحات پر نئے اضافے بلا جھجھک تجویز کریں۔** + +## ہم کیسے فیصلہ کرتے ہیں {#ways-to-contribute} + +ڈیولپر ٹول کی گذارشات کا جائزہ درج ذیل معیارات کی بنیاد پر لیا جائے گا: + +**کیا یہ پہلے سے درج ٹولز سے بامعنی طور پر مختلف ہے؟** + +- ٹولز کے نئے زمرے یا اقسام +- موجودہ ملتے جلتے ٹولز کے مقابلے نئی خصوصیات +- ایک ایسے مخصوص استعمال کے لیے بنایا گیا ہے جو موجودہ ملتے جلتے ٹولز میں شامل نہیں ہے۔ + +**کیا ٹول اچھی طرح سے دستاویزی ہے؟** + +- کیا دستاویزات موجود ہیں؟ +- کیا یہ ٹول استعمال کرنے کے لیے کافی ہے؟ +- کیا اسے حال ہی میں اپ ڈیٹ کیا گیا ہے؟ + +**کیا ٹول بڑے پیمانے پر استعمال ہوتا ہے؟** + +- ہم GitHub اسٹارز اور ڈاؤن لوڈ کے اعدادوشمار جیسے میٹرکس پر غور کریں گے، اور اس بات پر بھی کہ آیا اسے معروف کمپنیاں یا پروجیکٹس استعمال کرتے ہیں۔ + +**کیا ٹول کافی معیار کا ہے؟** + +- کیا بار بار آنے والے بگز ہیں؟ +- کیا ٹول قابل اعتماد ہے؟ +- کیا ٹول کو فعال طور پر برقرار رکھا گیا ہے؟ + +**کیا یہ ٹول اوپن سورس ہے؟** + +Ethereum اسپیس میں بہت سے پروجیکٹس اوپن سورس ہیں۔ ہم اوپن سورس پروجیکٹس کی فہرست بنانے کا زیادہ امکان رکھتے ہیں جو کمیونٹی ڈیولپرز کو کوڈ کا معائنہ کرنے اور اس میں حصہ ڈالنے کی اجازت دیتے ہیں۔ + +--- + +## پروڈکٹ کی ترتیب {#product-ordering} + +جب تک کہ پروڈکٹس کو خاص طور پر کسی اور طرح سے، جیسے حروف تہجی کے مطابق، ترتیب نہ دیا گیا ہو، پروڈکٹس کو صفحے پر سب سے پرانے سے لے کر سب سے نئے تک کی ترتیب میں دکھایا جائے گا۔ دوسرے الفاظ میں، نئے پروڈکٹس کو فہرست کے آخر میں شامل کیا جاتا ہے۔ + +--- + +## اپنا ڈیولپر ٹول شامل کریں {#how-decisions-about-the-site-are-made} + +اگر آپ ethereum.org میں کوئی ڈیولپر ٹول شامل کرنا چاہتے ہیں اور یہ معیار پر پورا اترتا ہے، تو GitHub پر ایک ایشو بنائیں۔ + + + ایشو بنائیں + diff --git a/public/content/translations/ur/contributing/adding-exchanges/index.md b/public/content/translations/ur/contributing/adding-exchanges/index.md new file mode 100644 index 00000000000..a269ebc3a03 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-exchanges/index.md @@ -0,0 +1,40 @@ +--- +title: "ایکسچینجز کو شامل کرنا" +description: "ethereum.org میں ایکسچینجز کو شامل کرتے وقت ہم جو پالیسی استعمال کرتے ہیں" +lang: ur-in +--- + +# Ethereum ایکسچینجز کو شامل کرنا {#adding-ethereum-exchanges} + +کوئی بھی شخص ethereum.org پر نئے ایکسچینجز کی تجویز دینے کے لیے آزاد ہے۔ + +ہم فی الحال انہیں یہاں پر فہرست بند کرتے ہیں: + +- [ethereum.org/get-eth](/get-eth/) + +یہ صفحہ صارف کو یہ درج کرنے کی اجازت دیتا ہے کہ وہ کہاں رہتے ہیں اور یہ دیکھنے کی اجازت دیتا ہے کہ وہ کون سے ایکسچینجز استعمال کر سکتے ہیں۔ اس سے کسی بھی جغرافیائی پابندیوں کو جلد سامنے لانے میں مدد ملتی ہے۔ + +اس تناظر کی وجہ سے، جب آپ کسی ایکسچینج کی تجویز دیتے ہیں تو ہمیں کچھ مخصوص معلومات کی ضرورت ہوتی ہے۔ + +**نوٹ:** اگر آپ کسی ڈی سنٹرلائزڈ ایکسچینج کو فہرست بند کرنا چاہتے ہیں، تو والیٹس اور dapps کو فہرست بند کرنے کے لیے ہماری [پالیسی](/contributing/adding-products/) پر ایک نظر ڈالیں۔ + +## ہمیں کیا چاہیے {#what-we-need} + +- ایکسچینج پر لاگو ہونے والی جغرافیائی پابندیاں۔ ایکسچینج سے وابستہ جغرافیائی پابندیوں کی تفصیل ایکسچینج کی ویب سائٹ کے ایک مخصوص صفحہ یا سیکشن پر ہونی چاہیے۔ +- وہ کرنسیاں جن کا استعمال صارفین ETH خریدنے کے لیے کر سکتے ہیں۔ +- اس بات کا ثبوت کہ ایکسچینج ایک جائز تجارتی کمپنی ہے۔ +- آپ کے پاس کوئی بھی اضافی معلومات ہو – یہ کمپنی کے بارے میں معلومات ہو سکتی ہیں جیسے آپریشن کے سال، مالی معاونت وغیرہ۔ + +ہمیں اس معلومات کی ضرورت ہے تاکہ ہم درست طریقے سے [صارفین کو ایک ایسا ایکسچینج تلاش کرنے میں مدد کر سکیں جسے وہ استعمال کر سکتے ہیں](/get-eth/#country-picker)۔ + +اور تاکہ ethereum.org زیادہ پراعتماد ہو سکے کہ ایکسچینج ایک جائز اور محفوظ سروس ہے۔ + +--- + +## اپنا ایکسچینج شامل کریں {#add-exchange} + +اگر آپ ethereum.org میں کوئی ایکسچینج شامل کرنا چاہتے ہیں، تو GitHub پر ایک ایشو بنائیں۔ + + + ایک ایشو بنائیں + diff --git a/public/content/translations/ur/contributing/adding-glossary-terms/index.md b/public/content/translations/ur/contributing/adding-glossary-terms/index.md new file mode 100644 index 00000000000..3c649536a42 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-glossary-terms/index.md @@ -0,0 +1,26 @@ +--- +title: "لغت کی اصطلاحات شامل کرنا" +lang: ur-in +description: "ethereum.org کی لغت میں نئی اصطلاحات شامل کرنے کے لیے ہمارے معیارات" +--- + +# لغت کی اصطلاحات شامل کرنا {#contributing-to-ethereumorg-} + +یہ شعبہ ہر روز بدل رہا ہے۔ نئی اصطلاحات Ethereum کے صارفین کی لغت میں مسلسل داخل ہو رہی ہیں، اور ہمیں Ethereum سے متعلق تمام چیزوں کے لیے ایک درست، تازہ ترین حوالہ فراہم کرنے میں آپ کی مدد کی ضرورت ہے۔ موجودہ [لغت](/glossary/) کو دیکھیں اور اگر آپ مدد کرنا چاہتے ہیں تو نیچے دیکھیں۔ + +## معیارات {#criteria} + +نئی لغوی اصطلاحات کا جائزہ مندرجہ ذیل معیارات کی بنیاد پر کیا جائے گا: + +- کیا اصطلاح/تعریف تازہ ترین اور فی الحال متعلقہ ہے؟ +- کیا لغت میں پہلے سے کوئی ملتی جلتی اصطلاح موجود ہے؟ (اگر ایسا ہے تو، موجودہ اصطلاح کو اپ ڈیٹ کرنے کے بجائے ایک نئی اصطلاح کے فوائد پر غور کریں) +- کیا اصطلاح/تعریف پروڈکٹ کی تشہیر یا دیگر پروموشنل مواد سے خالی ہے؟ +- کیا یہ اصطلاح/تعریف براہ راست Ethereum سے متعلق ہے؟ +- کیا تعریف معروضی، درست اور موضوعی فیصلے یا رائے سے خالی ہے؟ +- کیا ماخذ قابل اعتبار ہے؟ کیا وہ اپنے ماخذ کا حوالہ دیتے ہیں؟ + +--- + +## اپنی اصطلاح شامل کریں {#how-decisions-about-the-site-are-made} + +اگر آپ ethereum.org میں لغت کی اصطلاح شامل کرنا چاہتے ہیں اور یہ معیارات پر پورا اترتی ہے، تو [GitHub پر ایک ایشو بنائیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml)۔ diff --git a/public/content/translations/ur/contributing/adding-layer-2s/index.md b/public/content/translations/ur/contributing/adding-layer-2s/index.md new file mode 100644 index 00000000000..57edb7a79e6 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-layer-2s/index.md @@ -0,0 +1,97 @@ +--- +title: "پرت 2s شامل کرنا" +description: "ایتھیریم ڈاٹ آرگ میں لیئر 2 کو شامل کرنے کے لئے ہم جو پالیسی استعمال کرتے ہیں" +lang: ur-in +--- + +# لیئر 2 کو شامل کرنا {#adding-layer-2} + +ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہم بہترین ممکنہ وسائل کی فہرست بنائیں تاکہ صارفین لیئر 2 اسپیس کو محفوظ اور پراعتماد طریقے سے نیویگیٹ کر سکیں۔ + +ایتھیریم ڈاٹ آرگ پر کوئی بھی لیئر 2 شامل کرنے کی تجویز دینے کے لیے آزاد ہے۔ اگر کوئی لیئر 2 ہے جسے ہم نے چھوڑ دیا ہے، **[براہ کرم اس کی تجویز دیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!** + +ہم فی الحال مندرجہ ذیل صفحات پر L2s کی فہرست دیتے ہیں: + +- [آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups/) +- [زیرو نالج رول اپس](/developers/docs/scaling/zk-rollups/) +- [لیئر 2](/layer-2/) + +لیئر 2 ایتھیریم کے لیے ایک نسبتاً نیا اور دلچسپ پیراڈائم ہے۔ ہم نے ethereum.org پر غور کرنے کے لیے ایک منصفانہ فریم ورک بنانے کی کوشش کی ہے لیکن فہرست سازی کے معیارات وقت کے ساتھ بدلیں گے اور تیار ہوں گے۔ + +## فیصلہ سازی کا فریم ورک {#decision-framework} + +### شمولیت کے لیے معیار: لازمی چیزیں {#criteria-for-inclusion-the-must-haves} + +**L2BEAT پر فہرست سازی** + +- غور کیے جانے کے لیے، اس پروجیکٹ کو [L2BEAT](https://l2beat.com) پر درج ہونا چاہیے۔ L2BEAT لیئر 2 پروجیکٹس کا ایک مضبوط رسک اسیسمنٹ فراہم کرتا ہے جس پر ہم L2 پروجیکٹس کا جائزہ لینے کے لیے انحصار کرتے ہیں۔ **اگر پروجیکٹ L2BEAT پر نمایاں نہیں ہے، تو ہم اسے ethereum.org پر L2 کے طور پر درج نہیں کریں گے۔** +- [L2BEAT میں اپنا L2 پروجیکٹ شامل کرنے کا طریقہ جانیں](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md)۔ + +**اوپن سورس** + +- آپ کا کوڈ قابل رسائی ہونا چاہیے اور آپ کو وسیع تر کمیونٹی سے PRs قبول کرنا چاہیے۔ + +**لیئر 2 زمرہ** + +ہم فی الحال مندرجہ ذیل کو لیئر 2 حل سمجھتے ہیں: + +- آپٹیمسٹک رول اپ +- زیرو نالج رول اپ + +_ہم دیگر اسکیلنگ کے حل کو لیئر 2 نہیں سمجھتے جو ڈیٹا کی دستیابی یا سیکیورٹی کے لیے ایتھیریم کا استعمال نہیں کرتے ہیں۔_ + +**ڈیٹا کی دستیابی کے لیے ایتھیریم** + +- ڈیٹا کی دستیابی دیگر اسکیلنگ کے حل اور لیئر 2 کے درمیان ایک اہم امتیازی عنصر ہے۔ فہرست میں شامل کیے جانے کے لیے ایک پروجیکٹ کو ڈیٹا کی دستیابی کے لیے **لازمی** طور پر ایتھیریم مین نیٹ کا استعمال کرنا چاہیے۔ + +**برجز** + +- صارفین لیئر 2 پر کیسے آن بورڈ ہو سکتے ہیں؟ + +**پروجیکٹ کے لائیو ہونے کی تاریخ** + +- ایک لیئر 2 جو 6 ماہ سے زیادہ عرصے سے مین نیٹ پر "لائیو" ہے۔ + +- نئے پروجیکٹس جن کا صارفین نے بیٹل ٹیسٹ نہیں کیا ہے ان کے درج ہونے کا امکان کم ہوتا ہے۔ + +**بیرونی سیکیورٹی آڈٹ** + +- چاہے آڈٹ، اندرونی سیکیورٹی ٹیم یا کسی اور طریقے سے ہو، آپ کے پروڈکٹ کی سیکیورٹی کو قابل اعتماد طریقے سے ٹیسٹ کیا جانا چاہیے۔ اس سے ہمارے صارفین کے لیے خطرہ کم ہوتا ہے اور ہمیں یہ ظاہر ہوتا ہے کہ آپ سیکیورٹی کو سنجیدگی سے لیتے ہیں۔ + +**مسلسل صارف بیس** + +- ہم TVL ہسٹری، ٹرانزیکشن کے اعداد و شمار، اور کیا یہ معروف کمپنیوں یا پروجیکٹس کے ذریعے استعمال کیا جاتا ہے جیسے میٹرکس پر غور کریں گے۔ + +**فعال ڈیولپمنٹ ٹیم** + +- ہم ایسے لیئر 2 کو درج نہیں کریں گے جس کے پروجیکٹ پر کام کرنے والی کوئی فعال ٹیم نہ ہو۔ + +**بلاک ایکسپلورر** + +- درج شدہ پروجیکٹس کو ایک کام کرنے والے بلاک ایکسپلورر کی ضرورت ہوتی ہے تاکہ صارفین آسانی سے چین کو نیویگیٹ کر سکیں۔ + +### دیگر معیارات: جو چیزیں ہوں تو اچھا ہے {#nice-to-haves} + +**پروجیکٹ کے لیے ایکسچینج سپورٹ** + +- کیا صارفین براہ راست ایکسچینج سے جمع اور/یا نکال سکتے ہیں؟ + +**لیئر 2 ایکو سسٹم میں dapps کے لنکس** + +- ہم اس بارے میں معلومات فراہم کرنے کے قابل ہونا چاہتے ہیں کہ صارفین اس لیئر 2 پر کیا کرنے کی توقع کر سکتے ہیں۔ (مثلاً، https://portal.arbitrum.io/, https://www.optimism.io/apps) + +**ٹوکن کانٹریکٹ کی فہرستیں** + +- چونکہ لیئر 2 پر اثاثوں کا ایک نیا پتہ ہوگا، اگر ٹوکن کی فہرست کا کوئی وسیلہ دستیاب ہے تو براہ کرم شیئر کریں۔ + +**نیٹیو والیٹ سپورٹ** + +- کیا کوئی والیٹ مقامی طور پر L2 کو سپورٹ کرتا ہے؟ + +## اپنا لیئر 2 شامل کریں {#add-exchange} + +اگر آپ ethereum.org میں لیئر 2 شامل کرنا چاہتے ہیں، تو GitHub پر ایک ایشو بنائیں۔ + + + ایک ایشو بنائیں + diff --git a/public/content/translations/ur/contributing/adding-products/index.md b/public/content/translations/ur/contributing/adding-products/index.md new file mode 100644 index 00000000000..18641c98cd2 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-products/index.md @@ -0,0 +1,100 @@ +--- +title: "مصنوعات شامل کرنا" +description: "وہ پالیسی جسے ہم ethereum.org پر dapps شامل کرتے وقت استعمال کرتے ہیں" +lang: ur-in +--- + +# Ethereum پروڈکٹس شامل کرنا {#adding-products} + +کوئی بھی شخص ethereum.org پر مواد میں نئے dapps کی تجویز دینے کے لیے آزاد ہے، جہاں ایسا کرنا مناسب ہو۔ **نہیں، ہم آپ کے dapp کو اپنے ہوم پیج پر فہرست میں شامل نہیں کریں گے** 😜 + +Dapps فی الحال اس پر درج ہیں: + +- ethereum.org/dapps +- ethereum.org/get-eth + +**براہ کرم صرف ان صفحات پر نئے اضافے کی تجویز دیں۔** + +اگرچہ ہم نئے اضافے کا خیر مقدم کرتے ہیں، لیکن ہم نے موجودہ dapps کا انتخاب اس تجربے کی بنیاد پر کیا ہے جسے ہم اپنے صارفین کے لیے بنانے کی کوشش کر رہے ہیں۔ یہ ہمارے کچھ ڈیزائن اصولوں پر مبنی ہیں: + +- _متاثر کن_: ethereum.org پر موجود کسی بھی چیز کو صارفین کو کچھ نیا پیش کرنا چاہیے۔ +- _ایک اچھی کہانی_: جو کچھ درج ہے اسے ایک "آہا" لمحہ فراہم کرنا چاہیے۔ +- _معتبر_: صارفین کے لیے خطرے کو کم سے کم کرنے کے لیے ہر چیز جائز کاروبار/پروجیکٹ ہونا چاہیے۔ + +مجموعی طور پر **ethereum.org نئے صارفین کے لیے ایک "ہموار آن بورڈنگ تجربہ" فراہم کرنا چاہتا ہے**۔ اسی وجہ سے، ہم dapps کو ان کی بنیاد پر شامل کرتے ہیں: + +- استعمال میں آسانی +- دیگر پروڈکٹس کے ساتھ باہمی عمل پذیری +- سیکورٹی +- طویل مدتی + +یہاں مزید تفصیل میں ہمارا فیصلہ سازی کا فریم ورک ہے۔ بلا جھجھک رائے دیں یا تبدیلیوں کی تجویز دیں۔ + +## فیصلہ سازی کا فریم ورک {#decision-framework} + +### شمولیت کے لیے معیار: لازمی چیزیں {#criteria-for-inclusion-the-must-haves} + +- **ایک سیکیورٹی-ٹیسٹ شدہ پروڈکٹ** – چاہے آڈٹ کے ذریعے، ایک اندرونی سیکیورٹی ٹیم یا کسی اور طریقے سے، آپ کے پروڈکٹ کی سیکیورٹی کو قابل اعتماد طریقے سے ٹیسٹ کیا جانا چاہیے۔ اس سے ہمارے صارفین کے لیے خطرہ کم ہوتا ہے اور ہمیں یہ ظاہر ہوتا ہے کہ آپ سیکیورٹی کو سنجیدگی سے لیتے ہیں۔ +- **ایک پروڈکٹ جو 6 ماہ سے زیادہ عرصے سے "لائیو" ہے** – یہ سیکیورٹی کا ایک اور اشارہ ہے۔ اہم بگس اور استحصال کے پائے جانے کے لیے 6 ماہ کا عرصہ ایک اچھا وقت ہے۔ +- **ایک فعال ٹیم کے ذریعے کام کیا گیا** – اس سے معیار کو یقینی بنانے میں مدد ملتی ہے اور یہ کہ صارف کو ان کے سوالات کے ساتھ مدد ملے گی۔ +- **ایماندار اور درست فہرست سازی کی معلومات** - یہ توقع کی جاتی ہے کہ پروجیکٹس سے کسی بھی تجویز کردہ فہرست میں ایماندار اور درست معلومات شامل ہوں۔ ایسے پروڈکٹس جو فہرست سازی کی معلومات کو غلط ثابت کرتے ہیں، جیسے یہ اعلان کرنا کہ آپ کا پروڈکٹ "اوپن سورس" ہے جبکہ ایسا نہیں ہے، انہیں ہٹا دیا جائے گا۔ + +### درجہ بندی کے لیے معیار: اچھی خصوصیات {#criteria-for-ranking-the-nice-to-haves} + +مندرجہ ذیل معیار کی وجہ سے آپ کا dapp، ethereum.org پر دوسروں کی طرح نمایاں طور پر درج نہیں کیا جا سکتا ہے۔ + +**Dapps** + +- **آپ اسے زیادہ تر درج شدہ والیٹس کے ذریعے رسائی حاصل کر سکتے ہیں** – dapps کو ethereum.org پر درج زیادہ تر والیٹس کے ساتھ کام کرنا چاہیے۔ +- **صارفین اسے خود آزما سکتے ہیں –** ایک انفرادی صارف کو آپ کے dapp کا استعمال کرنے اور کچھ ٹھوس حاصل کرنے کے قابل ہونا چاہیے۔ +- **آن بورڈنگ** – آپ کے پروڈکٹ میں صارفین کی مدد اور تعلیم کے لیے ایک اچھی طرح سے ڈیزائن کیا گیا آن بورڈنگ تجربہ ہونا چاہیے۔ یا مضامین یا ویڈیوز جیسے کیسے کریں مواد کا ثبوت۔ +- **غیر تحویلی** – صارفین اپنے فنڈز کو کنٹرول کرتے ہیں۔ اگر آپ کا پروڈکٹ غائب ہو جاتا ہے، تو صارفین پھر بھی اپنے فنڈز تک رسائی حاصل کر سکتے ہیں اور انہیں منتقل کر سکتے ہیں۔ +- **عالمی سطح پر قابل رسائی** – آپ کے پروڈکٹ میں جغرافیائی حدود یا KYC کی ضروریات نہیں ہیں جو بعض لوگوں کو آپ کی سروس تک رسائی سے خارج کرتی ہیں۔ +- **اوپن سورس** – آپ کا کوڈ قابل رسائی ہونا چاہیے اور آپ کو وسیع تر کمیونٹی سے PRs قبول کرنے چاہئیں۔ +- **کمیونٹی** – آپ کے پاس ایک وقف کمیونٹی ہونی چاہیے، شاید ایک Discord، جہاں صارفین مدد حاصل کرنے یا نئی خصوصیات تجویز کرنے کے لیے آپ کی ٹیم کے ساتھ بات چیت کر سکیں۔ + +## عملی طور پر معیار {#criteria-in-practice} + +آپ جتنے زیادہ معیار پورے کریں گے، اتنا ہی زیادہ امکان ہے کہ آپ کا پروڈکٹ ethereum.org پر اپنی جگہ بنا لے۔ + +ایک درج شدہ پروڈکٹ جو صرف لازمی شرائط کو پورا کرتا ہے اسے ہٹایا جا سکتا ہے اگر کوئی نیا پروڈکٹ تجویز کیا جاتا ہے جو لازمی شرائط اور کئی اچھی خصوصیات کو پورا کرتا ہو۔ + +دیگر چیزیں جو اس فیصلے میں شامل ہوں گی: + +- کیا تبدیل کرنے کے بجائے شامل کرنے سے صفحہ کا UX خراب ہو جائے گا؟ + - ہماری سائٹ بنیادی طور پر تعلیمی ہے اور اس کا بنیادی مقصد Ethereum اور اس کے متعلقہ تصورات کی وضاحت کرنا ہے۔ صارفین کے لیے بہت زیادہ اختیارات شامل کرنے سے، صفحات کم پڑھنے کے قابل اور اس طرح کم مفید ہو سکتے ہیں۔ +- کیا یہ صفحہ اب صارف کو انتخاب کے ساتھ مفلوج کر دیتا ہے؟ + - جیسے جب آپ گھنٹوں تک Netflix براؤز کرتے ہیں کیونکہ آپ یہ فیصلہ نہیں کر پاتے کہ کیا دیکھنا ہے۔ نئے صارفین کو بہت زیادہ انتخاب کے ساتھ الجھانا ایک خطرہ ہے۔ + +یہ ایک ڈیزائن کا فیصلہ ہے جس کے لیے ethereum.org ذمہ دار ہے۔ + +لیکن یقین رکھیں، **ایسی دوسری ویب سائٹس کے لنکس ہوں گے جو مزید dapps کی درجہ بندی کرتی ہیں** + +### پروڈکٹ کی ترتیب {#product-ordering} + +جب تک کہ پروڈکٹس کو خاص طور پر کسی اور ترتیب میں نہ رکھا جائے، جیسے کہ حروف تہجی کے مطابق، پروڈکٹس کو صفحہ پر سب سے حال میں شامل کیے گئے سے لے کر سب سے کم حال میں شامل کیے گئے تک دکھایا جائے گا۔ دوسرے الفاظ میں، نئے پروڈکٹس کو فہرست کے آخر میں شامل کیا جاتا ہے۔ + +### استعمال کی شرائط {#terms-of-use} + +براہ کرم ہماری [استعمال کی شرائط](/terms-of-use/) کو بھی دیکھیں۔ ethereum.org پر معلومات صرف عام معلومات کے مقاصد کے لیے فراہم کی جاتی ہے۔ + +## دیکھ بھال {#maintenance} + +جیسا کہ Ethereum کی فطرت متغیر ہے، ٹیمیں اور پروڈکٹس آتے جاتے رہتے ہیں اور روزانہ جدت ہوتی رہتی ہے، اس لیے ہم اپنے مواد کی معمول کی جانچ پڑتال کریں گے تاکہ: + +- یہ یقینی بنائیں کہ تمام درج شدہ dapps اب بھی ہمارے معیار پر پورا اترتے ہیں +- اس بات کی تصدیق کریں کہ ایسے کوئی پروڈکٹس تجویز نہیں کیے گئے ہیں جو فی الحال درج شدہ پروڈکٹس سے زیادہ ہمارے معیار پر پورا اترتے ہوں + +آپ جانچ کرکے اور ہمیں بتا کر اس میں مدد کر سکتے ہیں۔ [ایک مسئلہ بنائیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) یا [website@ethereum.org](mailto:website@ethereum.org) پر ایک ای میل بھیجیں + +_ہم ووٹنگ کے لیے اختیارات کی بھی چھان بین کر رہے ہیں تاکہ کمیونٹی اپنی ترجیحات کا اظہار کر سکے اور وہاں موجود بہترین پروڈکٹس کو نمایاں کر سکے جن کی ہم سفارش کر سکیں۔_ + +--- + +## اپنا پروڈکٹ شامل کریں {#add-your-product} + +اگر آپ ethereum.org میں کوئی dapp شامل کرنا چاہتے ہیں اور وہ معیار پر پورا اترتا ہے، تو براہ کرم ہمیں بتائیں۔ + + + ایک ایپ تجویز کریں + diff --git a/public/content/translations/ur/contributing/adding-resources/index.md b/public/content/translations/ur/contributing/adding-resources/index.md new file mode 100644 index 00000000000..ccb8e313388 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-resources/index.md @@ -0,0 +1,53 @@ +--- +title: "وسائل کا اضافہ" +description: "وہ پالیسی جسے ہم ethereum.org پر وسائل شامل کرتے وقت استعمال کرتے ہیں۔" +lang: ur-in +--- + +# وسائل کا اضافہ {#adding-resources} + +ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہم بہترین ممکنہ وسائل کی فہرست بنائیں اور ساتھ ہی صارفین کو محفوظ اور پراعتماد رکھیں۔ + +کوئی بھی شخص ethereum.org پر وسائل کے ڈیش بورڈ میں شامل کرنے کے لیے نئے وسائل تجویز کرنے کے لیے آزاد ہے، جو فی الحال [ethereum.org/resources](/resources/) پر موجود ہے۔ + +اگرچہ ہم نئے اضافوں کا خیرمقدم کرتے ہیں، لیکن موجودہ وسائل کا انتخاب اس تجربے کی بنیاد پر کیا گیا تھا جو ہم اپنے صارفین کے لیے بنانے کی کوشش کر رہے ہیں۔ یہ ہمارے کچھ ڈیزائن اصولوں پر مبنی ہیں: + +- _متاثر کن_: ethereum.org پر موجود کسی بھی چیز کو صارفین کو کچھ نیا پیش کرنا چاہیے۔ +- _ایک اچھی کہانی_: جو کچھ درج ہے اسے ایک "آہا" لمحہ فراہم کرنا چاہیے۔ +- _معتبر_: صارفین کے لیے خطرے کو کم سے کم کرنے کے لیے ہر چیز جائز کاروبار/پروجیکٹ ہونا چاہیے۔ + +مجموعی طور پر، **ethereum.org کا مقصد نئے صارفین کو ایک ہموار آن بورڈنگ تجربہ فراہم کرنا ہے**۔ اسی وجہ سے، ہم وسائل کو ان کی بنیاد پر شامل کرتے ہیں: + +- استعمال میں آسانی +- درستگی +- دیکھ بھال + +## فیصلہ سازی کا فریم ورک {#decision-framework} + +### معیارات {#criteria} + +- **ایماندار اور درست فہرست سازی کی معلومات** - کسی بھی تجویز کردہ فہرست میں ایماندار اور درست معلومات ہونی چاہئیں۔ معلومات کو غلط بیان کرنے والی مصنوعات کو ہٹا دیا جائے گا۔ +- **فعال پروجیکٹ** – وسیلے کی دیکھ بھال ایک فعال ٹیم کے ذریعے کی جانی چاہیے تاکہ صارفین کے لیے معیار اور سپورٹ کو یقینی بنایا جا سکے۔ پرانے وسائل کو ہٹایا جا سکتا ہے۔ + +### پروڈکٹ کی ترتیب {#product-ordering} + +ہم پروڈکٹس کو ان کے اثرات کی بنیاد پر ترتیب دینے کا حق محفوظ رکھتے ہیں۔ نئے پروڈکٹس کو عام طور پر فہرست کے نیچے شامل کیا جائے گا جب تک کہ دوسری صورت میں وضاحت نہ کی جائے۔ + +## دیکھ بھال {#maintenance} + +جیسے جیسے ایتھیریم ایکو سسٹم تیار ہوتا ہے، ہم اپنے مواد کو معمول کے مطابق چیک کریں گے تاکہ: + +- یقینی بنائیں کہ فہرست میں شامل تمام وسائل اب بھی ہمارے معیار پر پورا اترتے ہیں۔ +- تصدیق کریں کہ ایسے کوئی پروڈکٹس نہیں ہیں جن کی تجویز دی گئی ہو جو ہمارے معیار پر موجودہ فہرست میں شامل پروڈکٹس سے زیادہ پورا اترتے ہوں۔ + +آپ جانچ کرکے اور ہمیں بتا کر اس میں مدد کر سکتے ہیں۔ [ایک ایشو بنائیں](https://github.com/ethereum/ethereum-org-website/issues/new?template=bug_report.yaml) یا [website@ethereum.org](mailto:website@ethereum.org) پر ایک ای میل بھیجیں۔ + +--- + +## اپنا وسیلہ شامل کریں {#add-your-resource} + +اگر آپ ethereum.org میں کوئی وسیلہ شامل کرنا چاہتے ہیں اور یہ معیار پر پورا اترتا ہے، تو GitHub پر ایک ایشو بنائیں۔ + + + ایک ایشو بنائیں + diff --git a/public/content/translations/ur/contributing/adding-staking-products/index.md b/public/content/translations/ur/contributing/adding-staking-products/index.md new file mode 100644 index 00000000000..0709ec16887 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-staking-products/index.md @@ -0,0 +1,176 @@ +--- +title: "اسٹیکنگ پروڈکٹس یا خدمات شامل کرنا" +description: "وہ پالیسی جو ہم ethereum.org میں اسٹیکنگ پروڈکٹس یا خدمات شامل کرتے وقت استعمال کرتے ہیں" +lang: ur-in +--- + +# اسٹیکنگ پروڈکٹس یا خدمات شامل کرنا {#adding-staking-products-or-services} + +ہم اس بات کو یقینی بنانا چاہتے ہیں کہ ہم بہترین ممکنہ وسائل کی فہرست بنائیں اور ساتھ ہی صارفین کو محفوظ اور پراعتماد رکھیں۔ + +کوئی بھی ethereum.org پر اسٹیکنگ پروڈکٹ یا سروس شامل کرنے کی تجویز دینے کے لیے آزاد ہے۔ اگر کوئی ایسی چیز ہے جو ہم سے چھوٹ گئی ہے، **[براہ کرم اس کی تجویز دیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!** + +ہم فی الحال درج ذیل صفحات پر اسٹیکنگ پروڈکٹس اور خدمات کی فہرست دیتے ہیں: + +- [سولو اسٹیکنگ](/staking/solo/) +- [سروس کے طور پر اسٹیکنگ](/staking/saas/) +- [اسٹیکنگ پولز](/staking/pools/) + +بیکن چین پر پروف-آف-اسٹیک 1 دسمبر 2020 سے لائیو ہے۔ اگرچہ اسٹیکنگ اب بھی نسبتاً نئی ہے، ہم نے ethereum.org پر غور کے لیے ایک منصفانہ اور شفاف فریم ورک بنانے کی کوشش کی ہے لیکن فہرست سازی کے معیار وقت کے ساتھ بدلتے اور تیار ہوتے رہیں گے، اور یہ بالآخر ethereum.org ویب سائٹ ٹیم کی صوابدید پر ہے۔ + +## فیصلے کا فریم ورک {#the-decision-framework} + +ethereum.org پر کسی پروڈکٹ کو فہرست میں شامل کرنے کا فیصلہ کسی ایک عنصر پر منحصر نہیں ہے۔ کسی پروڈکٹ یا سروس کو فہرست میں شامل کرنے کا فیصلہ کرتے وقت متعدد معیارات پر ایک ساتھ غور کیا جاتا ہے۔ ان میں سے جتنے زیادہ معیارات پورے ہوں گے، اس کے فہرست میں شامل ہونے کا امکان اتنا ہی زیادہ ہوگا۔ + +**سب سے پہلے، یہ کس زمرے کا پروڈکٹ یا سروس ہے؟** + +- نوڈ یا کلائنٹ ٹولنگ +- کلیدی انتظام +- اسٹیکنگ ایز اے سروس (SaaS) +- اسٹیکنگ پول + +فی الحال، ہم صرف ان زمروں میں پروڈکٹس یا خدمات کی فہرست دے رہے ہیں۔ + +### شمولیت کے لیے معیار {#criteria-for-inclusion} + +اسٹیکنگ پروڈکٹس یا خدمات کی جمع کرائی گئی درخواستوں کا جائزہ درج ذیل معیارات کے مطابق لیا جائے گا: + +**یہ پروجیکٹ یا سروس کب شروع کی گئی تھی؟** + +- کیا اس بات کا کوئی ثبوت ہے کہ یہ پروڈکٹ یا سروس عوام کے لیے کب دستیاب ہوئی؟ +- یہ پروڈکٹس کے "battle tested" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**کیا پروجیکٹ کو فعال طور پر برقرار رکھا جا رہا ہے؟** + +- کیا پروجیکٹ کو تیار کرنے والی کوئی فعال ٹیم ہے؟ کون شامل ہے؟ +- صرف فعال طور پر برقرار رکھے گئے پروڈکٹس پر غور کیا جائے گا۔ + +**کیا پروڈکٹ یا سروس بھروسہ مند/انسانی ثالثوں سے پاک ہے؟** + +- صارف کے سفر میں کن مراحل کے لیے انسانوں پر بھروسہ کرنے کی ضرورت ہوتی ہے تاکہ وہ یا تو ان کے فنڈز کی کلیدیں اپنے پاس رکھیں، یا انعامات کو صحیح طریقے سے تقسیم کریں؟ +- یہ پروڈکٹ یا خدمات کے "trustless" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**کیا پروجیکٹ درست اور قابل اعتماد معلومات فراہم کرتا ہے؟** + +- یہ بہت ضروری ہے کہ پروڈکٹ کی ویب سائٹ پر تازہ ترین، درست، اور غیر گمراہ کن معلومات موجود ہوں، خاص طور پر اگر یہ Ethereum پروٹوکول یا دیگر متعلقہ ٹیکنالوجیز سے متعلق ہے۔ +- Ethereum یا دیگر متعلقہ موضوعات کے بارے میں غلط معلومات، پرانی تفصیلات، یا ممکنہ طور پر گمراہ کن بیانات پر مشتمل جمع کرائی گئی درخواستوں کو فہرست میں شامل نہیں کیا جائے گا یا اگر پہلے سے فہرست میں شامل ہیں تو انہیں ہٹا دیا جائے گا۔ + +**کون سے پلیٹ فارم سپورٹ کیے جاتے ہیں؟** + +- یعنی، Linux, macOS, Windows, iOS, Android + +#### سافٹ ویئر اور اسمارٹ کنٹریکٹس {#software-and-smart-contracts} + +کسی بھی کسٹم سافٹ ویئر یا اسمارٹ کنٹریکٹس کے لیے جو شامل ہیں: + +**کیا سب کچھ اوپن سورس ہے؟** + +- اوپن سورس پروجیکٹس کا عوامی طور پر دستیاب سورس کوڈ ریپوزٹری ہونا چاہیے۔ +- یہ پروڈکٹس کے "open source" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**کیا پروڈکٹ _beta_ ڈیولپمنٹ سے باہر ہے؟** + +- پروڈکٹ اپنے ڈیولپمنٹ سائیکل میں کہاں ہے؟ +- بیٹا مرحلے میں موجود پروڈکٹس کو ethereum.org پر شمولیت کے لیے غور نہیں کیا جاتا۔ + +**کیا سافٹ ویئر کا بیرونی سیکیورٹی آڈٹ ہوا ہے؟** + +- اگر نہیں، تو کیا بیرونی آڈٹ کرانے کا کوئی منصوبہ ہے؟ +- یہ پروڈکٹس کے "audited" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**کیا پروجیکٹ کا بگ باؤنٹی پروگرام ہے؟** + +- اگر نہیں، تو کیا سیکیورٹی بگ باؤنٹی بنانے کا کوئی منصوبہ ہے؟ +- یہ پروڈکٹس کے "bug bounty" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +#### نوڈ یا کلائنٹ ٹولنگ {#node-or-client-tooling} + +نوڈ یا کلائنٹ سیٹ اپ، انتظام یا منتقلی سے متعلق سافٹ ویئر پروڈکٹس کے لیے: + +**کون سے کنسینسس لیئر کلائنٹس (یعنی، Lighthouse, Teku, Nimbus, Prysm, Grandine) سپورٹ کیے جاتے ہیں؟** + +- کون سے کلائنٹس سپورٹ کیے جاتے ہیں؟ کیا صارف انتخاب کر سکتا ہے؟ +- یہ پروڈکٹس کے "multi-client" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +#### سروس کے طور پر اسٹیکنگ {#staking-as-a-service} + +[سروس کے طور پر اسٹیکنگ فہرستوں](/staking/saas/) کے لیے (یعنی، ڈیلیگیٹڈ نوڈ آپریشن): + +**سروس استعمال کرنے سے وابستہ فیس کیا ہیں؟** + +- فیس کا ڈھانچہ کیا ہے، مثلاً، کیا سروس کے لیے کوئی ماہانہ فیس ہے؟ +- کوئی اضافی اسٹیکنگ کی ضروریات؟ + +**کیا صارفین کو اکاؤنٹ کے لیے سائن اپ کرنے کی ضرورت ہے؟** + +- کیا کوئی اجازت یا KYC کے بغیر سروس استعمال کر سکتا ہے؟ +- یہ پروڈکٹس کے "permissionless" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**سائننگ کیز، اور ودڈرال کیز کون رکھتا ہے؟** + +- صارف کن کیز تک رسائی برقرار رکھتا ہے؟ سروس کن کیز تک رسائی حاصل کرتی ہے؟ +- یہ پروڈکٹس کے "trustless" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**آپریٹ کیے جانے والے نوڈز کا کلائنٹ تنوع کیا ہے؟** + +- ویلیڈیٹر کیز کا کتنا فیصد اکثریتی کنسینسس لیئر (CL) کلائنٹ کے ذریعے چلایا جا رہا ہے؟ +- آخری ترمیم کے مطابق، Prysm کنسینسس لیئر کلائنٹ ہے جسے نوڈ آپریٹرز کی اکثریت چلا رہی ہے، جو نیٹ ورک کے لیے خطرناک ہے۔ اگر کوئی CL کلائنٹ فی الحال نیٹ ورک کے 33% سے زیادہ استعمال کر رہا ہے، تو ہم اس کے استعمال سے متعلق ڈیٹا کی درخواست کرتے ہیں۔ +- یہ پروڈکٹس کے "diverse clients" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +#### اسٹیکنگ پول {#staking-pool} + +[پولڈ اسٹیکنگ خدمات](/staking/pools/) کے لیے: + +**اسٹیک کرنے کے لیے کم از کم کتنے ETH کی ضرورت ہے؟** + +- مثلاً، 0.01 ETH + +**اس میں شامل فیس یا اسٹیکنگ کی ضروریات کیا ہیں؟** + +- انعامات کا کتنا فیصد فیس کے طور پر ہٹا دیا جاتا ہے؟ +- کوئی اضافی اسٹیکنگ کی ضروریات؟ + +**کیا کوئی لیکویڈیٹی ٹوکن ہے؟** + +- اس میں کون سے ٹوکن شامل ہیں؟ وہ کیسے کام کرتے ہیں؟ کنٹریکٹ ایڈریس کیا ہیں؟ +- یہ پروڈکٹس کے "liquidity token" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**کیا صارفین نوڈ آپریٹر کے طور پر حصہ لے سکتے ہیں؟** + +- پولڈ فنڈز کا استعمال کرتے ہوئے ویلیڈیٹر کلائنٹس کو چلانے کے لیے کیا ضرورت ہے؟ +- کیا اس کے لیے کسی فرد، کمپنی یا DAO سے اجازت درکار ہے؟ +- یہ پروڈکٹس کے "permissionless nodes" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +**پول نوڈ آپریٹرز کا کلائنٹ تنوع کیا ہے؟** + +- نوڈ آپریٹرز کا کتنا فیصد اکثریتی کنسینسس لیئر (CL) کلائنٹ چلا رہا ہے؟ +- آخری ترمیم کے مطابق، Prysm کنسینسس لیئر کلائنٹ ہے جسے نوڈ آپریٹرز کی اکثریت چلا رہی ہے، جو نیٹ ورک کے لیے خطرناک ہے۔ اگر کوئی CL کلائنٹ فی الحال نیٹ ورک کے 33% سے زیادہ استعمال کر رہا ہے، تو ہم اس کے استعمال سے متعلق ڈیٹا کی درخواست کرتے ہیں۔ +- یہ پروڈکٹس کے "diverse clients" اسکور کا تعین کرنے کے لیے استعمال ہوتا ہے۔ + +### دیگر معیار: اچھی چیزیں {#other-criteria} + +**کون سے یوزر انٹرفیس سپورٹ کیے جاتے ہیں؟** + +- یعنی، براؤزر ایپ، ڈیسک ٹاپ ایپ، موبائل ایپ، CLI + +**نوڈ ٹولنگ کے لیے، کیا سافٹ ویئر کلائنٹس کے درمیان سوئچ کرنے کا آسان طریقہ فراہم کرتا ہے؟** + +- کیا صارف ٹول کا استعمال کرتے ہوئے آسانی سے اور محفوظ طریقے سے کلائنٹس کو تبدیل کر سکتا ہے؟ + +**SaaS کے لیے، سروس کے ذریعے فی الحال کتنے ویلیڈیٹرز آپریٹ کیے جا رہے ہیں؟** + +- اس سے ہمیں اب تک آپ کی سروس کی پہنچ کا اندازہ ہوتا ہے۔ + +## ہم نتائج کیسے دکھاتے ہیں {#product-ordering} + +اوپر دیے گئے [شمولیت کے معیار](#criteria-for-inclusion) کا استعمال ہر پروڈکٹ یا سروس کے لیے مجموعی اسکور کا حساب لگانے کے لیے کیا جاتا ہے۔ یہ ان پروڈکٹس کو ترتیب دینے اور دکھانے کے ایک ذریعہ کے طور پر استعمال ہوتا ہے جو کچھ معروضی معیارات پر پورا اترتے ہیں۔ جتنے زیادہ معیارات کے لیے ثبوت فراہم کیا جائے گا، پروڈکٹ کو اتنا ہی اونچا ترتیب دیا جائے گا، اور ٹائی ہونے کی صورت میں لوڈ پر بے ترتیب کیا جائے گا۔ + +ان معیارات کے لیے کوڈ کی منطق اور وزن فی الحال ہمارے ریپو میں [اس JavaScript جزو](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) میں موجود ہیں۔ + +## اپنا پروڈکٹ یا سروس شامل کریں {#add-product} + +اگر آپ ethereum.org میں کوئی اسٹیکنگ پروڈکٹ یا سروس شامل کرنا چاہتے ہیں تو GitHub پر ایک مسئلہ بنائیں۔ + + + ایک ایشو بنائیں + diff --git a/public/content/translations/ur/contributing/adding-wallets/index.md b/public/content/translations/ur/contributing/adding-wallets/index.md new file mode 100644 index 00000000000..7af39c51a84 --- /dev/null +++ b/public/content/translations/ur/contributing/adding-wallets/index.md @@ -0,0 +1,80 @@ +--- +title: "والٹس شامل کرنا" +description: "ethereum.org پر والٹ شامل کرنے کے لیے جو پالیسی ہم استعمال کرتے ہیں" +lang: ur-in +--- + +# والٹس شامل کرنا {#adding-wallets} + +ہم یہ یقینی بنانا چاہتے ہیں کہ ہم والٹس کے فیچر سے بھرپور لینڈ اسکیپ کا احاطہ کرنے والے مختلف قسم کے والٹس دکھائیں تاکہ صارفین اعتماد کے ساتھ Ethereum کو نیویگیٹ کر سکیں۔ + +کوئی بھی ethereum.org پر والٹ شامل کرنے کی تجویز دینے کے لیے آزاد ہے۔ اگر کوئی ایسا والٹ ہے جو ہم سے چھوٹ گیا ہے، تو براہ کرم اس کی تجویز دیں! + +والٹس فی الحال اس پر درج ہیں: + +- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/) + +Ethereum میں والٹس تیزی سے بدل رہے ہیں۔ ہم نے ethereum.org پر غور کرنے کے لیے ایک منصفانہ فریم ورک بنانے کی کوشش کی ہے لیکن فہرست سازی کے معیارات وقت کے ساتھ بدلیں گے اور تیار ہوں گے۔ + +## فیصلے کا فریم ورک {#the-decision-framework} + +### شامل کرنے کے معیارات: لازمی چیزیں {#the-must-haves} + +- **سیکیورٹی کے لحاظ سے جانچا گیا پروڈکٹ** - چاہے آڈٹ کے ذریعے، اندرونی سیکیورٹی ٹیم، اوپن سورس کوڈ، یا کسی اور طریقے سے، آپ کے والٹ کی سیکیورٹی قابل اعتماد ہونی چاہیے۔ اس سے ہمارے صارفین کے لیے خطرہ کم ہوتا ہے اور ہمیں یہ ظاہر ہوتا ہے کہ آپ سیکیورٹی کو سنجیدگی سے لیتے ہیں۔ +- **ایک ایسا والٹ جو چھ ماہ سے زیادہ عرصے سے "لائیو" ہے یا کسی معروف ٹریک ریکارڈ والے گروپ کے ذریعہ جاری کیا گیا ہے** - یہ سیکیورٹی کا ایک اور اشارہ ہے۔ چھ ماہ کا عرصہ اہم بگس اور استحصال کو تلاش کرنے کے لیے ایک اچھا وقت ہے۔ ہم ان فورکس کو فلٹر کرنے میں مدد کے لیے چھ ماہ کا وقت مانگتے ہیں جنہیں پروجیکٹس کے طور پر جلد ہی ترک کر دیا جاتا ہے۔ +- **ایک فعال ٹیم کے ذریعہ کام کیا گیا** - اس سے معیار کو یقینی بنانے میں مدد ملتی ہے اور یہ کہ صارف کو اس کے سوالات کے لیے مدد ملے گی۔ +- **ایماندار اور درست فہرست سازی کی معلومات** - یہ توقع کی جاتی ہے کہ پروجیکٹس سے کسی بھی تجویز کردہ فہرست میں ایماندار اور درست معلومات شامل ہوں۔ وہ پروڈکٹس جو فہرست سازی کی معلومات کو غلط ثابت کرتے ہیں، جیسے کہ یہ اعلان کرنا کہ آپ کا پروڈکٹ "اوپن سورس" ہے جب کہ وہ نہیں ہے، ہٹا دیا جائے گا۔ +- **رابطے کا مقام** - والٹ کے لیے رابطے کا ایک مقام تبدیلیاں کیے جانے پر ہمیں درست معلومات حاصل کرنے میں بہت مدد کرے گا۔ اس سے مستقبل کی معلومات اکٹھا کرتے وقت ethereum.org کو اپ ڈیٹ کرنا قابل انتظام رہے گا۔ +- **EIP-1559 (قسم 2) ٹرانزیکشنز** - آپ کے والٹ کو مین نیٹ Ethereum پر ٹرانزیکشنز کے لیے EIP-1559 (قسم 2) ٹرانزیکشنز کو سپورٹ کرنا چاہیے۔ +- **اچھا صارف تجربہ** - اگرچہ UX موضوعی ہے، اگر کئی بنیادی ٹیم کے اراکین پروڈکٹ کی جانچ کرتے ہیں اور اسے استعمال کرنا مشکل پاتے ہیں، تو ہم والٹ کو مسترد کرنے کا حق محفوظ رکھتے ہیں اور اس کے بجائے بہتری کے لیے مفید تجاویز فراہم کریں گے۔ یہ ہمارے صارف کی بنیاد کی حفاظت کے لیے کیا جاتا ہے جو زیادہ تر ابتدائی افراد پر مشتمل ہے۔ +- **Ethereum پر مرکوز** - ایک والٹ کو بنیادی طور پر Ethereum پر مرکوز تجربہ فراہم کرنا چاہیے۔ اس کا مطلب ہے کہ Ethereum (یا کوئی L2) ڈیفالٹ نیٹ ورک کے طور پر سیٹ ہے، ERC اثاثوں کو مناسب طریقے سے سپورٹ کیا جاتا ہے، اور خصوصیات Ethereum ایکو سسٹم کے ساتھ منسلک ہیں۔ وہ والٹس جو UI میں متبادل لیئر 1s کو ترجیح دیتے ہیں ان کی فہرست نہیں دی جائے گی۔ + +### پروڈکٹ ہٹانا {#product-removals} + +- **اپ ڈیٹ کردہ معلومات** - والٹ فراہم کنندگان ہر 6 ماہ بعد اپنے والٹ کی معلومات دوبارہ جمع کرانے کے ذمہ دار ہیں تاکہ فراہم کردہ معلومات کی درستگی اور مطابقت کو یقینی بنایا جا سکے (چاہے ان کے پروڈکٹ میں کوئی تبدیلی نہ ہو)۔ اگر پروڈکٹ ٹیم ایسا کرنے میں ناکام رہتی ہے، تو ethereum.org پروجیکٹ کو صفحہ سے ہٹا سکتا ہے۔ + +### دیگر معیارات: اچھی اضافی خصوصیات {#the-nice-to-haves} + +- **عالمی سطح پر قابل رسائی** - آپ کے والٹ میں جغرافیائی حدود یا KYC کی ضروریات نہیں ہیں جو کچھ لوگوں کو آپ کی سروس تک رسائی سے خارج کرتی ہیں۔ +- **متعدد زبانوں میں دستیاب** - آپ کا والٹ متعدد زبانوں میں ترجمہ کیا گیا ہے جس سے دنیا بھر کے صارفین اس تک رسائی حاصل کر سکتے ہیں۔ +- **اوپن سورس** - آپ کے پورے پروجیکٹ کا کوڈ بیس (صرف ماڈیولز نہیں) قابل رسائی ہونا چاہئے اور آپ کو وسیع تر کمیونٹی سے PRs قبول کرنا چاہئے۔ +- **غیر تحویلی** - صارفین اپنے فنڈز کو کنٹرول کرتے ہیں۔ اگر آپ کا پروڈکٹ غائب ہو جاتا ہے، تو صارفین پھر بھی اپنے فنڈز تک رسائی حاصل کر سکتے ہیں اور انہیں منتقل کر سکتے ہیں۔ +- **ہارڈویئر والٹ سپورٹ** - صارفین ٹرانزیکشنز پر دستخط کرنے کے لیے اپنے ہارڈویئر والٹ کو جوڑ سکتے ہیں۔ +- **WalletConnect** - صارفین WalletConnect کا استعمال کرتے ہوئے dapps سے منسلک ہو سکتے ہیں۔ +- **Ethereum RPC اینڈ پوائنٹس درآمد کرنا** - صارفین نوڈ RPC ڈیٹا درآمد کر سکتے ہیں، جس سے وہ اپنی پسند کے نوڈ، یا دیگر EVM ہم آہنگ نیٹ ورکس سے جڑ سکتے ہیں۔ +- **NFTs** - صارفین والٹ میں اپنے NFTs کو دیکھنے اور ان کے ساتھ تعامل کرنے کے قابل ہیں۔ +- **Ethereum ایپلیکیشنز سے جڑیں** - صارفین Ethereum ایپلیکیشنز سے جڑنے اور استعمال کرنے کے قابل ہیں۔ +- **اسٹیکنگ** - صارفین براہ راست والٹ کے ذریعے اسٹیک کرنے کے قابل ہیں۔ +- **سواپس** - صارفین والٹ کے ذریعے ٹوکن سواپ کرنے کے قابل ہیں۔ +- **ملٹی چین نیٹ ورکس** - آپ کا والٹ صارفین کو بطور ڈیفالٹ متعدد بلاک چین نیٹ ورکس تک رسائی کی حمایت کرتا ہے۔ +- **لیئر 2 نیٹ ورکس** - آپ کا والٹ صارفین کو بطور ڈیفالٹ لیئر 2 نیٹ ورکس تک رسائی کی حمایت کرتا ہے۔ +- **گیس فیس کو حسب ضرورت بنائیں** - آپ کا والٹ صارفین کو اپنی ٹرانزیکشن گیس فیس (بیس فیس، ترجیحی فیس، زیادہ سے زیادہ فیس) کو حسب ضرورت بنانے کی اجازت دیتا ہے۔ +- **ENS سپورٹ** - آپ کا والٹ صارفین کو ENS ناموں پر ٹرانزیکشن بھیجنے کی اجازت دیتا ہے۔ +- **ERC-20 سپورٹ** - آپ کا والٹ صارفین کو ERC-20 ٹوکن کنٹریکٹ درآمد کرنے، یا خود بخود ERC-20 ٹوکنز کو استفسار کرنے اور ڈسپلے کرنے کی اجازت دیتا ہے۔ +- **کرپٹو خریدیں** - آپ کا والٹ صارفین کو براہ راست کرپٹو خریدنے اور آن بورڈنگ کی حمایت کرتا ہے۔ +- **فیاٹ کے لیے فروخت کریں** - آپ کا والٹ صارفین کو براہ راست کارڈ یا بینک اکاؤنٹ میں فیاٹ فروخت کرنے اور نکالنے کی حمایت کرتا ہے۔ +- **ملٹی سگ** - آپ کا والٹ ٹرانزیکشن پر دستخط کرنے کے لیے متعدد دستخطوں کی حمایت کرتا ہے۔ +- **سماجی بازیابی** - آپ کا والٹ گارڈینز کو سپورٹ کرتا ہے اور اگر کوئی صارف ان گارڈینز کا استعمال کرتے ہوئے اپنا سیڈ فریز کھو دیتا ہے تو وہ اپنے والٹ کو بازیافت کر سکتا ہے۔ +- **مخصوص سپورٹ ٹیم** - آپ کے والٹ میں ایک مخصوص سپورٹ ٹیم ہے جہاں مسائل کا سامنا کرنے پر صارفین جا سکتے ہیں۔ +- **تعلیمی وسائل/دستاویزات** - آپ کے پروڈکٹ میں صارفین کی مدد اور تعلیم کے لیے ایک اچھی طرح سے ڈیزائن کیا گیا آن بورڈنگ تجربہ ہونا چاہیے۔ یا مضامین یا ویڈیوز جیسے کیسے کریں مواد کا ثبوت۔ + +## ایک والٹ شامل کرنا {#adding-a-wallet} + +اگر آپ ethereum.org میں والٹ شامل کرنا چاہتے ہیں تو، GitHub پر ایک ایشو بنائیں۔ + + + ایک ایشو بنائیں + + +## دیکھ بھال {#maintenance} + +جیسا کہ Ethereum کی فطرت متغیر ہے، ٹیمیں اور پروڈکٹس آتے جاتے رہتے ہیں اور روزانہ جدت ہوتی رہتی ہے، اس لیے ہم اپنے مواد کی معمول کی جانچ پڑتال کریں گے تاکہ: + +- یقینی بنائیں کہ فہرست میں شامل تمام والٹس اور dapps اب بھی ہمارے معیارات پر پورا اترتے ہیں +- اس بات کی تصدیق کریں کہ ایسے کوئی پروڈکٹس تجویز نہیں کیے گئے ہیں جو فی الحال درج شدہ پروڈکٹس سے زیادہ ہمارے معیار پر پورا اترتے ہوں + +ethereum.org کو اوپن سورس کمیونٹی کے ذریعے برقرار رکھا جاتا ہے اور ہم اسے اپ ٹو ڈیٹ رکھنے میں مدد کے لیے کمیونٹی پر انحصار کرتے ہیں۔ اگر آپ کو درج کردہ والٹس کے بارے میں کوئی ایسی معلومات نظر آتی ہے جسے اپ ڈیٹ کرنے کی ضرورت ہے، تو براہ کرم [ایک ایشو کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) یا [پل کی درخواست کریں](https://github.com/ethereum/ethereum-org-website/pulls)! + +## استعمال کی شرائط {#terms-of-use} + +براہ کرم ہماری [استعمال کی شرائط](/terms-of-use/) بھی دیکھیں۔ ethereum.org پر معلومات صرف عام معلومات کے مقاصد کے لیے فراہم کی جاتی ہے۔ diff --git a/public/content/translations/ur/contributing/content-resources/index.md b/public/content/translations/ur/contributing/content-resources/index.md new file mode 100644 index 00000000000..cce1b2dbcc3 --- /dev/null +++ b/public/content/translations/ur/contributing/content-resources/index.md @@ -0,0 +1,32 @@ +--- +title: "مواد کے وسائل شامل کرنا" +lang: ur-in +description: "ethereum.org پر مواد کے وسائل کی فہرست بنانے کے ہمارے معیارات" +--- + +# مواد کے وسائل شامل کرنا {#adding-content-resources} + +ہم ایتھیریم کی ہر چیز کا احاطہ کرنے کی امید نہیں کر سکتے ہیں اس لیے ہم کمیونٹی کی طرف سے بنائے گئے کچھ شاندار مضامین، ٹیوٹوریلز، نیوز لیٹرز، جاب بورڈز اور مختلف مواد کے وسائل کو ظاہر کرنے کی کوشش کرتے ہیں۔ یہ اکثر ایسے موضوعات پر مزید گہرائی سے معلومات فراہم کرتے ہیں جن میں صارفین دلچسپی لے سکتے ہیں۔ + +اگر کوئی مواد کا وسیلہ ہے جس کے بارے میں آپ کو لگتا ہے کہ اسے کسی صفحہ پر شامل کیا جانا چاہئے، تو بلا جھجھک اسے کہیں مناسب جگہ پر تجویز کریں۔ + +## ہم فیصلہ کیسے کرتے ہیں {#how-we-decide} + +سیکھنے کے وسائل کا مندرجہ ذیل معیارات کے مطابق جائزہ لیا جائے گا: + +- کیا مواد تازہ ترین ہے؟ +- کیا مواد پے وال کے پیچھے ہے؟ +- کیا معلومات درست ہیں؟ کیا یہ حقائق پر مبنی ہے یا رائے پر مبنی ہے؟ +- کیا مصنف قابل اعتبار ہے؟ کیا وہ اپنے ماخذ کا حوالہ دیتے ہیں؟ +- کیا یہ مواد کوئی ایسی الگ قدر شامل کرتا ہے جس کا احاطہ موجودہ وسائل/لنکس نہیں کرتے؟ +- کیا یہ مواد ہمارے [صارف شخصیات](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c) میں سے کسی ایک کی خدمت کرتا ہے؟ + +--- + +## اپنا مواد کا وسیلہ شامل کریں {#add-your-content-resource} + +اگر آپ ethereum.org پر کوئی مواد کا وسیلہ شامل کرنا چاہتے ہیں اور وہ معیارات پر پورا اترتا ہے، تو GitHub پر ایک ایشو بنائیں۔ + + + ایک ایشو بنائیں + diff --git a/public/content/translations/ur/contributing/design-principles/index.md b/public/content/translations/ur/contributing/design-principles/index.md new file mode 100644 index 00000000000..ac67dda91d7 --- /dev/null +++ b/public/content/translations/ur/contributing/design-principles/index.md @@ -0,0 +1,93 @@ +--- +title: "ڈیزائن کے اصول" +lang: ur-in +description: "ethereum.org کے ڈیزائن اور مواد کے فیصلوں کے پیچھے کے اصول" +--- + +# ہمارے ڈیزائن کے اصول {#contributing-to-ethereumorg-} + + ہیلو، اور ethereum.org کے ڈیزائن کے اصولوں میں آپ کا استقبال ہے۔ یہ ethereum.org کو تیار کرنے اور بہتر بنانے کے ایک جاری عمل کا حصہ ہے۔ + +ہمارے اصول سائٹ کی شکل و صورت اور اس پر موجود مواد سے آگاہ کرتے ہیں۔ + +آپ کو [ethereum.org میں حصہ ڈالنے](/contributing/) سے پہلے انہیں پڑھنا چاہیے۔ + +## ڈیزائن کے اصول کیا ہیں؟ {#ways-to-contribute} + +فکر نہ کریں، وہ بہت آسان ہیں! **ڈیزائن کے اصول** رہنما اصولوں کا ایک مجموعہ ہیں جن کا حوالہ ہم کسی چیز کو ڈیزائن کرتے وقت (یعنی تخلیق، برقرار رکھنے یا اپ ڈیٹ کرتے وقت) دیتے ہیں۔ + +ethereum.org کے تناظر میں یہ ڈیزائن کے اصول اس بنیاد کی حیثیت رکھتے ہیں جو ہم چاہتے ہیں کہ ویب سائٹ دنیا کے سامنے پیش کرے اور نمائندگی کرے۔ وہ تمنائی **اور** فعال دونوں ہیں۔ یہ صرف یہ نہیں ہے کہ ویب سائٹ _کیسی دکھتی ہے_، بلکہ یہ بھی کہ یہ _کیسے کام کرتی ہے_ اور یہاں تک کہ یہ کسی کو کیسا _محسوس_ کراتی ہے۔ ہر چیز، رنگوں سے لے کر صفحہ کے لے آؤٹ تک اور ہم ویب سائٹ پر Ethereum کے بارے میں کیسے بات کرتے ہیں، ان اصولوں سے مطلع ہونا چاہیے۔ + +## عمل میں اصول {#how-decisions-about-the-site-are-made} + +آئیے ایک مثال دیکھتے ہیں۔ اصولوں میں سے ایک "قابل اعتبار" ہے، جس کا مطلب ہے کہ ہم چاہتے ہیں کہ سائٹ پر آنے والے لوگ یہ _محسوس کریں_ اور _جانیں_ کہ سائٹ قابل اعتماد ہے - بالکل وسیع تر Ethereum ایکو سسٹم کی طرح۔ اس اصول کے اندر، ہمارے پاس 3 فعال "ذیلی اصول" ہیں جن کے بارے میں ہمارا ماننا ہے کہ وہ قابل عمل اقدامات ہیں جو ہم سائٹ کو قابل اعتبار بنانے کے لیے اٹھا سکتے ہیں: + +- _“تازہ”_ یعنی مواد کو اپ ٹو ڈیٹ رکھیں۔ +- _“سماجی ثبوت”_ یعنی، ایکو سسٹم کے سائز، تنوع اور سرگرمی کو دکھائیں (آپ جانتے ہیں: Ethereum اپ گریڈ کی پیشرفت، DeFi، گیمنگ، تمام ہیکاتھون، وغیرہ) +- _“مستقل مزاج”_ یعنی، سائٹ کے ڈیزائن اور تحریر کے لہجے اور درستگی میں مستقل مزاجی۔ + +لہذا جب ہم ڈیزائن کے فیصلے کر رہے ہوں، یا کاپی رائٹنگ کے فیصلے کر رہے ہوں، تو ہم "قابل اعتبار" اصول کا حوالہ دے سکتے ہیں اور پوچھ سکتے ہیں: + +- _“کیا سائٹ موجودہ معلومات کی عکاسی کرتی ہے؟”_ +- _“ہم ایکو سسٹم کے سائز اور سرگرمی کو کیسے اور کہاں دکھا رہے ہیں؟”_ +- _“کیا کمیونٹی کے کسی رکن کی طرف سے پیش کردہ نئی تجاویز، جن کا میں جائزہ لے رہا ہوں، سائٹ پر موجودہ ڈیزائن اور تحریر کے مطابق ہیں؟”_ + +## ethereum.org کے ڈیزائن کے اصول {#contributors} + +### 1۔ متاثر کن {#1-inspirational} + +سائٹ کو صارفین کو یہ خواب دیکھنے کی ترغیب دینی چاہیے کہ Ethereum دنیا کو کیسے بدل سکتا ہے۔ اسے لوگوں کو Ethereum ایکو سسٹم کے ٹولز اور ایپس کو دریافت کرنے، کھیلنے اور ان کے ساتھ چھیڑ چھاڑ کرنے کی ترغیب دینی چاہیے۔ + +- **انقلابی:** سائٹ کو دنیا کو بامعنی طور پر تبدیل کرنے کے لیے Ethereum کے مہتواکانکشی اہداف سے آگاہ کرنا چاہیے۔ یہ واضح ہونا چاہیے کہ Ethereum صرف کوئی نیا ٹیک اسٹیک نہیں ہے - یہ ایک تبدیلی لانے والی ٹیکنالوجی ہے۔ +- **تعلیم کے ذریعے بااختیار بنانا:** سائٹ کو لوگوں کو تعلیم دینی چاہیے تاکہ وہ Ethereum کی صلاحیت کو سمجھ سکیں، ایکو سسٹم میں اپنی جگہ تلاش کر سکیں، اور اس میں حصہ لینے کے لیے خود کو بااختیار محسوس کر سکیں۔ + +بصری سمت • مواد + +### 2۔ عالمگیر {#2-universal} + +Ethereum ایک عالمی، غیر مرکزی پروجیکٹ ہے اور ہمارے سامعین اس کی عکاسی کرتے ہیں۔ سائٹ کو ہر ایک کے لیے قابل رسائی ہونے کی خواہش رکھنی چاہیے، اور دنیا کی بہت سی ثقافتوں کے لیے حساس ہونا چاہیے۔ + +- **قابل رسائی:** سائٹ کو رسائی کے رہنما اصولوں پر عمل کرنا چاہیے - بشمول کم بینڈوتھ کنکشن والے لوگوں کے لیے۔ +- **سیدھا سادھا:** سائٹ سادہ اور غیر مبہم ہونی چاہیے۔ کاپی میں ایسی زبان استعمال نہیں کرنی چاہیے جس کی غلط تشریح کی جا سکے یا ترجمہ میں گم ہو جائے۔ +- **Ethereum کثیر جہتی ہے:** Ethereum ایک پروجیکٹ، ایک کوڈبیس، ایک کمیونٹی، اور ایک وژن ہے۔ Ethereum مختلف لوگوں کے لیے مختلف وجوہات کی بنا پر قیمتی ہے، اور اس میں شامل ہونے کے بہت سے طریقے ہیں۔ + +تحریری نظام • رنگ کا استعمال • بصری سمت • مواد + +### 3۔ ایک اچھی کہانی {#3-a-good-story} + +ویب سائٹ کو ایک اچھی کہانی کی طرح کام کرنا چاہیے۔ زائرین ایک سفر پر ہیں، اور آپ جو مواد فراہم کرتے ہیں وہ اس کا ایک حصہ ہے۔ آپ کے تعاون کو ایک واضح بیانیے میں فٹ ہونا چاہیے: جس میں ایک آغاز (تعارف/داخلی نقطہ)، وسط (سیکھنے اور بصیرت کا مجموعہ)، اور اختتام (متعلقہ وسائل کا ایک لنک، یا اگلے اقدامات) ہو۔ + +- **درجہ بندی**: ایک واضح، درجہ بندی کے لحاظ سے ترتیب دیا گیا معلوماتی فن تعمیر ethereum.org کے زائرین کو اپنے اہداف حاصل کرنے کی کوشش کے دوران سائٹ کو "ایک کہانی کے طور پر" نیویگیٹ کرنے میں مدد کرتا ہے۔ +- **ایک سنگ میل:** ہم جوابات تلاش کرنے والے ہر شخص کے لیے ایک سنگ میل ہیں۔ ہم ان بہت سے وسائل کو تبدیل نہیں کرنا چاہتے یا ان کا متبادل نہیں بننا چاہتے جو پہلے سے موجود ہیں۔ ہم ایک جواب دیتے ہیں اور قابل اعتماد اگلے اقدامات فراہم کرتے ہیں۔ + +صارف کے سفر • مواد + +### 4. قابل اعتبار {#4-credible} + +لوگ Ethereum ایکو سسٹم سے اپنا تعارف کرا رہے ہوں گے یا وہ شکی ہو سکتے ہیں۔ آپ جس طرح سے بات چیت کرتے ہیں اس میں اس ذمہ داری کو تسلیم کریں۔ اس بات کو یقینی بنائیں کہ وہ دونوں Ethereum ایکو سسٹم میں زیادہ اعتماد کے ساتھ جائیں۔ + +- **تازہ:** ہمیشہ اپ ٹو ڈیٹ۔ +- **سماجی ثبوت:** ایکو سسٹم کے سائز، تنوع اور سرگرمی کو دکھائیں۔ +- **مستقل مزاج:** ڈیزائن اور مواد میں مستقل مزاجی ساکھ کو ظاہر کرتی ہے۔ + +بصری سمت • مواد + +### 5. باہمی بہتری {#5-collaborative-improvement} + +ویب سائٹ بہت سے شراکت داروں کی پیداوار ہے، بالکل اسی طرح جیسے مجموعی طور پر ایکو سسٹم۔ + +- **کھلا:** پورے ایکو سسٹم میں سورس کوڈ، عمل اور پروجیکٹس کی شفافیت کا جشن منائیں۔ +- **قابل توسیع:** ماڈیولریٹی ہمارے ہر کام کے پیچھے ایک کلیدی توجہ ہے، اور اس لیے شراکت کو بھی ماڈیولر ہونا چاہیے۔ سائٹ کا بنیادی ڈیزائن، جزو کوڈ اور نفاذ اسے مستقبل میں آسانی سے توسیع دینے کے قابل بنانا چاہیے۔ +- **تجرباتی:** ہم مسلسل تجربہ، جانچ اور تکرار کر رہے ہیں۔ +- **باہمی تعاون:** یہ پروجیکٹ ہم سب کو اکٹھا کرتا ہے۔ +- **پائیدار:** کمیونٹی کے ذریعہ طویل مدتی دیکھ بھال کے لیے ترتیب دینا + +آپ ہمارے ڈیزائن کے اصولوں کو [ہماری سائٹ پر](/) عملی طور پر دیکھ سکتے ہیں۔ + +## رائے دیں {#give-feedback} + +**اس دستاویز پر اپنی رائے کا اشتراک کریں!** ہمارے مجوزہ اصولوں میں سے ایک "**باہمی بہتری**" ہے جس کا مطلب ہے کہ ہم چاہتے ہیں کہ ویب سائٹ بہت سے شراکت داروں کی پیداوار ہو۔ لہذا اس اصول کی روح کے مطابق، ہم ان ڈیزائن اصولوں کو Ethereum کمیونٹی کے ساتھ بانٹنا چاہتے ہیں۔ + +اگرچہ یہ اصول ethereum.org ویب سائٹ پر مرکوز ہیں، ہمیں امید ہے کہ ان میں سے بہت سے مجموعی طور پر Ethereum ایکو سسٹم کی اقدار کے نمائندہ ہیں۔ ہو سکتا ہے کہ آپ ان میں سے کچھ کو اپنے پروجیکٹ میں شامل کرنا چاہیں! + +ہمیں [Discord سرور](https://discord.gg/ethereum-org) پر یا [ایک مسئلہ بنا کر](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) اپنے خیالات سے آگاہ کریں۔ diff --git a/public/content/translations/ur/contributing/design/adding-design-resources/index.md b/public/content/translations/ur/contributing/design/adding-design-resources/index.md new file mode 100644 index 00000000000..feb7c566dca --- /dev/null +++ b/public/content/translations/ur/contributing/design/adding-design-resources/index.md @@ -0,0 +1,69 @@ +--- +title: "ڈیزائن کے وسائل شامل کرنا" +description: "ethereum.org پر ڈیزائن مواد کے معیار کو یقینی بنانے کے لیے رہنما خطوط اور تقاضے" +lang: ur-in +--- + +# ڈیزائن کے وسائل شامل کرنا {#adding-design-resources} + +کوئی بھی [web3 صفحہ میں ڈیزائن اور UX](/developers/docs/design-and-ux/) پر نئے ڈیزائن مواد کی تجویز دے سکتا ہے۔ + +آگاہ رہیں کہ اس صفحہ کا مرکز خواہشمند web3 ڈیزائنرز کو صارف کی قدر فراہم کرنا ہے۔ ڈیزائن کا سیکشن آپ کی خدمات، مصنوعات، یا پلیٹ فارمز کی تشہیر کے لیے نہیں ہے۔ + +اس بات کو یقینی بنانے کے لیے کہ ہم معلومات کا اعلیٰ معیار برقرار رکھیں اور قیمتی بصیرت کو فروغ دیں، ہم نے ایک لسٹنگ پالیسی قائم کی ہے: + +## تحقیقی مطالعات اور ڈیش بورڈز {#Research-studies} + +1. درست طریقہ کار + +a. طریقہ کار میں واضح طور پر یہ بیان ہونا چاہیے کہ ڈیٹا کیسے اکٹھا کیا گیا تھا۔ + +b. تحقیق میں شامل شرکاء کی تعداد بیان کی جانی چاہیے۔ + +c. استعمال کیے گئے تحقیقی طریقوں کو بیان کیا جانا چاہیے۔ + +2. Web3 ڈیزائنرز اور عام ڈیزائن کے استعمال کے معاملات سے مطابقت + +a. تحقیق کا موضوع web3 ڈیزائنرز سے متعلقہ ہونا چاہیے اور عام ڈیزائن کے استعمال کے معاملات کو حل کرنا چاہیے۔ + +3. بصیرت فراہم کرنے پر توجہ + +a. متن کا بنیادی مقصد کسی مخصوص پروجیکٹ یا کمپنی کو فروغ دینے کے بجائے بصیرت کا اشتراک ہونا چاہیے۔ + +## مضامین {#Articles} + +1. Web3 ڈیزائنرز/محققین اور عام Web3 ڈیزائن کے استعمال کے معاملات سے مطابقت + +a. مضمون کا موضوع web3 ڈیزائنرز اور محققین سے متعلقہ ہونا چاہیے، جو عام web3 ڈیزائن کے استعمال کے معاملات پر مرکوز ہو۔ + +2. تحریر کا بنیادی معیار + +a. مضمون گرامر اور ہجے کی غلطیوں سے پاک ہونا چاہیے۔ + +b. کلیدی بصیرت اور سیکھ فراہم کرنے پر زور دیا جانا چاہیے۔ + +c. تحریر مختصر اور جامع ہونی چاہیے۔ + +3. متن کا مقصد + +a. مضمون کا بنیادی مقصد کسی خاص پروجیکٹ یا کمپنی کو فروغ دینے کے بجائے بصیرت کا اشتراک ہونا چاہیے۔ + +## کمیونٹیز / DAOs {#Communities-and-DAOs} + +1. ویب سائٹ پر واضح طور پر یہ بتایا جانا چاہیے کہ DAO/کمیونٹی میں کیسے شامل ہوں + +2. رکنیت کے واضح فوائد + +a. رکن بننے کے فوائد نمایاں طور پر دکھائے جانے چاہئیں۔ + +**مثالیں**: کام پر رائے حاصل کرنا، ملازمت کے مواقع یا باؤنٹیز تک رسائی، ڈیزائن اور تحقیق کی بصیرت کا اشتراک۔ + +3. Discord پر فعال اور متحرک مواصلات + +a. Discord کمیونٹی میں جاندار اور فعال مواصلات کا مظاہرہ ہونا چاہیے۔ + +b. ماڈریٹرز کو کمیونٹی کو برقرار رکھنے اور بات چیت کو آسان بنانے میں فعال طور پر شامل ہونا چاہیے۔ + +c. کمیونٹی کو پچھلے دو ہفتوں کے اندر قیمتی اور نتیجہ خیز گفتگو کا ٹریک ریکارڈ دکھانا چاہیے۔ + +ان معیارات پر عمل کرتے ہوئے، ہمارا مقصد اپنی کمیونٹی کے اندر ایک ترقی پذیر اور علم کے اشتراک کا ماحول پیدا کرنا ہے۔ ہمیں یقین ہے کہ یہ وائٹ لسٹنگ پالیسی اس بات کو یقینی بنائے گی کہ ہمارے صارفین کو قابل اعتماد، متعلقہ، اور بصیرت سے بھرپور وسائل تک رسائی حاصل ہو۔ ہمارے پلیٹ فارم کے اندر مواد کے معیار کو برقرار رکھنے میں آپ کی سمجھ اور تعاون کا شکریہ۔ diff --git a/public/content/translations/ur/contributing/design/index.md b/public/content/translations/ur/contributing/design/index.md new file mode 100644 index 00000000000..fbb35de44de --- /dev/null +++ b/public/content/translations/ur/contributing/design/index.md @@ -0,0 +1,77 @@ +--- +title: "ڈیزائن میں تعاون" +description: "ethereum.org میں ڈیزائن کا تعاون" +lang: ur-in +--- + +# ethereum.org میں ڈیزائن کا تعاون {#design-contributions} + +ڈیزائن کسی بھی پروجیکٹ کا ایک اہم جزو ہے، اور ethereum.org کے لیے اپنا وقت اور ڈیزائن کی مہارتیں وقف کر کے، آپ ہمارے ملاحظہ کاروں کے لیے صارف کے تجربے کو بہتر بنانے میں مدد کر سکتے ہیں۔ ایک اوپن سورس پروجیکٹ میں تعاون کرنا متعلقہ تجربہ حاصل کرنے اور باہمی تعاون کے ماحول میں اپنی مہارتوں کو فروغ دینے کا موقع فراہم کرتا ہے۔ آپ کو دوسرے ڈیزائنرز، ڈیولپرز، اور کمیونٹی ممبران کے ساتھ کام کرنے کا موقع ملے گا، جن میں سے ہر ایک کے اپنے منفرد نقطہ نظر اور بصیرت ہوں گے۔ + +بالآخر، یہ ایک متنوع اور متاثر کن پورٹ فولیو بنانے کا ایک بہترین طریقہ ہے جو آپ کی ڈیزائن کی مہارتوں کو ظاہر کرتا ہے۔ + +## کیسے حصہ ڈالیں? + +###  ابتدائی ڈیزائن پروٹوٹائپس پر فیڈ بیک فراہم کریں {#design-critique} + +ہمیں کبھی کبھی اپنے خام خیالات کی جانچ میں مدد کی ضرورت ہوتی ہے۔ یہ بغیر کسی تکنیکی علم کے تعاون کرنے کا ایک بہترین طریقہ ہے۔ + +1. ڈیزائن ٹیم [Discord](https://discord.com/invite/ethereum-org) اور [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) پر ایک موک اپ ڈیزائن شیئر کرے گی۔ +2. کمنٹس فنکشن کے ذریعے فیڈ بیک فراہم کرنے کے لیے ڈیزائنز کے ذریعے آپ کی رہنمائی کی جائے گی۔ +3. نتیجہ GitHub ایشو میں شیئر کیا جائے گا اور پھر ٹیم کے ذریعے اسے بند کر دیا جائے گا۔ + +###  سروے ریسرچ میں حصہ لیں {#answer-surveys} + +ہماری ویب سائٹ پر اس طرح فیڈ بیک فراہم کریں: + +1. ethereum.org پر جا کر اور صفحات کو پڑھ کر۔ +2. نیچے دائیں کونے میں فیڈ بیک ویجیٹ پر کلک کر کے اور ڈیزائن اور مواد سے متعلق سوالات کے جوابات دے کر۔ +3. فری فارمیٹ سوالات پر توجہ دیں۔ + +###  ویب سائٹ پر ڈیزائن سے متعلق مسائل تلاش کریں اور ان کی اطلاع دیں {#report-design-issues} + +ethereum.org ایک تیزی سے بڑھتی ہوئی ویب سائٹ ہے جس میں بہت سی خصوصیات اور مواد موجود ہے۔ کچھ UI آسانی سے متروک ہو سکتے ہیں یا انہیں بہتر بنایا جا سکتا ہے۔ اگر آپ کو ایسی کوئی مثال ملتی ہے، تو براہ کرم اس کی اطلاع دیں تاکہ یہ ہماری توجہ میں آئے۔ + +1. ویب سائٹ کا جائزہ لیں اور اس کے ڈیزائن پر توجہ دیں۔ +2. اگر آپ کو کوئی بصری یا UX مسائل نظر آتے ہیں تو اسکرین شاٹس اور نوٹس لیں۔ +3. [بگ رپورٹ](https://github.com/ethereum/ethereum-org-website/issues/new/choose) کا استعمال کرتے ہوئے پائے گئے مسائل کی اطلاع دیں۔ + +###  ڈیزائن میں تبدیلیوں کی تجویز دیں {#propose-design-changes} + +اگر آپ ڈیزائن کے چیلنجز کا سامنا کرنے میں آسانی محسوس کرتے ہیں، تو آپ ہمارے GitHub ایشوز بورڈ پر جا سکتے ہیں اور [ڈیزائن سے متعلق ایشوز](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) کے لیے فلٹر کر سکتے ہیں۔ + +1. ہماری ویب سائٹ کا جائزہ لیں اور اس کے ڈیزائن پر توجہ دیں یا ہمارے GitHub ریپوزٹری پر جائیں اور [“Design required” ٹیگ](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) کے ساتھ فلیگ کیے گئے مسائل کا جائزہ لیں۔ +2. حل پر غور کریں اور اسے ڈیزائن کریں۔ (مثالی طور پر ہمارے [ڈیزائن سسٹم](https://www.figma.com/community/file/1134414495420383395) کا استعمال کرتے ہوئے)۔ +3. متعلقہ GitHub ایشو میں حل کی تجویز دیں یا [ایک نیا بنائیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)۔ +4. ڈیزائن ٹیم کے جائزے کا انتظار کریں۔ + +###  مل کر ڈیزائن سسٹم بنائیں {#Contribute-to-design-system} + +ہمارا ڈیزائن سسٹم ethereum.org کو ڈیزائن کرنا دلچسپ اور آسان بناتا ہے۔ اگر آپ ایک تجربہ کار ڈیزائنر ہیں، تو آپ ویب سائٹ کے لیے بہت سے اجزاء تیار کرنے میں ہماری مدد کر سکتے ہیں۔ + +1. GitHub پر [ڈیزائن سسٹم بورڈ](https://github.com/ethereum/ethereum-org-website/labels/design%20system) سے کام کرنے کے لیے ایک ایشو منتخب کریں یا ایک نیا بنائیں۔ +2. درخواست کریں کہ منتخب کردہ ایشو آپ کو تفویض کیا جائے۔ +3. Figma میں درخواست کردہ جزو کو ڈیزائن کرنا شروع کریں۔ +4. جب آپ کو جائزے یا رہنمائی کی ضرورت ہو تو اسے GitHub پر ڈیزائن ٹیم کے ساتھ شیئر کریں۔ +5. ڈیزائن ٹیم جائزہ لے گی۔ +6. ڈیزائن ٹیم تبدیلیوں کو مرکزی فائل میں شامل کرے گی اور فائل کو کمیونٹی میں شائع کرے گی۔ + +###  ویب سائٹ پر ڈیزائن سے متعلق مواد لکھیں {#write-design-articles} + +Ethereum ڈیولپر کمیونٹی مضبوط ہے، لیکن ڈیزائن کمیونٹی تھوڑی پیچھے رہ رہی ہے۔ اگر آپ web3 کا علم رکھنے والے ڈیزائنر ہیں، تو براہ کرم اپنی سیکھی ہوئی باتوں کو بڑی کمیونٹی کے ساتھ شیئر کرنے پر غور کریں تاکہ ہم سب مل کر ترقی کر سکیں اور بہتر ہو سکیں؛ ہمارے پاس [Ethereum کے لیے ڈیزائننگ پر ایک صفحہ](/developers/docs/design-and-ux/) ہے جس میں آپ تعاون کر سکتے ہیں۔ آپ ہماری [لسٹنگ پالیسیاں](/contributing/design/adding-design-resources) بھی دیکھ سکتے ہیں۔ + +1. ڈیزائن کے ان موضوعات پر غور کریں جنہیں ethereum.org پر شامل کیا جانا چاہیے اور جو اس شعبے میں ڈیزائنرز کے لیے فائدہ مند ہوں گے۔ +2. ہمارے GitHub ریپوزٹری پر جائیں اور ایک موضوع کی تجویز دیتے ہوئے [ایک ایشو اٹھائیں](https://github.com/ethereum/ethereum-org-website/issues/new) (ابھی مواد نہ لکھیں)۔ +3. ڈیزائن ٹیم کی منظوری کا انتظار کریں۔ +4. منظور ہونے کے بعد، مواد لکھیں۔ +5. اسے متعلقہ GitHub ایشو میں جمع کرائیں۔ + +###  نئی تمثیلیں بنائیں {#prepare-illustrations} + +تجریدی موضوعات کی وضاحت کے لیے ویژولائزیشنز سب سے طاقتور ٹولز میں سے ایک ہیں۔ ڈایاگرام اور انفوگرافکس شامل کرنے میں بہت بڑی صلاحیت ہے۔ آخر کار، ایک تصویر ہزار الفاظ کہہ سکتی ہے۔ + +1. ہماری ویب سائٹ پر جائیں اور ایسے صفحات دیکھیں جہاں کچھ نئے انفوگرافکس شامل کیے جا سکتے ہیں۔ +2. یقینی بنائیں کہ تمثیل کا انداز ہمارے [اثاثوں](/assets/) سے مطابقت رکھتا ہے۔ +3. ہمارے GitHub ریپوزٹری پر جائیں اور تمثیل کی تجویز دیتے ہوئے [ایک ایشو اٹھائیں](https://github.com/ethereum/ethereum-org-website/issues/new)۔ +4. ڈیزائن ٹیم اس کا جائزہ لے گی۔ +5. ہم ایک نیا ایشو بناتے ہیں تاکہ ایک ڈیولپر سے نئی تصویر کو نافذ کرنے کے لیے کہا جا سکے۔ diff --git a/public/content/translations/ur/contributing/index.md b/public/content/translations/ur/contributing/index.md new file mode 100644 index 00000000000..ab6795f85e2 --- /dev/null +++ b/public/content/translations/ur/contributing/index.md @@ -0,0 +1,120 @@ +--- +title: "شراکت داری کرنا" +description: "ethereum.org میں تعاون کرنے کے مختلف طریقوں کے بارے میں جانیں۔" +lang: ur-in +--- + +# ethereum.org میں تعاون کرنا 🦄 {#contributing-to-ethereumorg} + +Ethereum.org ایک اوپن سورس پروجیکٹ ہے جس میں **12,000+** سے زیادہ تعاون کنندگان ہیں جو ویب سائٹ کا ترجمہ کرنے، لکھنے، ڈیزائن کرنے اور اسے برقرار رکھنے میں مدد کرتے ہیں۔ + +ہم ایک خوش آمدید کہنے والی کمیونٹی ہیں جو آپ کو Ethereum ایکو سسٹم میں بڑھنے اور تعلیم حاصل کرنے میں مدد کرے گی، اور ساتھ ہی بامعنی طور پر تعاون کرنے اور متعلقہ عملی تجربہ حاصل کرنے میں بھی مدد کرے گی! + +## تعاون کرنے کے طریقے {#ways-to-contribute} + +**ترجمے** + +- [ترجمہ پروگرام میں شامل ہوں](/contributing/translation-program/) – ethereum.org کو نئی زبانوں میں لانے میں ہماری مدد کریں۔ + +**ڈیولپمنٹ** + +- [کسی کھلے مسئلے پر کام کریں](https://github.com/ethereum/ethereum-org-website/issues) – وہ کام جس کی ہم نے نشاندہی کی ہے کہ اسے کرنے کی ضرورت ہے۔ + +**ڈیزائن** + +- [ویب سائٹ کو ڈیزائن کرنے میں مدد کریں](/contributing/design/) – ہر سطح کے ڈیزائنرز ویب سائٹ کو بہتر بنانے میں تعاون کر سکتے ہیں۔ + +**مواد** + +- [مواد بنائیں/ترمیم کریں](/contributing/#how-to-update-content) – نئے صفحات تجویز کریں یا جو کچھ یہاں پہلے سے موجود ہے اس میں تبدیلیاں کریں۔ +- [کمیونٹی کے وسائل شامل کریں](/contributing/content-resources/) – ایک متعلقہ صفحہ پر ایک مددگار مضمون یا وسیلہ شامل کریں۔ +- [ایک ڈیزائن وسیلہ تجویز کریں](/contributing/design/adding-design-resources/) – مددگار ڈیزائن وسائل شامل کریں، اپ ڈیٹ کریں، اور حذف کریں۔ +- [کوئز](/contributing/quizzes/) – ایک متعلقہ صفحہ کے لیے کوئز سوالات کے بینک شامل کریں، اپ ڈیٹ کریں، اور حذف کریں۔ + +**فیچر کے آئیڈیاز** + +- [ایک فیچر کی درخواست کریں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – ہمیں ایک نئے فیچر یا ڈیزائن کے لیے اپنے کسی بھی آئیڈیا کے بارے میں بتائیں۔ + +**پروڈکٹ کی فہرستیں** + +- [ایک ایکسچینج شامل کریں](/contributing/adding-exchanges/) – ہمارے [exchange finder](/get-eth/#country-picker) میں ایک ایکسچینج شامل کریں۔ +- [ایک پروڈکٹ شامل کریں](/contributing/adding-products/) – ایک متعلقہ صفحہ پر ایک dapp یا والٹ شامل کریں۔ +- [ڈیولپر ٹولز شامل کریں](/contributing/adding-developer-tools/) – ایک متعلقہ صفحہ پر ایک ڈیولپر ٹول شامل کریں۔ +- [ایک لیئر 2 شامل کریں](/contributing/adding-layer-2s/) – ایک متعلقہ صفحہ پر ایک لیئر 2 شامل کریں۔ +- [ایک اسٹیکنگ پروڈکٹ یا سروس شامل کریں](/contributing/adding-staking-products/) – ایک ایسا پروجیکٹ شامل کریں جو سولو اسٹیکنگ، پولڈ اسٹیکنگ، یا اسٹیکنگ بطور سروس کی سہولت فراہم کرنے میں مدد کرتا ہے۔ +- [ایک والٹ شامل کریں](/contributing/adding-wallets/) – [والٹ تلاش کرنے والے صفحہ](/wallets/find-wallet/) کے لیے ایک والٹ شامل کریں۔ +- [ہمارے DeSci صفحہ کے لیے ایک پروجیکٹ تجویز کریں](/contributing/adding-desci-projects/) – Ethereum پر بنایا گیا ایک پروجیکٹ شامل کریں جو ڈی سینٹرلائزڈ سائنس میں تعاون کرتا ہے۔ + +کوئی سوال؟ 🤔 ہمارے [Discord سرور](https://discord.gg/ethereum-org) میں شامل ہوں + +## تعاون شروع کرنے کے لیے اچھے پہلے کام + +یہ چند موجودہ کام ہیں جنہیں حل کرنے میں آپ ہماری مدد کر سکتے ہیں اور ان کی ذمہ داری لے سکتے ہیں۔ زیادہ تر کے لیے آپ کو GitHub اکاؤنٹ کی ضرورت ہوگی کیونکہ ویب سائٹ میں زیادہ تر تبدیلیاں GitHub کے ذریعے کی جاتی ہیں۔ + + + +تمام کام دیکھیں + +## ethereum.org پر کیسے کام کریں {#how-to-update-content} + +اگر آپ [ترجمہ پروگرام](/contributing/translation-program/) میں تعاون کرنا چاہتے ہیں، تو ہم آپ سے [Crowdin](https://crowdin.com/project/ethereum-org) پر ایک اکاؤنٹ بنانے کے لیے کہتے ہیں۔ باقی ہر چیز کے لیے – ویب سائٹ پر مواد یا ویژول شامل کرنا یا ان میں ترمیم کرنا، بگز کو ٹھیک کرنا، کھلے کاموں پر کام کرنا – آپ کو ایک [GitHub](https://github.com/) اکاؤنٹ کی ضرورت ہوگی۔ + +تمام اپ ڈیٹس GitHub PR پروسیس کے ذریعے کی جاتی ہیں۔ اس کا مطلب ہے کہ آپ ویب سائٹ کی ایک مقامی کاپی بناتے ہیں، اپنی تبدیلیاں کرتے ہیں اور اپنی تبدیلیوں کو ضم کرنے کی درخواست کرتے ہیں۔ اگر آپ نے پہلے کبھی ایسا نہیں کیا ہے، تو ہماری [GitHub ریپوزٹری](https://github.com/ethereum/ethereum-org-website) کے نیچے دی گئی ہدایات پر عمل کریں۔ + +آپ کو کسی بھی چیز پر کام کرنے کے لیے اجازت کی ضرورت نہیں ہے، لیکن یہ ہمیشہ بہتر ہے کہ آپ ہمیں بتائیں کہ آپ کیا کرنے کا منصوبہ بنا رہے ہیں۔ آپ یہ کر سکتے ہیں بذریعہ: + +- [GitHub](https://github.com/ethereum/ethereum-org-website) میں کسی مسئلے یا PR پر تبصرہ کرکے +- ہمارے [Discord سرور](https://discord.gg/ethereum-org) پر پیغام بھیج کر + +تعاون کرنے سے پہلے، یقینی بنائیں کہ آپ ان سے واقف ہیں: + +- [ethereum.org کا ارتقا پذیر وژن](/about/) +- ہمارے [ڈیزائن کے اصول](/contributing/design-principles/) +- ہماری [اسٹائل گائیڈ](/contributing/style-guide/) +- ہمارا [ضابطہ اخلاق](/community/code-of-conduct) + +## سائٹ کے بارے میں فیصلے کیسے کیے جاتے ہیں {#how-decisions-about-the-site-are-made} + +انفرادی PRs، ڈیزائن کے ارتقاء اور بڑے اپ گریڈ کے بارے میں فیصلے Ethereum ایکو سسٹم کی ایک ٹیم کرتی ہے۔ اس ٹیم میں پروجیکٹ مینیجرز، ڈیولپرز، ڈیزائنرز، مارکیٹنگ اور کمیونیکیشن، اور موضوع کے ماہرین شامل ہیں۔ کمیونٹی کی رائے ہر فیصلے سے آگاہ کرتی ہے: لہذا براہ کرم مسائل میں سوالات اٹھائیں، PRs جمع کروائیں، یا ٹیم سے رابطہ کریں: + +- [website@ethereum.org](mailto:website@ethereum.org) +- [@ethdotorg](https://twitter.com/ethdotorg) +- [Discord سرور](https://discord.gg/ethereum-org) + +### سرقہ پر ایک نوٹ {#plagiarism} + +ethereum.org میں کوئی بھی مواد یا آرٹفیکٹ شامل کرتے وقت صرف اپنا اصل کام یا وہ مواد استعمال کریں جسے استعمال کرنے کی آپ کو اجازت ہے۔ Ethereum ایکو سسٹم کے اندر بہت سے پروجیکٹس اوپن سورس لائسنسنگ کا استعمال کرتے ہیں جو معلومات کے آزادانہ اشتراک کی اجازت دیتا ہے۔ تاہم، اگر آپ کو یہ معلومات نہیں ملتی ہیں، تو اسے ethereum.org میں شامل کرنے کی کوشش نہ کریں۔ سرقہ سمجھی جانے والی کوئی بھی پل ریکویسٹ مسترد کر دی جائے گی۔ + +## اوپن سورس میں نئے ہیں؟ {#new-to-open-source} + +ہماری GitHub ریپوزٹری پر ہمارے پاس کم رکاوٹ والے مسائل ہیں جو خاص طور پر ان ڈیولپرز کے لیے ڈیزائن کیے گئے ہیں جو اوپن سورس میں نئے ہیں، جن پر [good first issue](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) کا لیبل لگا ہوا ہے۔ + +## اپنا آن چین اچیومنٹ ٹوکن (OAT) حاصل کریں {#oat} + +اگر آپ کا تعاون ethereum.org میں ضم ہو جاتا ہے، تو آپ کو [Galxe](https://app.galxe.com/quest/ethereumorg) پر ایک خصوصی بیج حاصل کرنے کا موقع ملے گا۔ ایک آن چین اچیومنٹ ٹوکن (OAT) اس بات کا ثبوت ہے کہ آپ نے ایکو سسٹم کو تھوڑا اور بہتر بنانے میں مدد کی ہے۔ + +[OATs کے بارے میں مزید](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03) + +### کیسے حاصل کریں + +1. ہمارے [Discord سرور](https://discord.gg/ethereum-org) میں شامل ہوں۔ +2. اپنے تعاون کا ایک لنک `#🥇 | proof-of-contribution` چینل میں پیسٹ کریں۔ +3. ہماری ٹیم کے کسی رکن کا انتظار کریں کہ وہ آپ کو آپ کے OAT کا لنک بھیجے۔ +4. اپنا OAT حاصل کریں! + +OATs حاصل کرنے کے لیے آپ کو صرف سیلف-کسٹڈی والٹس کا استعمال کرنا چاہیے۔ ایکسچینج اکاؤنٹس یا دیگر اکاؤنٹس کا استعمال نہ کریں جن کی پرائیویٹ کیز آپ کے پاس نہیں ہیں، کیونکہ یہ آپ کو اپنے OATs تک رسائی حاصل کرنے اور ان کا نظم کرنے کی اجازت نہیں دیں گے۔ + +## اپنا GitPOAP حاصل کریں {#claim-gitpoap} + +GitPOAP آپ کے ضم شدہ تعاون کو خود بخود پہچان لے گا اور آپ کو ان کے اپنے پلیٹ فارم پر ایک الگ منفرد تعاون کنندگان کا POAP منٹ کرنے دے گا! + +### کیسے حاصل کریں {#how-to-claim} + +1. [GitPOAP](https://www.gitpoap.io) پر جائیں۔ +2. سائن ان آپشن کے ذریعے اپنے والٹ یا یہاں تک کہ اپنے ای میل سے جڑیں۔ +3. اپنا GitHub یوزرنیم، ETH ایڈریس، ENS نام یا کوئی بھی GitPOAP تلاش کریں یہ جانچنے کے لیے کہ آیا آپ اہل ہیں یا نہیں۔ +4. اگر آپ کا GitHub اکاؤنٹ اہل ہے، تو آپ ایک GitPOAP منٹ کر سکیں گے! + +## تعاون کنندگان {#contributors} + + diff --git a/public/content/translations/ur/contributing/quizzes/index.md b/public/content/translations/ur/contributing/quizzes/index.md new file mode 100644 index 00000000000..2b6bb422e95 --- /dev/null +++ b/public/content/translations/ur/contributing/quizzes/index.md @@ -0,0 +1,62 @@ +--- +title: "کوئز شامل کرنا" +description: "ethereum.org پر کوئز شامل کرتے وقت ہم جو پالیسی استعمال کرتے ہیں" +lang: ur-in +--- + +# کوئزز {#quizzes} + +کوئزز صارفین کے لیے خود کو جانچنے کا ایک موقع ہیں کہ آیا انہوں نے اس صفحے پر موجود مواد کو سمجھا ہے جسے انہوں نے ابھی پڑھا ہے۔ سوالات صرف صفحے پر فراہم کردہ مواد پر مبنی ہونے چاہئیں اور ایسی معلومات کے بارے میں نہیں پوچھنا چاہیے جن کا صفحے پر ذکر نہیں ہے۔ + +سوالات کی ساخت حسب ذیل ہے۔ سوال کا پرامپٹ، 1 صحیح جواب اس کی وضاحت کے ساتھ کہ یہ کیوں صحیح ہے، 3 غلط جوابات اس وضاحت کے ساتھ کہ وہ کیوں غلط ہیں۔ + +موجودہ کوئزز کی کچھ مثالیں یہاں مل سکتی ہیں: + +- [لیئر 2](/layer-2) +- [NFT](/nft/) +- [ایتھیریم کیا ہے؟](/what-is-ethereum/) +- [ETH کیا ہے؟](/what-is-ether/) + +## ایک لرن کوئز شامل کرنا + +اگر کوئی ایسا صفحہ ہے جس کے لیے لرن کوئز نہیں بنایا گیا ہے، تو براہ کرم اس کے لیے [ایک ایشو کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)۔ + +براہ کرم درج ذیل معلومات فراہم کریں: + +- وہ صفحہ جس پر آپ کوئز شامل کرنا چاہتے ہیں +- درج ذیل معلومات کے ساتھ 5 سوالات: + - صفحہ کا وہ حصہ جس پر سوال مبنی ہے + - سوال کا پرامپٹ + - 1 صحیح جواب اس کی وضاحت کے ساتھ کہ یہ کیوں صحیح ہے + - 3 غلط جوابات، ہر ایک اس کی وضاحت کے ساتھ کہ وہ کیوں غلط ہیں + +## ایک کوئز سوال شامل کرنا + +اگر کوئی ایسا سوال ہے جسے آپ کوئز کے لیے سوالیہ بینک میں شامل کرنا چاہتے ہیں، تو براہ کرم [ایک ایشو کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) اور درج ذیل معلومات فراہم کریں: + +- وہ صفحہ جس پر آپ کوئز سوال شامل کرنا چاہتے ہیں +- ہر سوال کے لیے درج ذیل معلومات فراہم کریں: + - صفحہ کا وہ حصہ جس پر سوال مبنی ہے + - سوال کا پرامپٹ + - 1 صحیح جواب اس کی وضاحت کے ساتھ کہ یہ کیوں صحیح ہے + - 3 غلط جوابات، ہر ایک اس کی وضاحت کے ساتھ کہ وہ کیوں غلط ہیں + +## کوئز سوال کو اپ ڈیٹ کرنا + +اگر کوئی ایسا سوال ہے جسے آپ کوئز کے لیے سوالیہ بینک میں اپ ڈیٹ کرنا چاہتے ہیں، تو براہ کرم [ایک ایشو کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) اور درج ذیل معلومات فراہم کریں: + +- وہ صفحہ جس پر آپ کوئز سوال اپ ڈیٹ کرنا چاہتے ہیں +- اپ ڈیٹ کیے جانے والے ہر سوال کے لیے، درج ذیل معلومات فراہم کریں: + - صفحہ کا وہ حصہ جس پر سوال مبنی ہے + - جس سوال کو آپ اپ ڈیٹ کرنا چاہتے ہیں اس کا سوالیہ پرامپٹ + - اپ ڈیٹ شدہ سوال کا پرامپٹ + - 1 صحیح جواب اس کی وضاحت کے ساتھ کہ یہ کیوں صحیح ہے + - 3 غلط جوابات، ہر ایک اس کی وضاحت کے ساتھ کہ وہ کیوں غلط ہیں + +## کوئز سوال کو ہٹانا + +اگر کسی سوال کے لیے صفحہ پر مواد مزید موجود نہیں ہے اور اسے ہٹانے کی ضرورت ہے، تو براہ کرم سوال کو ہٹانے کے لیے [ایک ایشو کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) اور درج ذیل معلومات فراہم کریں: + +- وہ صفحہ جس پر آپ کوئز سوال حذف کرنا چاہتے ہیں +- وہ سوال جسے آپ حذف کرنا چاہتے ہیں +- اگر ضروری ہو تو اس کی وضاحت کہ سوال کو کیوں ہٹایا جانا چاہیے diff --git a/public/content/translations/ur/contributing/translation-program/faq/index.md b/public/content/translations/ur/contributing/translation-program/faq/index.md new file mode 100644 index 00000000000..b6021fcd965 --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/faq/index.md @@ -0,0 +1,119 @@ +--- +title: "ترجمہ پروگرام کے اکثر پوچھے جانے والے سوالات (FAQ)" +lang: ur-in +description: "ethereum.org ترجمہ پروگرام کے بارے میں اکثر پوچھے جانے والے سوالات" +--- + +# ethereum.org کے ترجمے کی گائیڈ {#translating-ethereum-guide} + +اگر آپ ترجمہ پروگرام میں نئے ہیں اور اس میں شامل ہونے سے ہچکچا رہے ہیں، تو یہاں کچھ اکثر پوچھے جانے والے سوالات (FAQs) ہیں جو آپ کو شروع کرنے میں مدد کر سکتے ہیں۔ سب سے عام سوالات کے جوابات تلاش کرنے کے لیے اس گائیڈ کا استعمال کریں۔ + +## کیا مجھے ethereum.org کا ترجمہ کرنے کا معاوضہ مل سکتا ہے؟ {#compensation} + +Ethereum.org ایک اوپن سورس ویب سائٹ ہے، جس کا مطلب ہے کہ کوئی بھی اس میں شامل ہو سکتا ہے اور اپنا حصہ ڈال سکتا ہے۔ + +ethereum.org ترجمہ پروگرام اسی کا ایک توسیع ہے اور اسی طرح کے فلسفے کو ذہن میں رکھتے ہوئے منظم کیا گیا ہے۔ + +ترجمہ پروگرام کا مقصد Ethereum مواد کو ہر کسی کے لیے قابل رسائی بنانا ہے، چاہے وہ کوئی بھی زبان بولتے ہوں۔ یہ کسی بھی دو لسانی شخص کو Ethereum ایکو سسٹم میں شامل ہونے اور قابل رسائی طریقے سے اپنا حصہ ڈالنے کی اجازت دیتا ہے۔ + +اسی وجہ سے، ترجمہ پروگرام کھلا اور رضاکارانہ ہے، اور شرکت معاوضے کے تابع نہیں ہے۔ اگر ہم مترجمین کو ان کے ترجمہ کردہ الفاظ کی تعداد کے لیے معاوضہ دیتے، تو ہم صرف ان لوگوں کو ہی ترجمہ پروگرام میں شامل ہونے کی دعوت دے سکتے تھے جن کے پاس ترجمے کا کافی تجربہ ہو (پیشہ ور مترجم)۔ یہ ترجمہ پروگرام کو خارج کرنے والا بنا دے گا اور ہمیں بیان کردہ اہداف تک پہنچنے سے روکے گا، خاص طور پر: ہر کسی کو ایکو سسٹم میں حصہ لینے اور شامل ہونے کی اجازت دینا۔ + +ہم اپنے معاونین کو Ethereum ایکو سسٹم میں کامیاب ہونے کے قابل بنانے کی ہر ممکن کوشش کرتے ہیں؛ بہت سے غیر مالیاتی ترغیبات موجود ہیں جیسے: [POAPs کی پیشکش](/contributing/translation-program/acknowledgements/#poap) اور ایک [مترجم کا سرٹیفکیٹ](/contributing/translation-program/acknowledgements/#certificate)، نیز [ترجمہ لیڈر بورڈز](/contributing/translation-program/acknowledgements/) کو منظم کرنا اور [سائٹ پر ہمارے تمام مترجمین کی فہرست بنانا](/contributing/translation-program/contributors/)۔ + +## میں `` والے اسٹرنگز کا ترجمہ کیسے کروں؟ {#tags} + +ہر اسٹرنگ خالص متن کی شکل میں نہیں لکھا جاتا ہے۔ کچھ اسٹرنگز ایسے ہوتے ہیں جن میں HTML ٹیگز (`<0>`, ``) جیسے مخلوط اسکرپٹ ہوتے ہیں۔ یہ عام طور پر ہائپر لنکس یا کسی جملے کے بیچ میں متبادل اسٹائلنگ کے لیے ہوتا ہے۔ + +- ٹیگز کے اندر کے متن کا ترجمہ کریں لیکن خود ٹیگز کا نہیں۔ `<` اور `>` میں موجود کسی بھی چیز کا ترجمہ یا اسے ہٹایا نہیں جانا چاہیے۔ +- اسٹرنگ کو محفوظ رکھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ نیچے بائیں جانب "Copy Source" بٹن پر کلک کریں۔ یہ اصل اسٹرنگ کو کاپی کرکے ٹیکسٹ باکس میں پیسٹ کر دے گا۔ یہ آپ کو یہ واضح کرنے دیتا ہے کہ ٹیگز کہاں ہیں اور غلطیوں سے بچنے میں آپ کی مدد کرتا ہے۔ + +![کاپی سورس بٹن کو نمایاں کرنے والا کراؤڈن انٹرفیس](./html-tag-strings.png) + +آپ اپنی زبان میں اسے مزید فطری بنانے کے لیے اسٹرنگ کے اندر ٹیگز کی پوزیشن کو منتقل کر سکتے ہیں – بس پورے ٹیگ کو منتقل کرنا یقینی بنائیں۔ + +ٹیگز اور کوڈ کے ٹکڑوں سے نمٹنے کے بارے میں مزید گہرائی سے معلومات کے لیے، براہ کرم [ethereum.org ترجمہ اسٹائل گائیڈ](/contributing/translation-program/translators-guide/#dealing-with-tags) سے رجوع کریں۔ + +## اسٹرنگز کہاں رہتے ہیں؟ {#strings} + +اکثر صرف سورس اسٹرنگز ہی آپ کو درست ترجمہ فراہم کرنے کے لیے کافی نہیں ہو سکتے ہیں۔ + +- مزید معلومات کے لیے "screenshots" اور "context" پر ایک نظر ڈالیں۔ سورس اسٹرنگ سیکشن میں، آپ کو منسلک اسکرین شاٹ کی تصویر نظر آئے گی جو آپ کو دکھائے گی کہ ہم سیاق و سباق میں اسٹرنگ کا استعمال کیسے کر رہے ہیں۔ +- اگر آپ اب بھی غیر یقینی ہیں تو، "comment section" میں ایک فلیگ بلند کریں۔ [یقین نہیں ہے کہ تبصرہ کیسے چھوڑیں؟](#comment) + +![یہ دکھا رہا ہے کہ اسکرین شاٹ کے ساتھ کسی اسٹرنگ کے لیے سیاق و سباق کیسے فراہم کیا جا سکتا ہے۔](./source-string.png) + +![سیاق و سباق کے لیے شامل کردہ ایک مثال اسکرین شاٹ](./source-string-2.png) + +## میں تبصرے کیسے چھوڑ سکتا ہوں یا سوالات کیسے پوچھ سکتا ہوں؟ میں کسی مسئلے یا ٹائپ کی غلطیوں کو فلیگ کرنا چاہوں گا... {#comment} + +اگر آپ کسی خاص اسٹرنگ پر کوئی فلیگ اٹھانا چاہتے ہیں جس پر توجہ کی ضرورت ہے، تو بلا جھجھک ایک تبصرہ جمع کرائیں۔ + +- اوپر دائیں بار کے دوسرے بٹن پر کلک کریں۔ پوشیدہ ٹیب آپ کے دائیں جانب ظاہر ہوگا۔ ایک نیا تبصرہ چھوڑیں اور نیچے "Issue" چیک باکس پر کلک کریں۔ آپ ڈراپ ڈاؤن مینو سے کسی ایک آپشن کا انتخاب کرکے مسئلے کی قسم بتا سکتے ہیں۔ +- جمع کروانے کے بعد، اس کی اطلاع ہماری ٹیم کو دی جائے گی۔ ہم مسئلہ ٹھیک کریں گے اور آپ کے تبصرے کا جواب دے کر اور مسئلہ بند کر کے آپ کو بتائیں گے۔ +- اگر آپ کسی غلط ترجمہ کی اطلاع دیتے ہیں، تو ترجمہ اور آپ کے تجویز کردہ متبادل کا اگلے جائزے کے دوران ایک مقامی بولنے والے کے ذریعہ جائزہ لیا جائے گا۔ + +![یہ دکھا رہا ہے کہ تبصرے اور مسائل کیسے بنائے جائیں](./comment-issue.png) + +## ترجمہ میموری (TM) کیا ہے؟ {#translation-memory} + +ترجمہ میموری (TM) کراؤڈن کی ایک خصوصیت ہے جو ethereum.org پر پہلے سے ترجمہ شدہ تمام اسٹرنگز کو اسٹور کرتی ہے۔ جب کسی اسٹرنگ کا ترجمہ کیا جاتا ہے، تو یہ خود بخود ہمارے پروجیکٹ TM میں محفوظ ہو جاتا ہے۔ یہ آپ کا وقت بچانے میں مدد کرنے کے لیے ایک مفید ٹول ہو سکتا ہے! + +- "TM and MT Suggestions" سیکشن کو دیکھیں اور آپ دیکھیں گے کہ دوسرے مترجمین نے اسی یا اسی طرح کے اسٹرنگ کا ترجمہ کیسے کیا۔ اگر آپ کو اعلی مماثلت کی شرح والی کوئی تجویز ملتی ہے، تو بلا جھجھک اس پر کلک کرکے ترجمہ کا حوالہ دیں۔ +- اگر فہرست میں کچھ نہیں ہے، تو آپ پہلے سے کیے گئے ترجموں کے لیے TM کو تلاش کر سکتے ہیں اور مستقل مزاجی کے لیے انہیں دوبارہ استعمال کر سکتے ہیں۔ + +![ترجمہ میموری کا ایک اسکرین شاٹ](./translation-memory.png) + +## میں کراؤڈن لغت کا استعمال کیسے کروں؟ {#glossary} + +Ethereum کی اصطلاحات ہمارے ترجمے کے کام کا ایک اور اہم حصہ ہے کیونکہ اکثر نئی تکنیکی اصطلاحات ابھی تک بہت سی زبانوں میں مقامی نہیں ہوتیں۔ اس کے علاوہ، ایسی اصطلاحات ہیں جن کے مختلف سیاق و سباق میں مختلف معنی ہوتے ہیں۔ [Ethereum کی اصطلاحات کا ترجمہ کرنے کے بارے میں مزید](#terminology) + +کراؤڈن لغت اصطلاحات اور تعریفات کی وضاحت کے لیے بہترین جگہ ہے۔ لغت کا حوالہ دینے کے دو طریقے ہیں۔ + +- سب سے پہلے، جب آپ کو سورس اسٹرنگ پر ایک انڈر لائن شدہ اصطلاح ملتی ہے، تو آپ اس پر ماؤس کر سکتے ہیں اور اس کی مختصر تعریف دیکھ سکتے ہیں۔ + +![ایک مثال لغت کی تعریف](./glossary-definition.png) + +- دوسرا، اگر آپ کو کوئی ایسی اصطلاح نظر آتی ہے جس سے آپ واقف نہیں ہیں لیکن انڈر لائن نہیں ہے، تو آپ لغت ٹیب (دائیں کالم کا تیسرا بٹن) میں تلاش کر سکتے ہیں۔ آپ کو مخصوص اصطلاحات اور پروجیکٹ میں کثرت سے استعمال ہونے والی اصطلاحات کی وضاحتیں ملیں گی۔ + +![ایک اسکرین شاٹ جس میں دکھایا گیا ہے کہ کراؤڈن میں لغت ٹیب کہاں تلاش کرنا ہے۔](./glossary-tab.png) + +- اگر آپ کو اب بھی یہ نہیں ملتا ہے، تو یہ آپ کے لیے ایک نئی اصطلاح شامل کرنے کا موقع ہے! ہم آپ کی حوصلہ افزائی کرتے ہیں کہ اسے سرچ انجن پر تلاش کریں اور تفصیل کو لغت میں شامل کریں۔ اس سے دوسرے مترجمین کو اصطلاح کو بہتر طور پر سمجھنے میں بہت مدد ملے گی۔ + +![ایک اسکرین شاٹ جس میں دکھایا گیا ہے کہ کراؤڈن میں لغت کی اصطلاح کیسے شامل کی جائے۔](./add-glossary-term.png) + +### اصطلاحات کے ترجمے کی پالیسی {#terminology} + +_ناموں (برانڈز، کمپنیاں، لوگ) اور نئی تکنیکی اصطلاحات (Beacon Chain, shard chains, وغیرہ) کے لیے_ + +Ethereum بہت سی نئی اصطلاحات پیش کرتا ہے جو حال ہی میں وضع کی گئی ہیں۔ کچھ اصطلاحات مترجم سے مترجم میں مختلف ہوں گی کیونکہ ان کی متعلقہ زبان میں کوئی سرکاری ترجمہ نہیں ہے۔ اس طرح کی تضادات غلط فہمی کا باعث بن سکتی ہیں اور پڑھنے کی اہلیت کو کم کر سکتی ہیں۔ + +لسانی تنوع اور ہر زبان میں مختلف معیارات کی وجہ سے، ایک متحد اصطلاحات کے ترجمے کی پالیسی وضع کرنا تقریباً ناممکن ہو گیا ہے جسے تمام معاون زبانوں میں اپنایا جا سکے۔ + +غور و فکر کے بعد، ہم نے یہ فیصلہ کیا ہے کہ سب سے زیادہ استعمال ہونے والی اصطلاحات کو آپ، یعنی مترجمین، پر چھوڑ دیا جائے۔ + +جب آپ کو کوئی ایسی اصطلاح ملتی ہے جس سے آپ ناواقف ہیں تو ہم یہ تجویز کرتے ہیں: + +- [اصطلاحات کی لغت](#glossary) سے رجوع کریں، آپ کو معلوم ہو سکتا ہے کہ دوسرے مترجمین نے پہلے اس کا ترجمہ کیسے کیا ہے۔ اگر آپ کو لگتا ہے کہ پہلے ترجمہ شدہ اصطلاح مناسب نہیں ہے، تو بلا جھجھک کراؤڈن لغت میں ایک نئی اصطلاح شامل کرکے اپنے ترجمے کو بحال کریں۔ +- اگر اس طرح کا پچھلا ترجمہ لغت میں موجود نہیں ہے، تو ہم آپ کی حوصلہ افزائی کرتے ہیں کہ اسے کسی سرچ انجن یا میڈیا آرٹیکل پر تلاش کریں جو یہ دکھاتا ہو کہ یہ اصطلاح آپ کی کمیونٹی میں اصل میں کیسے استعمال ہوتی ہے۔ +- اگر آپ کو کوئی حوالہ نہیں ملتا ہے، تو بلا جھجھک اپنی بصیرت پر بھروسہ کریں اور اپنی زبان میں ایک نیا ترجمہ تجویز کریں! +- اگر آپ ایسا کرنے میں کم پراعتماد محسوس کرتے ہیں، تو اصطلاح کا ترجمہ نہ کریں۔ کبھی کبھی، انگریزی اصطلاحات درست تعریفیں فراہم کرنے کے لیے کافی سے زیادہ ہوتی ہیں۔ + +ہم تجویز کرتے ہیں کہ آپ برانڈز، کمپنیوں اور اہلکاروں کے ناموں کا ترجمہ نہ کریں کیونکہ ترجمہ غیر ضروری الجھن اور SEO مشکلات کا سبب بن سکتا ہے۔ + +## جائزے کا عمل کیسے کام کرتا ہے؟ {#review-process} + +اپنے ترجموں میں معیار اور مستقل مزاجی کی ایک خاص سطح کو یقینی بنانے کے لیے، ہم [Acolad](https://www.acolad.com/) کے ساتھ کام کرتے ہیں، جو عالمی سطح پر سب سے بڑے زبان کی خدمات فراہم کرنے والوں میں سے ایک ہے۔ Acolad کے پاس 20,000 پیشہ ور ماہر لسانیات ہیں، جس کا مطلب ہے کہ وہ ہر زبان اور مواد کی قسم کے لیے پیشہ ور جائزہ کار فراہم کر سکتے ہیں جن کی ہمیں ضرورت ہے۔ + +جائزے کا عمل سیدھا ہے؛ ایک بار جب مواد کا ایک سیٹ 100% ترجمہ ہو جاتا ہے، تو ہم اس مواد کی بالٹی کے لیے ایک جائزے کا آرڈر دیتے ہیں۔ جائزے کا عمل براہ راست کراؤڈن میں ہوتا ہے۔ جائزہ مکمل ہونے کے بعد، ہم ویب سائٹ کو ترجمہ شدہ مواد کے ساتھ اپ ڈیٹ کرتے ہیں۔ + +## میں اپنی زبان میں مواد کیسے شامل کروں؟ {#adding-foreign-language-content} + +فی الحال، تمام غیر انگریزی مواد کا براہ راست انگریزی سورس مواد سے ترجمہ کیا جاتا ہے، اور کوئی بھی مواد جو انگریزی میں موجود نہیں ہے اسے دوسری زبانوں میں شامل نہیں کیا جا سکتا ہے۔ + +ethereum.org کے لیے نیا مواد تجویز کرنے کے لیے، آپ GitHub پر [ایک مسئلہ بنا سکتے ہیں](https://github.com/ethereum/ethereum-org-website/issues)۔ اگر شامل کیا جاتا ہے، تو مواد انگریزی میں لکھا جائے گا اور کراؤڈن کا استعمال کرتے ہوئے دوسری زبانوں میں ترجمہ کیا جائے گا۔ + +ہم مستقبل قریب میں غیر انگریزی مواد کے اضافے کے لیے تعاون شامل کرنے کا ارادہ رکھتے ہیں۔ + +## رابطہ کریں {#contact} + +یہ سب پڑھنے کے لیے آپ کا شکریہ۔ ہمیں امید ہے کہ اس سے آپ کو ہمارے پروگرام میں شامل ہونے میں مدد ملے گی۔ سوالات پوچھنے اور دوسرے مترجمین کے ساتھ تعاون کرنے کے لیے بلا جھجھک ہمارے [Discord ترجمہ چینل](https://discord.gg/ethereum-org) میں شامل ہوں، یا ہم سے translations@ethereum.org پر رابطہ کریں! diff --git a/public/content/translations/ur/contributing/translation-program/how-to-translate/index.md b/public/content/translations/ur/contributing/translation-program/how-to-translate/index.md new file mode 100644 index 00000000000..e71271642e1 --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/how-to-translate/index.md @@ -0,0 +1,92 @@ +--- +title: "ترجمہ کیسے کریں" +lang: ur-in +description: "ethereum.org کا ترجمہ کرنے کے لیے Crowdin استعمال کرنے کی ہدایات" +--- + +# ترجمہ کیسے کریں {#how-to-translate} + +## بصری گائیڈ {#visual-guide} + +مزید بصری سیکھنے والوں کے لیے، لوکا کو دیکھیں کہ وہ Crowdin کے ساتھ کیسے سیٹ اپ کرتے ہیں۔ متبادل کے طور پر، آپ اگلے سیکشن میں تحریری شکل میں وہی مراحل تلاش کر سکتے ہیں۔ + + + +## تحریری گائیڈ {#written-guide} + +### Crowdin میں ہمارے پروجیکٹ میں شامل ہوں {#join-project} + +اگر آپ کے پاس پہلے سے Crowdin اکاؤنٹ نہیں ہے تو آپ کو اپنے Crowdin اکاؤنٹ میں لاگ ان کرنا ہوگا یا سائن اپ کرنا ہوگا۔ سائن اپ کرنے کے لیے صرف ایک ای-میل اکاؤنٹ اور پاس ورڈ کی ضرورت ہے۔ + + + پروجیکٹ میں شامل ہوں + + +### اپنی زبان کھولیں {#open-language} + +Crowdin میں لاگ ان کرنے کے بعد، آپ کو پروجیکٹ کی تفصیل اور تمام دستیاب زبانوں کی فہرست نظر آئے گی۔ +ہر زبان میں ترجمہ کے قابل الفاظ کی کل تعداد کے بارے میں معلومات اور اس بات کا جائزہ بھی ہوتا ہے کہ کسی مخصوص زبان میں کتنا مواد ترجمہ اور منظور کیا جا چکا ہے۔ + +ترجمے کے لیے دستیاب فائلوں کی فہرست دیکھنے کے لیے وہ زبان کھولیں جس میں آپ ترجمہ کرنا چاہتے ہیں۔ + +![Crowdin میں زبانوں کی فہرست](./list-of-languages.png) + +### کام کرنے کے لیے ایک دستاویز تلاش کریں {#find-document} + +ویب سائٹ کا مواد کئی دستاویزات اور کنٹینٹ بکیٹس میں تقسیم ہے۔ آپ دائیں جانب ہر دستاویز کی پیشرفت دیکھ سکتے ہیں – اگر ترجمے کی پیشرفت 100% سے کم ہے، تو براہ کرم تعاون کریں! + +اپنی زبان فہرست میں درج نہیں دیکھ رہے ہیں؟ [ایک مسئلہ کھولیں](https://github.com/ethereum/ethereum-org-website/issues/new/choose) یا ہمارے [Discord](https://discord.gg/ethereum-org) میں پوچھیں + +![Crowdin میں ترجمہ شدہ اور غیر ترجمہ شدہ فائلیں](./crowdin-files.png) + +کنٹینٹ بکیٹس پر ایک نوٹ: ہم سب سے زیادہ ترجیحی مواد کو پہلے جاری کرنے کے لیے Crowdin کے اندر 'کنٹینٹ بکیٹس' کا استعمال کرتے ہیں۔ جب آپ کسی زبان کو دیکھتے ہیں، مثال کے طور پر، [Filipino](https://crowdin.com/project/ethereum-org/fil#) تو آپ کو کنٹینٹ بکیٹ کے لیے فولڈر نظر آئیں گے ("1. ہوم پیج"، "2۔ ضروریات"، "3۔ ایکسپلورنگ"، وغیرہ)۔ + +ہم آپ کو اس عددی ترتیب (1 → 2 → 3 → ⋯) میں ترجمہ کرنے کی ترغیب دیتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ سب سے زیادہ اثر والے صفحات کا ترجمہ پہلے ہو۔ + +### ترجمہ کریں {#translate} + +جس فائل کا آپ ترجمہ کرنا چاہتے ہیں اسے منتخب کرنے کے بعد، یہ آن لائن ایڈیٹر میں کھل جائے گی۔ اگر آپ نے پہلے کبھی Crowdin استعمال نہیں کیا ہے، تو آپ بنیادی باتیں جاننے کے لیے اس فوری گائیڈ کا استعمال کر سکتے ہیں۔ + +![Crowdin آن لائن ایڈیٹر](./online-editor.png) + +**_1 – بایاں سائڈبار_** + +- غیر ترجمہ شدہ (سرخ) – وہ متن جس پر ابھی تک کام نہیں ہوا ہے۔ یہ وہ اسٹرنگز ہیں جن کا آپ کو ترجمہ کرنا چاہیے۔ +- ترجمہ شدہ (سبز) – وہ متن جس کا پہلے ہی ترجمہ ہو چکا ہے، لیکن ابھی تک اس کا جائزہ نہیں لیا گیا ہے۔ آپ متبادل ترجمے تجویز کرنے کے لیے آزاد ہیں، یا ایڈیٹر میں ''+'' اور ''-'' بٹنوں کا استعمال کرتے ہوئے موجودہ ترجموں پر ووٹ دے سکتے ہیں۔ +- منظور شدہ (چیک مارک) – وہ متن جس کا پہلے ہی جائزہ لیا جا چکا ہے اور فی الحال ویب سائٹ پر لائیو ہے۔ + +آپ مخصوص اسٹرنگز تلاش کرنے، انہیں اسٹیٹس کے لحاظ سے فلٹر کرنے یا منظر کو تبدیل کرنے کے لیے اوپر والے بٹنوں کا بھی استعمال کر سکتے ہیں۔ + +**_2 – ایڈیٹر ایریا_** + +مرکزی ترجمہ کا علاقہ – سورس متن سب سے اوپر دکھایا جاتا ہے، اضافی سیاق و سباق اور اسکرین شاٹس کے ساتھ، اگر دستیاب ہوں۔ +نیا ترجمہ تجویز کرنے کے لیے، اپنا ترجمہ ''یہاں ترجمہ درج کریں'' فیلڈ میں درج کریں اور محفوظ کریں پر کلک کریں۔ + +آپ اس سیکشن میں اسٹرنگ کے موجودہ تراجم اور دیگر زبانوں میں ترجمے، نیز ٹرانسلیشن میموری میچز اور مشین ٹرانسلیشن کی تجاویز بھی تلاش کر سکتے ہیں۔ + +**_3 – دایاں سائڈبار_** + +یہ وہ جگہ ہے جہاں آپ تبصرے، ٹرانسلیشن میموری اندراجات اور لغت کے اندراجات تلاش کر سکتے ہیں۔ ڈیفالٹ منظر تبصرے دکھاتا ہے اور مترجمین کو بات چیت کرنے، مسائل اٹھانے یا غلط ترجمے کی اطلاع دینے کی اجازت دیتا ہے۔ + +اوپر والے بٹنوں کا استعمال کرکے، آپ ٹرانسلیشن میموری پر بھی جا سکتے ہیں، جہاں آپ موجودہ ترجمے تلاش کر سکتے ہیں، یا لغت پر جا سکتے ہیں، جس میں کلیدی اصطلاحات کی تفصیل اور معیاری ترجمے شامل ہیں۔ + +مزید جاننا چاہتے ہیں؟ بلا جھجھک [Crowdin آن لائن ایڈیٹر استعمال کرنے پر دستاویزات](https://support.crowdin.com/online-editor/) دیکھیں۔ + +### جائزے کا عمل {#review-process} + +ایک بار جب آپ ترجمہ مکمل کر لیتے ہیں (یعنی، ایک کنٹینٹ بکیٹ کی تمام فائلیں 100% دکھاتی ہیں)، تو ہماری پیشہ ورانہ ترجمہ کی سروس مواد کا جائزہ لے گی (اور ممکنہ طور پر اس میں ترمیم کرے گی)۔ ایک بار جائزہ مکمل ہونے کے بعد (یعنی، جائزے کی پیشرفت 100% ہے)، ہم اسے ویب سائٹ پر شامل کر دیں گے۔ + + + + + براہ کرم پروجیکٹ کا ترجمہ کرنے کے لیے مشین ٹرانسلیشن کا استعمال نہ کریں۔ ویب سائٹ میں شامل کرنے سے پہلے تمام ترجموں کا جائزہ لیا جائے گا۔ اگر آپ کے تجویز کردہ ترجمے مشین سے ترجمہ شدہ پائے جاتے ہیں، تو انہیں مسترد کر دیا جائے گا اور جو معاونین اکثر مشین ٹرانسلیشن کا استعمال کرتے ہیں انہیں پروجیکٹ سے ہٹا دیا جائے گا۔ + + + +### رابطہ کریں {#get-in-touch} + +کیا آپ کے کوئی سوالات ہیں؟ یا ہماری ٹیم اور دیگر مترجمین کے ساتھ تعاون کرنا چاہتے ہیں؟ براہ کرم ہمارے [ethereum.org Discord سرور](https://discord.gg/ethereum-org) کے #translations چینل میں پوسٹ کریں + +آپ ہم سے translations@ethereum.org پر بھی رابطہ کر سکتے ہیں + +ethereum.org ترجمہ پروگرام میں آپ کی شرکت کا شکریہ! diff --git a/public/content/translations/ur/contributing/translation-program/index.md b/public/content/translations/ur/contributing/translation-program/index.md new file mode 100644 index 00000000000..35169c6a735 --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/index.md @@ -0,0 +1,91 @@ +--- +title: "ترجمہ پروگرام" +lang: ur-in +description: "ethereum.org ترجمہ پروگرام کے بارے میں معلومات" +--- + +# ترجمہ پروگرام {#translation-program} + +ترجمہ پروگرام ایک مشترکہ کوشش ہے جس کا مقصد ethereum.org کا مختلف زبانوں میں ترجمہ کرنا ہے تاکہ دنیا بھر کے اربوں غیر انگریزی بولنے والوں کے لیے ویب سائٹ کو مزید قابل رسائی بنایا جا سکے۔ + +![](./enterprise-eth.png) + +## ترجمہ کرنے میں ہماری مدد کریں {#help-us-translate} + +ethereum.org ترجمہ پروگرام کھلا ہے اور کوئی بھی اس میں تعاون کر سکتا ہے! + +1. آپ کو اپنے Crowdin اکاؤنٹ میں لاگ ان کرنا ہوگا یا سائن اپ کرنا ہوگا۔ +2. وہ زبان منتخب کریں جس میں آپ تعاون کرنا چاہتے ہیں۔ +3. شروع کرنے سے پہلے، براہ کرم Crowdin کا استعمال سیکھنے کے لیے [ترجمہ کیسے کریں](/contributing/translation-program/how-to-translate/) گائیڈ، اور تجاویز اور بہترین طریقوں کے لیے [ترجمہ اسٹائل گائیڈ](/contributing/translation-program/translators-guide/) دیکھیں۔ +4. مشینی ترجمے منظور نہیں کیے جائیں گے۔ +5. تمام ترجموں کا سائٹ پر شامل کرنے سے پہلے جائزہ لیا جاتا ہے، اس لیے آپ کے ترجمے لائیو ہونے سے پہلے تھوڑی تاخیر ہوگی۔ + +_ترجمے پر تعاون کرنے، سوالات پوچھنے، فیڈ بیک اور خیالات کا اشتراک کرنے، یا ترجمہ گروپ میں شامل ہونے کے لیے [ethereum.org Discord](https://discord.gg/ethereum-org) میں شامل ہوں۔_ + + + ترجمہ شروع کریں + + +## ترجمہ پروگرام کے بارے میں {#about-us} + +Ethereum کمیونٹی کا مقصد عالمی اور جامع ہونا ہے، پھر بھی اس کا زیادہ تر مواد صرف انگریزی بولنے والوں کے لیے ہے، جس سے دنیا کے 6 ارب غیر انگریزی بولنے والے محروم رہ جاتے ہیں۔ دنیا بھر کی کمیونٹی کے لیے Ethereum کے پورٹل کے طور پر کام کرنے کے لیے ethereum.org کے لیے، ہم سمجھتے ہیں کہ غیر انگریزی بولنے والوں کو ان کی مادری زبانوں میں Ethereum مواد فراہم کرنا ضروری ہے۔ + +ethereum.org ترجمہ پروگرام کا مقصد ethereum.org اور دیگر Ethereum مواد کا زیادہ سے زیادہ زبانوں میں ترجمہ کرکے Ethereum کو سب کے لیے قابل رسائی بنانا ہے۔ + +ethereum.org ترجمہ پروگرام کے [مشن اور وژن](/contributing/translation-program/mission-and-vision) کے بارے میں مزید پڑھیں۔ + +### اب تک کی ہماری پیشرفت {#our-progress} + +- [**6,900 +** مترجمین](/contributing/translation-program/contributors/) +- **68** زبانیں سائٹ پر لائیو ہیں +- [**2.89 ملین** الفاظ 2024 میں ترجمہ کیے گئے](/contributing/translation-program/acknowledgements/) + + + +### اعترافات {#acknowledgements} + +Ethereum.org کا ترجمہ ہزاروں کمیونٹی ممبران کرتے ہیں اور وہ ترجمہ پروگرام کا کلیدی حصہ ہیں۔ +ہم اپنے مترجمین کو تسلیم کرنا چاہتے ہیں اور ان کے کیریئر کے راستوں پر ان کی حمایت کرنا چاہتے ہیں۔ یہاں ہمارے مترجمین کے کچھ اعترافات ہیں: + +#### سرٹیفکیٹ {#certificate} + +اگر آپ نے ترجمہ پروگرام میں تعاون کیا ہے اور آپ کے کم از کم 5,000 ترجمہ شدہ الفاظ منظور ہو چکے ہیں، تو آپ ethereum.org مترجم سرٹیفکیٹ کے اہل ہیں۔ [سرٹیفکیٹس کے بارے میں مزید](/contributing/translation-program/acknowledgements/#certificate) + +#### OATs {#oats} + +ترجمہ پروگرام میں تعاون کرنے والے 2024 میں ان کے ترجمہ شدہ الفاظ کی تعداد کی بنیاد پر مختلف OATs (آن چین اچیومنٹ ٹوکنز) کے اہل ہیں۔ OATs وہ NFTs ہیں جو ethereum.org ترجمہ پروگرام میں آپ کے تعاون کو ثابت کرتے ہیں۔ [OATs کے بارے میں مزید](/contributing/translation-program/acknowledgements/#oats) + +#### مترجم کے اعترافات {#translator-acknowledgements} + +[لیڈر بورڈز](/contributing/translation-program/acknowledgements/) اور [ترجمہ پروگرام میں تمام تعاون کرنے والوں کی فہرست](/contributing/translation-program/contributors/) کا استعمال کرتے ہوئے ہمارے سرفہرست مترجمین کا عوامی اعتراف۔ + +#### انعامات {#rewards} + +ماضی میں، ہم نے اپنے سب سے فعال تعاون کرنے والوں کو [Devcon](https://devcon.org/en/) اور [Devconnect](https://devconnect.org/) جیسی Ethereum کانفرنسوں کے ٹکٹوں کے ساتھ ساتھ خصوصی ethereum.org مرچ کے ساتھ سابقہ طور پر انعام دیا ہے۔ + +ہم اپنے تعاون کرنے والوں کو انعام دینے کے نئے اور جدید طریقوں کے بارے میں مسلسل سوچ رہے ہیں، لہذا ہمارے ساتھ جڑے رہیں! + +### رہنما اور وسائل {#guides-and-resources} + +اگر آپ ترجمہ پروگرام میں تعاون کر رہے ہیں یا اس میں شامل ہونے کے بارے میں سوچ رہے ہیں، تو آپ کو نیچے دیے گئے ترجمہ گائیڈز کو دیکھنا چاہیے: + +- [ترجمہ اسٹائل گائیڈ](/contributing/translation-program/translators-guide/) _– ethereum.org کے مترجمین کے لیے ہدایات اور تجاویز_ +- [ترجمہ کے عمومی سوالات](/contributing/translation-program/faq/) _– ethereum.org ترجمہ پروگرام کے بارے میں اکثر پوچھے جانے والے سوالات اور جوابات_ +- [Crowdin آن لائن ایڈیٹر گائیڈ](https://support.crowdin.com/online-editor/) _– Crowdin آن لائن ایڈیٹر اور Crowdin کی کچھ جدید خصوصیات کو استعمال کرنے کے لیے ایک گہرائی سے گائیڈ_ + +دیگر مفید ترجمہ ٹولز، مترجم کمیونٹیز اور ترجمہ پروگرام کے بلاگ پوسٹس کے لیے، براہ کرم [وسائل کا صفحہ](/contributing/translation-program/resources/) دیکھیں۔ + +## رابطہ کریں {#get-in-touch} + +کیا آپ کے کوئی سوالات ہیں؟ یا ہماری ٹیم اور دیگر مترجمین کے ساتھ تعاون کرنا چاہتے ہیں؟ براہ کرم ہمارے [ethereum.org Discord سرور](https://discord.gg/ethereum-org) کے #translations چینل میں پوسٹ کریں + +آپ ہم سے translations@ethereum.org پر بھی رابطہ کر سکتے ہیں + +## اپنا ترجمہ پروگرام شروع کرنا {#starting-a-translation-program} + +ہم Ethereum مواد کا زیادہ سے زیادہ زبانوں میں ترجمہ کرنے اور تعلیمی مواد کو سب کے لیے دستیاب بنانے کے لیے وقف ہیں۔ +ترجمے پر ہماری توجہ کے مطابق، ہم دیگر Ethereum پروجیکٹس کو ان کی اپنی ترجمہ کی کوششوں کو منظم کرنے، ان کا انتظام کرنے اور بہتر بنانے میں مدد کرنا چاہتے ہیں۔ + +اس وجہ سے، ہم نے ایک [ترجمہ پروگرام پلے بک](/contributing/translation-program/playbook/) بنائی ہے جس میں کچھ تجاویز اور بہترین طریقے شامل ہیں جو ہم نے ethereum.org کا ترجمہ کرنے کے عمل میں حاصل کیے ہیں۔ + +مزید تعاون کرنا چاہتے ہیں یا ہمارے کچھ ترجمے کے وسائل استعمال کرنا چاہتے ہیں؟ پلے بک پر کوئی رائے ہے؟ ہم آپ سے translations@ethereum.org پر سننا پسند کریں گے۔ diff --git a/public/content/translations/ur/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/ur/contributing/translation-program/mission-and-vision/index.md new file mode 100644 index 00000000000..4dfe971299e --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/mission-and-vision/index.md @@ -0,0 +1,25 @@ +--- +title: "مشن اور وژن" +lang: ur-in +description: "ethereum.org ترجمہ پروگرام کا مشن اور وژن" +--- + +# مشن اور وژن {#mission-and-vision} + +Ethereum کمیونٹی کا مقصد عالمی اور جامع ہونا ہے، پھر بھی اس کا زیادہ تر مواد صرف انگریزی بولنے والوں کے لیے ہے، جس سے دنیا کے 6 ارب غیر انگریزی بولنے والے محروم رہ جاتے ہیں۔ دنیا بھر کی کمیونٹی کے لیے Ethereum کے پورٹل کے طور پر کام کرنے کے لیے ethereum.org کے لیے، ہم سمجھتے ہیں کہ غیر انگریزی بولنے والوں کو ان کی مادری زبانوں میں Ethereum مواد فراہم کرنا ضروری ہے۔ + +ethereum.org ترجمہ پروگرام کا مقصد ethereum.org اور دیگر Ethereum مواد کا زیادہ سے زیادہ زبانوں میں ترجمہ کرکے Ethereum کو سب کے لیے قابل رسائی بنانا ہے۔ + +## ہمارا مشن {#our-mission} + +- دنیا بھر کے وزیٹرز کو اپنی مادری زبان میں Ethereum کے بارے میں جاننے کے لیے بااختیار بنانے کی غرض سے ویب سائٹ کے ترجمہ شدہ ورژنز فراہم کرنا۔ +- عالمی Ethereum کمیونٹی میں مزید ممبران کی آن بورڈنگ میں سہولت فراہم کرنا۔ +- Ethereum کی معلومات اور علم کے زیادہ قابل رسائی اور جامع اشتراک کو ممکن بنانا۔ +- کمیونٹی کے ممبران کو بااختیار بنانا کہ وہ Ethereum میں ترجمے کا حصہ ڈالیں اور ایکو سسٹم پر اپنی شناخت قائم کریں۔ +- ایکو سسٹم میں شامل ہونے کے خواہشمند پرجوش شراکت داروں کی شناخت کرنا، ان سے رابطہ کرنا، اور انہیں رہنمائی فراہم کرنا۔ + +## ہمارا وژن {#our-vision} + +- دنیا کے زیادہ سے زیادہ ممالک اور حصوں سے Ethereum کمیونٹی کے ممبران کے لیے ضروری مواد کا ترجمہ کرنا۔ +- ایک بہتر باخبر اور تعلیم یافتہ Ethereum کمیونٹی بنانے کے لیے زبانوں میں علم کے اشتراک کی حمایت کرنا۔ +- لسانی رکاوٹوں کو دور کرکے Ethereum کی جامعیت اور رسائی کو بڑھانا جو غیر انگریزی بولنے والوں کو ایکو سسٹم میں شامل ہونے سے روکتی ہیں۔ diff --git a/public/content/translations/ur/contributing/translation-program/playbook/index.md b/public/content/translations/ur/contributing/translation-program/playbook/index.md new file mode 100644 index 00000000000..5e403080b03 --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/playbook/index.md @@ -0,0 +1,317 @@ +--- +title: "ترجمہ پروگرام پلے بک" +lang: ur-in +description: "ترجمہ پروگرام ترتیب دینے کے لیے تجاویز اور اہم غور و خوض کا مجموعہ" +--- + +# ترجمہ پروگرام پلے بک {#translation-program-playbook} + +انگریزی دنیا میں سب سے زیادہ بولی جانے والی زبانوں میں سے ایک ہے اور اب تک دنیا کی سب سے زیادہ پڑھی جانے والی زبان ہے۔ چونکہ انٹرنیٹ پر استعمال ہونے والی سب سے عام زبان انگریزی ہے - خاص طور پر سوشل میڈیا پر - اور کثیر لسانی پروگرامنگ زبانیں بہت کم ہیں، بلاک چین اسپیس میں زیادہ تر مواد مقامی طور پر انگریزی میں لکھا جاتا ہے۔ + +تاہم، چونکہ دنیا میں 6 بلین سے زیادہ لوگ (آبادی کا 75 فیصد سے زیادہ) بالکل بھی انگریزی نہیں بولتے ہیں، یہ دنیا کی آبادی کی بڑی اکثریت کے لیے Ethereum میں داخلے کے لیے ایک بہت بڑی رکاوٹ ہے۔ + +اسی وجہ سے، اس شعبے میں پروجیکٹس کی بڑھتی ہوئی تعداد اپنے مواد کو مختلف زبانوں میں ترجمہ کرانے اور عالمی برادریوں کے لیے مقامی بنانے کی کوشش کر رہی ہے۔ + +کثیر لسانی مواد فراہم کرنا آپ کی عالمی برادری کو بڑھانے، غیر انگریزی بولنے والوں کو تعلیم فراہم کرنے، اس بات کو یقینی بنانے کا ایک آسان اور موثر طریقہ ہے کہ آپ کا مواد اور مواصلات وسیع تر سامعین تک پہنچیں، اور اس جگہ پر مزید لوگوں کو شامل کریں۔ + +اس گائیڈ کا مقصد مواد کی لوکلائزیشن کے بارے میں عام چیلنجوں اور غلط فہمیوں کو دور کرنا ہے۔ یہ مواد کے انتظام، ترجمہ اور جائزہ کے عمل، کوالٹی اشورینس، مترجم تک رسائی، اور لوکلائزیشن کے عمل کے دیگر اہم پہلوؤں کے لیے مرحلہ وار گائیڈ فراہم کرتا ہے۔ + +## مواد کا انتظام {#content-management} + +ترجمہ مواد کا انتظام ترجمہ کے ورک فلو کو خودکار بنانے کے عمل سے مراد ہے، جو بار بار دستی کام کی ضرورت کو دور کرتا ہے، کارکردگی اور معیار کو بہتر بناتا ہے، بہتر کنٹرول کی اجازت دیتا ہے، اور تعاون کو قابل بناتا ہے۔ + +لوکلائزیشن کے عمل میں مواد کے انتظام کے بہت سے مختلف طریقے ہیں، جو مواد اور آپ کی ضروریات پر منحصر ہیں۔ + +مواد کے انتظام کا بنیادی طریقہ دو لسانی فائلیں بنانا ہے، جس میں ماخذ اور ہدف متن شامل ہو۔ یہ ترجمہ میں شاذ و نادر ہی استعمال ہوتا ہے، کیونکہ یہ سادگی کے علاوہ کوئی خاص فوائد پیش نہیں کرتا ہے۔ + +ترجمہ ایجنسیاں عام طور پر ترجمہ کے انتظام کے لیے ترجمہ مینجمنٹ سوفٹ ویئر یا لوکلائزیشن ٹولز کا استعمال کرتی ہیں، جو پروجیکٹ مینجمنٹ کی صلاحیتیں فراہم کرتی ہیں اور فائلوں، مواد اور ماہرین لسانیات پر زیادہ کنٹرول کی اجازت دیتی ہیں۔ + +مواد کے انتظام کے بارے میں مزید پڑھیں: + +[Trados پر ترجمہ کا انتظام کیا ہے](https://www.trados.com/solutions/translation-management/) + +[کثیر لسانی مواد کے انتظام پر Phrase](https://phrase.com/blog/posts/multilingual-content-management/) + +### ترجمہ مینجمنٹ سوفٹ ویئر {#translation-management-software} + +بہت سے ترجمہ کے انتظام کے نظام اور لوکلائزیشن ٹولز ہیں، اور سافٹ ویئر کا انتخاب بنیادی طور پر آپ کی ضروریات پر منحصر ہے۔ + +جبکہ کچھ پروجیکٹس ترجمہ کے انتظام کے نظام کو استعمال کرنے کے خلاف فیصلہ کرتے ہیں اور ترجمے کو دستی طور پر ہینڈل کرنے کو ترجیح دیتے ہیں - یا تو براہ راست دو لسانی فائلوں میں یا ہوسٹنگ سروسز، جیسے GitHub پر - یہ کنٹرول، پیداواریت، معیار، اسکیل ایبلٹی، اور تعاون کی صلاحیتوں کو ڈرامائی طور پر کم کرتا ہے۔ اس طرح کا نقطہ نظر چھوٹے پیمانے پر یا ایک بار کے ترجمے کے منصوبوں کے لیے سب سے زیادہ فائدہ مند ہو سکتا ہے۔ + +کچھ سب سے زیادہ طاقتور اور وسیع پیمانے پر استعمال ہونے والے ترجمہ مینجمنٹ ٹولز پر ایک فوری نظر: + +**کراؤڈ سورسنگ اور تعاون کے لیے بہترین** + +[Crowdin](https://crowdin.com/) + +- اوپن سورس پروجیکٹس کے لیے مفت (سٹرنگز اور پروجیکٹس کی لامحدود تعداد) +- TM اور لغت تمام منصوبوں کے ساتھ دستیاب ہیں۔ +- 60+ معاون فائل فارمیٹس، 70+ API انضمام + +[Lokalise](https://lokalise.com/) + +- 2 ٹیم ممبران کے لیے مفت، مزید شراکت داروں کے لیے بامعاوضہ منصوبے (زیادہ تر منصوبوں کے لیے سٹرنگز کی محدود تعداد) +- TM اور لغت کچھ بامعاوضہ منصوبوں کے ساتھ دستیاب ہیں۔ +- 30+ معاون فائل فارمیٹس، 40+ API انضمام + +[Transifex](https://www.transifex.com/) + +- صرف بامعاوضہ منصوبے (زیادہ تر منصوبوں کے لیے سٹرنگز کی محدود تعداد) +- TM اور لغت تمام بامعاوضہ منصوبوں کے ساتھ دستیاب ہیں۔ +- 30+ معاون فائل فارمیٹس، 20+ API انضمام + +[Phrase](https://phrase.com/) + +- صرف بامعاوضہ منصوبے (تمام منصوبوں کے لیے سٹرنگز کی لامحدود تعداد، منصوبوں اور ٹیم ممبران کی محدود تعداد) +- TM اور لغت کچھ بامعاوضہ منصوبوں کے ساتھ دستیاب ہیں۔ +- 40+ معاون فائل فارمیٹس، 20+ API انضمام + +[Smartcat](https://www.smartcat.com/) + +- قابل ادائیگی جدید خصوصیات کے ساتھ بنیادی مفت منصوبہ (تمام منصوبوں کے لیے سٹرنگز اور پروجیکٹس کی لامحدود تعداد) +- TM اور لغت تمام منصوبوں کے ساتھ دستیاب ہیں۔ +- 60+ معاون فائل فارمیٹس، 20+ API انضمام + +[POEditor](https://poeditor.com/) + +- اوپن سورس پروجیکٹس کے لیے مفت (تمام پروجیکٹس کے لیے سٹرنگز کی محدود تعداد، اوپن سورس پروجیکٹس کے لیے لامحدود) +- TM اور لغت بامعاوضہ منصوبوں کے لیے دستیاب ہیں۔ +- 20+ معاون فائل فارمیٹس، 10+ API انضمام + +اور بہت کچھ ... + +**پیشہ ورانہ ترجمہ کے اوزار** + +[SDL Trados Studio](https://www.trados.com/products/trados-studio/) + +- فری لانس مترجمین اور ٹیموں کے لیے بامعاوضہ منصوبے +- بہت طاقتور کمپیوٹر کی مدد سے ترجمہ (CAT) ٹول اور مترجم کی پیداواریت کا سافٹ ویئر + +[MemoQ](https://www.memoq.com/) + +- جدید خصوصیات کے لیے کئی بامعاوضہ منصوبوں کے ساتھ محدود مفت ورژن دستیاب ہے۔ +- کمپنیوں، زبان کی خدمت فراہم کرنے والوں اور مترجمین کے لیے ترجمہ مینجمنٹ سوفٹ ویئر + +[Memsource](https://www.memsource.com/) + +- انفرادی مترجمین کے لیے مفت اور ٹیموں کے لیے کئی بامعاوضہ منصوبے +- کلاؤڈ پر مبنی کمپیوٹر کی مدد سے ترجمہ اور ترجمہ کا انتظام کا نظام + +اور بہت کچھ ... + +ترجمہ مینجمنٹ سوفٹ ویئر کے بارے میں مزید پڑھیں: + +[ترجمہ کے انتظام کے نظام کی Wikipedia تعریف](https://en.wikipedia.org/wiki/Translation_management_system) + +[Phrase پر 7 چیزیں جو ہر ترجمہ مینجمنٹ سوفٹ ویئر میں ہونی چاہئیں](https://phrase.com/blog/posts/7-things-every-translation-management-software-should-have/) + +[MemoQ پر ترجمہ کا انتظام کا نظام کیا ہے](https://www.memoq.com/tools/what-is-a-translation-management-system) + +[Gengo کی 16 بہترین ترجمہ کے انتظام کے نظام کی فہرست](https://gengo.com/translator-product-updates/16-best-translation-management-systems/) + +## ورک فلو {#workflow} + +ترجمے کی جگہ میں، ترجمہ کے ورک فلو کا مطلب کچھ مختلف چیزیں ہوسکتی ہیں، دونوں کسی حد تک ایک دوسرے سے جڑے ہوئے ہیں، اور آپ کے پروجیکٹ کے لیے اہم غور و خوض۔ + +ہم ذیل میں ان دونوں کو دریافت کریں گے۔ + +**معنی 1** + +یہ شاید ترجمہ کے ورک فلو کے بارے میں سوچنے کا سب سے عام طریقہ ہے اور کچھ ایسا ہے جو عام طور پر ورک فلو کا لفظ سن کر ذہن میں آتا ہے۔ + +اس کے جوہر میں، یہ ترجمے کے بارے میں سوچنے سے لے کر اپنے پروڈکٹ میں ترجمہ شدہ مواد کو استعمال کرنے تک 'کام کا بہاؤ' ہے۔ + +اس معاملے میں ایک مثال کا ورک فلو یہ ہوگا: + +1. **ترجمے کے لیے فائلیں تیار کرنا** – یہ سادہ لگتا ہے؛ تاہم، آپ کو کچھ اہم چیزوں پر غور کرنے کی ضرورت ہے۔ اس مرحلے پر، آپ کے پاس ایک واضح منصوبہ ہونا چاہیے کہ پورا عمل کیسے کام کرنا چاہیے۔ + +- _آپ کونسی فائل کی اقسام استعمال کریں گے؟_ آپ اپنی ترجمہ شدہ فائلیں کس فارمیٹ میں وصول کرنا چاہتے ہیں؟_ + - اگر آپ کا مواد DOCX یا MD فارمیٹ میں دستیاب ہے، تو یہ طریقہ اس سے کہیں زیادہ سیدھا ہوگا اگر آپ اپنے وائٹ پیپر یا دیگر دستاویزات کے PDF ورژن کا ترجمہ کر رہے ہیں۔ +- _کون سے لوکلائزیشن ٹولز اس فائل کی قسم کو سپورٹ کرتے ہیں؟_ کیا فائل کا اس طرح ترجمہ کیا جا سکتا ہے کہ اصل فارمیٹنگ برقرار رہے؟_ + - تمام فائل کی اقسام براہ راست لوکلائزیشن (مثلاً، PDF فائلیں، تصویری فائلیں) کو سپورٹ نہیں کرتی ہیں، اور تمام لوکلائزیشن ٹولز تمام فائل کی اقسام کو سپورٹ نہیں کرتے ہیں۔ +- _مواد کا ترجمہ کون کرے گا؟_ کیا آپ پیشہ ورانہ ترجمے کا آرڈر دیں گے یا رضاکاروں پر بھروسہ کریں گے؟_ + - یہ آپ کو کرنے کی ضرورت کے بہت سے دوسرے فیصلوں کو متاثر کرتا ہے۔ مثال کے طور پر، پیشہ ور مترجم رضاکاروں کے مقابلے میں جدید لوکلائزیشن ٹولز کے ساتھ کام کرنے میں زیادہ آرام دہ ہیں۔ +- _ماہرین لسانیات کے لیے آپ کی کیا توقعات ہیں؟_ اگر آپ زبان کی خدمت فراہم کرنے والے کا استعمال کر رہے ہیں، تو وہ آپ سے کیا توقع رکھتے ہیں؟_ + - یہ اس بات کو یقینی بنانے کا مرحلہ ہے کہ آپ کے اہداف، توقعات، اور ٹائم لائنز ہم آہنگ ہیں۔ +- _کیا ترجمے کے لیے تمام مواد یکساں طور پر اہم ہے؟_ کیا کچھ مواد کا پہلے ترجمہ کیا جانا چاہئے؟_ + - کچھ مواد کو ترجیح دینے کے کچھ طریقے ہیں، جن کا پہلے ترجمہ اور عمل درآمد کیا جانا چاہیے۔ مثال کے طور پر، اگر آپ کے پاس ترجمے کے لیے بہت زیادہ مواد ہے، تو آپ ورژن کنٹرول کا استعمال اس بات کو یقینی بنانے کے لیے کر سکتے ہیں کہ مترجمین کو معلوم ہو کہ انہیں کس کو ترجیح دینی چاہیے۔ + +2. **ترجمے کے لیے فائلیں بانٹنا** - اس قدم کے لیے بھی کچھ طویل مدتی سوچ کی ضرورت ہے اور یہ اتنا سیدھا نہیں ہے جتنا کہ کسی زبان کی خدمت فراہم کرنے والے کو سورس فائلیں بھیجنا۔ + +- _مواد کا ترجمہ کون کرے گا؟_ اس عمل میں کتنے لوگ شامل ہوں گے؟_ + - اگر آپ لوکلائزیشن ٹول استعمال کرنے کا ارادہ رکھتے ہیں، تو یہ قدم آسان ہوجاتا ہے کیونکہ آپ سورس فائلوں کو براہ راست ٹول پر اپ لوڈ کرسکتے ہیں۔ یہ بھی سچ ہے اگر ترجمہ کا عمل ہوسٹنگ سروس پر ہوتا ہے کیونکہ سورس فائلوں کو کہیں بھی ایکسپورٹ کرنے کی ضرورت نہیں ہے۔ +- _کیا سورس فائلوں کو دستی طور پر ہینڈل کیا جائے گا، یا اس عمل کو خودکار کیا جا سکتا ہے؟_ + - زیادہ تر لوکلائزیشن ٹولز فائل مینجمنٹ کے عمل کی کچھ قسم کے انضمام یا آٹومیشن کی اجازت دیتے ہیں۔ دوسری طرف، اگر آپ انفرادی مترجمین کے ساتھ کام کر رہے ہیں اور لوکلائزیشن ٹول استعمال نہیں کر رہے ہیں، تو سینکڑوں یا ہزاروں مترجمین کو دستی طور پر سورس فائلیں بھیجنا ایک اسکیل ایبل عمل نہیں ہے۔ +- _لوکلائزیشن کے لیے کون سے اوزار استعمال کیے جائیں گے؟_ + - اس سوال کا جواب اس بات کا تعین کرے گا کہ آپ باقی سب کچھ کیسے کرتے ہیں۔ مناسب ٹول کا انتخاب آپ کو مواد کے انتظام کو خودکار کرنے، ترجمہ میموری اور لغت کا انتظام کرنے، مترجمین کا انتظام کرنے، ترجمہ/جائزہ کی پیشرفت کا سراغ لگانے وغیرہ میں مدد کرسکتا ہے، لہذا کچھ وقت نکالیں اور کچھ تحقیق کریں کہ آپ کون سا ٹول استعمال کرنا چاہتے ہیں۔ اگر آپ لوکلائزیشن ٹول استعمال کرنے کا ارادہ نہیں کر رہے ہیں، تو مندرجہ بالا سب کچھ دستی طور پر کرنا ہوگا۔ +- _ترجمہ کے عمل میں کتنا وقت لگے گا؟_ اس پر کتنا خرچ آئے گا؟_ + - اس وقت، آپ کو زبان کی خدمت فراہم کرنے والے یا مترجمین کے پول کے ساتھ سورس فائلیں بانٹنے کے لیے تیار رہنا چاہیے۔ زبان کی خدمت فراہم کرنے والا آپ کو الفاظ کی گنتی کا تجزیہ کرنے اور ایک اقتباس فراہم کرنے میں مدد کرسکتا ہے، بشمول ترجمہ کے عمل کے لیے شرحیں اور ٹائم لائن۔ +- _کیا آپ اس عمل کے دوران سورس مواد میں تبدیلیاں/اپ ڈیٹ کرنے کا منصوبہ بنا رہے ہیں؟_ + - اگر آپ کا مواد متحرک ہے اور اکثر بدلتا رہتا ہے، تو کوئی بھی تبدیلی یا اپ ڈیٹ ترجمہ کی پیشرفت میں خلل ڈال سکتا ہے۔ ترجمہ میموری کا استعمال اس کو نمایاں طور پر کم کرنے میں مدد کرسکتا ہے، حالانکہ یہ سوچنا اب بھی اہم ہے کہ یہ عمل کیسے کام کرے گا اور آپ مترجمین کی پیشرفت کو واپس کرنے سے کیسے روک سکتے ہیں۔ + +3. **ترجمہ کے عمل کا انتظام کرنا** – جب سورس مواد زبان کی خدمت فراہم کرنے والے یا مترجمین کو سونپ دیا جاتا ہے تو آپ کا کام ختم نہیں ہوتا ہے۔ ترجمے کے بہترین معیار کو یقینی بنانے کے لیے، مواد کے تخلیق کاروں کو ترجمے کے عمل میں زیادہ سے زیادہ شامل ہونا چاہیے۔ + +- _آپ مترجمین کے ساتھ بات چیت کرنے کا کیا منصوبہ بنا رہے ہیں؟_ + - اگر آپ لوکلائزیشن ٹول استعمال کرنے کا ارادہ کر رہے ہیں، تو مواصلات براہ راست ٹول میں ہوسکتی ہے۔ مترجمین کے ساتھ ایک متبادل مواصلاتی چینل قائم کرنے کی بھی سفارش کی جاتی ہے کیونکہ وہ رابطہ کرنے میں کم ہچکچاہٹ محسوس کرسکتے ہیں، اور میسجنگ ٹولز زیادہ آزادانہ مواصلات کی اجازت دیتے ہیں۔ +- _مترجمین کے سوالات کو کیسے ہینڈل کیا جائے؟_ ان سوالات کا جواب کون دے گا؟_ + - مترجمین (پیشہ ور اور غیر پیشہ ور دونوں) اکثر وضاحت یا اضافی سیاق و سباق کے لیے سوالات اور درخواستوں کے ساتھ ساتھ بہتری کے لیے فیڈ بیک اور خیالات کے ساتھ رابطہ کریں گے۔ ان پوچھ گچھ کا جواب دینے سے اکثر ترجمہ شدہ مواد کی بہتر مشغولیت اور معیار پیدا ہوسکتا ہے۔ انہیں زیادہ سے زیادہ وسائل فراہم کرنا بھی قابل قدر ہے (مثلاً، گائیڈز، ٹپس، اصطلاحات کے رہنما خطوط، FAQs، وغیرہ)۔ +- _جائزے کے عمل کو کیسے ہینڈل کیا جائے؟_ کیا آپ اسے آؤٹ سورس کرنا چاہتے ہیں، یا کیا آپ کے پاس اندرونی طور پر جائزے کرنے کی صلاحیت ہے؟_ + - اگرچہ ہمیشہ ضروری نہیں، جائزے ایک بہترین ترجمہ کے عمل کا ایک لازمی حصہ ہیں۔ عام طور پر، پیشہ ور جائزہ لینے والوں کو جائزے کے عمل کو آؤٹ سورس کرنا سب سے آسان ہے۔ تاہم، اگر آپ کے پاس ایک بڑی بین الاقوامی ٹیم ہے، تو جائزے یا QA کو اندرونی طور پر بھی ہینڈل کیا جاسکتا ہے۔ + +4. **ترجمہ شدہ مواد کو نافذ کرنا** - ورک فلو کا آخری حصہ، حالانکہ وقت سے پہلے غور کرنا اب بھی اہم ہے۔ + +- _کیا تمام ترجمے ایک ہی وقت میں مکمل کیے جائیں گے؟_ + - اگر نہیں، تو آپ کو اس بارے میں سوچنا چاہیے کہ کن ترجموں کو ترجیح دی جانی چاہیے، جاری ترجموں پر کیسے نظر رکھی جائے، اور ترجمے ہونے کے دوران عمل درآمد کو کیسے ہینڈل کیا جائے۔ +- _ترجمہ شدہ مواد آپ کو کیسے پہنچایا جائے گا؟_ یہ کس فارمیٹ میں ہوگا؟_ + - یہ ایک اہم غور ہے، چاہے آپ کوئی بھی طریقہ استعمال کریں۔ لوکلائزیشن ٹولز آپ کو ٹارگٹ فائل فارمیٹ اور ایکسپورٹ کے عمل پر کنٹرول برقرار رکھنے کی اجازت دیتے ہیں اور عام طور پر آٹومیشن کو سپورٹ کرتے ہیں، مثلاً، ہوسٹنگ سروس کے ساتھ انضمام کو فعال کرکے۔ +- _آپ اپنے پروجیکٹ میں ترجمے کیسے نافذ کریں گے؟_ + - کچھ معاملات میں، یہ اتنا آسان ہوسکتا ہے جتنا ترجمہ شدہ فائل کو اپ لوڈ کرنا یا اسے اپنے دستاویزات میں شامل کرنا۔ تاہم، زیادہ پیچیدہ پروجیکٹس، جیسے ویب سائٹ یا ایپ کے ترجمے کے ساتھ، آپ کو اس بات کو یقینی بنانا چاہیے کہ کوڈ بین الاقوامی کاری کو سپورٹ کرتا ہے اور یہ طے کریں کہ عمل درآمد کا عمل وقت سے پہلے کیسے ہینڈل کیا جائے گا۔ +- _اگر فارمیٹنگ سورس سے مختلف ہو تو کیا ہوگا؟_ + - اوپر کی طرح، اگر آپ سادہ ٹیکسٹ فائلوں کا ترجمہ کر رہے ہیں، تو فارمیٹنگ شاید اتنی اہم نہیں ہے۔ تاہم، زیادہ پیچیدہ فائلوں کے ساتھ، جیسے ویب سائٹ یا ایپلیکیشن کے مواد، آپ کے پروجیکٹ میں لاگو ہونے کے لیے فارمیٹنگ اور کوڈ کا سورس کے مطابق ہونا ضروری ہے۔ اگر نہیں، تو ٹارگٹ فائلوں کو یا تو مترجمین یا آپ کے ڈویلپرز کے ذریعہ ترمیم کرنے کی ضرورت ہوگی۔ + +**معنی 2** + +ایک متبادل ترجمہ ورک فلو، جو اندرونی فیصلوں اور طریقوں کا حساب نہیں رکھتا ہے۔ یہاں بنیادی غور مواد کے بہاؤ کا ہے۔ + +اس معاملے میں ایک مثال کا ورک فلو یہ ہوگا: + +1. _ترجمہ ← عمل درآمد_ + +- سب سے آسان ورک فلو، جہاں ترجمہ ممکنہ طور پر انسانی ترجمہ ہوگا، کیونکہ عمل درآمد سے پہلے ترجمے کے معیار کا جائزہ لینے اور ان میں ترمیم کرنے کے لیے کوئی جائزہ یا QA عمل نہیں ہے۔ +- اس ورک فلو کے ساتھ، یہ ضروری ہے کہ مترجم ایک خاص سطح کا معیار برقرار رکھ سکیں، جس کے لیے پروجیکٹ مینیجرز اور مترجمین کے درمیان مناسب وسائل اور مواصلات کی ضرورت ہوگی۔ + +2. _ترجمہ ← جائزہ ← عمل درآمد_ + +- ایک زیادہ جدید ورک فلو، جس میں ترجمے کے معیار کو قابل قبول اور مستقل بنانے کو یقینی بنانے کے لیے ایک جائزہ اور ترمیم کا عمل شامل ہے۔ +- اس ورک فلو کے بہت سے طریقے ہیں، جہاں ترجمے پیشہ ور مترجمین یا رضاکاروں کے ذریعہ انجام دیئے جاسکتے ہیں، جبکہ جائزے کے عمل کو ممکنہ طور پر پیشہ ور جائزہ لینے والے سنبھالیں گے، جو ٹارگٹ زبان میں مشاہدہ کیے جانے والے تمام گرامر اور آرتھوگرافی کے اصولوں سے واقف ہیں۔ + +3. _ترجمہ ← جائزہ ← QA ← عمل درآمد_ + +- اعلیٰ ترین معیار کو یقینی بنانے کے لیے بہترین ورک فلو۔ اگرچہ QA ہمیشہ ضروری نہیں ہوتا ہے، لیکن ترجمہ اور جائزے کے بعد ترجمہ شدہ متن کے معیار کا بہتر احساس دلانے کے لیے یہ کارآمد ثابت ہوسکتا ہے۔ +- اس ورک فلو کے ساتھ، ترجمے خصوصی طور پر رضاکاروں یا یہاں تک کہ مشین ترجمہ کے ذریعے کیے جاسکتے ہیں۔ جائزے کا عمل پیشہ ور مترجمین کے ذریعہ انجام دیا جانا چاہئے، جبکہ QA زبان کی خدمت فراہم کرنے والے کے ذریعہ یا اندرونی طور پر انجام دیا جاسکتا ہے، اگر آپ کے پاس ایسے ملازمین ہیں جو ٹارگٹ زبانوں کے مقامی بولنے والے ہیں۔ + +ترجمہ کے ورک فلو کے بارے میں مزید پڑھیں: + +[ترجمہ کے ورک فلو کے پانچ مراحل پر مواد کے قواعد](https://contentrules.com/creating-translation-workflow/) + +[Smartling پر ترجمہ ورک فلو مینجمنٹ کیا ہے](https://www.smartling.com/resources/101/what-is-translation-workflow-management/) + +[ترجمہ کے ورک فلو پر RixTrans](https://www.rixtrans.com/translation-workflow) + +## اصطلاحات کا انتظام {#terminology-management} + +اصطلاحات کو سنبھالنے کے طریقے پر ایک واضح منصوبہ قائم کرنا آپ کے ترجموں کے معیار اور مستقل مزاجی کو یقینی بنانے اور اپنے مترجمین کا وقت بچانے کے لیے سب سے اہم اقدامات میں سے ایک ہے۔ + +ترجمے کی جگہ میں، اسے اصطلاحات کے انتظام کے نام سے جانا جاتا ہے اور یہ زبان کی خدمت فراہم کرنے والوں کی طرف سے اپنے کلائنٹس کو پیش کی جانے والی کلیدی خدمات میں سے ایک ہے، اس کے علاوہ ماہرین لسانیات کے پول اور مواد کے انتظام تک رسائی۔ + +اصطلاحات کا انتظام اس اصطلاح کی نشاندہی، جمع کرنے اور اس کا انتظام کرنے کے عمل سے مراد ہے جو آپ کے پروجیکٹ کے لیے اہم ہے اور اس کا ہمیشہ صحیح اور مستقل طور پر ترجمہ کیا جانا چاہیے۔ + +اصطلاحات کے انتظام کے بارے میں سوچنا شروع کرتے وقت پیروی کرنے کے لیے کچھ اقدامات ہیں: + +- ان اہم اصطلاحات کی نشاندہی کریں جنہیں ٹرم بیس میں شامل کیا جانا چاہیے۔ +- اصطلاحات اور ان کی تعریفوں کی ایک لغت بنائیں۔ +- اصطلاحات کا ترجمہ کریں اور انہیں لغت میں شامل کریں۔ +- ترجموں کو چیک کریں اور منظور کریں۔ +- لغت کو برقرار رکھیں اور اسے نئی اصطلاحات کے ساتھ اپ ڈیٹ کریں، کیونکہ وہ اہم ہو جاتے ہیں۔ + +اصطلاحات کے انتظام کے بارے میں مزید پڑھیں: + +[Trados پر اصطلاحات کا انتظام کیا ہے](https://www.trados.com/solutions/terminology-management/translation-101-what-is-terminology-management.html) + +[Language Scientific پر اصطلاحات کا انتظام کیوں اہم ہے](https://www.languagescientific.com/terminology-management-why-it-matters/#:~:text=Terminology%20management%20is%20the%20process,are%20related%20to%20each%20other.) + +[Clear Words Translation پر اصطلاحات کا انتظام کیا ہے اور یہ کیوں اہم ہے](http://clearwordstranslations.com/language/en/what-is-terminology-management/) + +### ترجمہ میموری اور لغت {#tm-and-glossary} + +ترجمہ میموری اور لغت ترجمہ کی صنعت میں اہم اوزار ہیں اور ایسی چیز جس پر زیادہ تر زبان کی خدمت فراہم کرنے والے انحصار کرتے ہیں۔ + +آئیے دیکھتے ہیں کہ ان اصطلاحات کا کیا مطلب ہے اور وہ ایک دوسرے سے کیسے مختلف ہیں: + +**ترجمہ میموری (TM)** – ایک ڈیٹا بیس جو خود بخود حصوں یا سٹرنگز کو ذخیرہ کرتا ہے، بشمول متن کے لمبے بلاکس، مکمل جملے، پیراگراف، اور انفرادی اصطلاحات، نیز ہر زبان میں ان کے موجودہ اور پچھلے ترجمے۔ + +زیادہ تر لوکلائزیشن ٹولز، ترجمہ مینجمنٹ سسٹمز، اور کمپیوٹر کی مدد سے ترجمہ کرنے والے ٹولز میں بلٹ ان ترجمہ میموریز ہوتی ہیں، جنہیں عام طور پر ایکسپورٹ کیا جا سکتا ہے اور اسی طرح کے دوسرے ٹولز میں بھی استعمال کیا جا سکتا ہے۔ + +ترجمہ میموری کے استعمال کے فوائد میں تیز تر ترجمے، بہتر ترجمہ کا معیار، سورس مواد کو اپ ڈیٹ کرنے یا تبدیل کرتے وقت کچھ ترجموں کو برقرار رکھنے کی صلاحیت، اور بار بار آنے والے مواد کے لیے ترجمے کے سستے اخراجات شامل ہیں۔ + +ترجمہ میموریز مختلف حصوں کے درمیان فیصد میچ کی بنیاد پر کام کرتی ہیں اور عام طور پر اس وقت سب سے زیادہ مفید ہوتی ہیں جب دو حصوں میں 50% سے زیادہ ایک جیسا مواد ہو۔ ان کا استعمال بار بار آنے والے حصوں کا خود بخود ترجمہ کرنے کے لیے بھی کیا جاتا ہے، جو 100% مماثل ہوتے ہیں، اس طرح بار بار آنے والے مواد کا ایک سے زیادہ بار ترجمہ کرنے کی ضرورت ختم ہوجاتی ہے۔ + +ترجمہ میموریز کے بارے میں مزید پڑھیں: + +[ترجمہ میموریز پر Memsource](https://www.memsource.com/translation-memory/) + +[Smartling پر ترجمہ میموری کیا ہے](https://www.smartling.com/resources/101/what-is-translation-memory/) + +**لغت –** اہم یا حساس اصطلاحات، ان کی تعریفیں، افعال، اور قائم شدہ ترجموں کی فہرست۔ لغت اور ترجمہ میموری کے درمیان بنیادی فرق یہ ہے کہ لغت خود بخود نہیں بنتی ہے، اور اس میں مکمل جملوں کے ترجمے نہیں ہوتے ہیں۔ + +زیادہ تر لوکلائزیشن ٹولز، ترجمہ مینجمنٹ سسٹمز، اور کمپیوٹر کی مدد سے ترجمہ کرنے والے ٹولز میں بلٹ ان لغتیں ہوتی ہیں جنہیں آپ اس بات کو یقینی بنانے کے لیے برقرار رکھ سکتے ہیں کہ ان میں آپ کے پروجیکٹ کے لیے اہم اصطلاحات موجود ہیں۔ TM کی طرح، لغت کو عام طور پر ایکسپورٹ کیا جا سکتا ہے اور دوسرے لوکلائزیشن ٹولز میں استعمال کیا جا سکتا ہے۔ + +اپنا ترجمہ پروجیکٹ شروع کرنے سے پہلے، یہ انتہائی سفارش کی جاتی ہے کہ کچھ وقت نکالیں اور اپنے مترجمین اور جائزہ لینے والوں کے لیے ایک لغت بنائیں۔ لغت کا استعمال اس بات کو یقینی بناتا ہے کہ اہم اصطلاحات کا صحیح ترجمہ کیا گیا ہے، مترجمین کو بہت ضروری سیاق و سباق فراہم کرتا ہے، اور ترجموں میں مستقل مزاجی کی ضمانت دیتا ہے۔ + +جبکہ لغات میں اکثر ٹارگٹ زبانوں میں قائم شدہ ترجمے ہوتے ہیں، وہ اس کے بغیر بھی مفید ہیں۔ قائم شدہ ترجموں کے بغیر بھی، ایک لغت میں تکنیکی اصطلاحات کی تعریفیں ہوسکتی ہیں، ایسی اصطلاحات کو اجاگر کریں جن کا ترجمہ نہیں ہونا چاہیے، اور مترجمین کو مطلع کریں کہ آیا کوئی مخصوص اصطلاح بطور اسم، فعل، مناسب اسم، یا تقریر کا کوئی اور حصہ استعمال ہوتی ہے۔ + +لغتوں کے بارے میں مزید پڑھیں: + +[ترجمہ لغت کیا ہے پر Lionbridge](http://info.lionbridge.com/rs/lionbridge/images/Lionbridge%20FAQ_Glossary_2013.pdf) + +[لغات پر Transifex](https://docs.transifex.com/glossary/glossary) + +اگر آپ اپنے پروجیکٹ کے لیے لوکلائزیشن ٹول استعمال کرنے کا ارادہ نہیں کر رہے ہیں، تو آپ ممکنہ طور پر ترجمہ میموری اور لغت کا استعمال نہیں کر پائیں گے (آپ ایکسل فائل میں ایک لغت یا ٹرم بیس بنا سکتے ہیں، تاہم، خودکار لغتیں مترجمین کو دستی طور پر اصطلاحات اور ان کی تعریفیں تلاش کرنے کی ضرورت کو ختم کردیتی ہیں)۔ + +اس کا مطلب ہے کہ تمام بار بار آنے والے اور اسی طرح کے مواد کا ہر بار دستی طور پر ترجمہ کرنا ہوگا۔ اس کے علاوہ، مترجمین کو اس بارے میں سوالات کے ساتھ رابطہ کرنا ہوگا کہ آیا کسی خاص اصطلاح کا ترجمہ کرنے کی ضرورت ہے یا نہیں، یہ متن میں کیسے استعمال ہوتی ہے، اور آیا کسی اصطلاح کا پہلے سے ہی قائم شدہ ترجمہ ہے۔ + +_کیا آپ اپنے پروجیکٹ میں ethereum.org ترجمہ میموری اور لغت کا استعمال کرنا چاہتے ہیں؟_ ہم سے translations@ethereum.org پر رابطہ کریں۔_ + +## مترجم تک رسائی {#translator-outreach} + +**زبان کی خدمت فراہم کرنے والے کے ساتھ کام کرنا** + +اگر آپ کسی زبان کی خدمت فراہم کرنے والے اور ان کے پیشہ ور مترجمین کے ساتھ کام کر رہے ہیں، تو یہ سیکشن آپ کے لیے زیادہ متعلقہ نہیں ہوسکتا ہے۔ + +اس معاملے میں، یہ ضروری ہے کہ ایسی زبان کی خدمت فراہم کرنے والے کا انتخاب کیا جائے جس میں بہت سی زبانوں میں آپ کو درکار تمام خدمات (مثلاً، ترجمہ، جائزہ، QA) فراہم کرنے کی صلاحیت ہو۔ + +جبکہ یہ صرف ان کی پیش کردہ شرحوں کی بنیاد پر کسی زبان کی خدمت فراہم کرنے والے کا انتخاب کرنے کے لیے پرکشش ہوسکتا ہے، یہ نوٹ کرنا ضروری ہے کہ سب سے بڑی زبان کی خدمت فراہم کرنے والوں کی شرحیں ایک وجہ سے زیادہ ہیں۔ + +- ان کے ڈیٹا بیس میں دسیوں ہزار ماہرین لسانیات ہیں، جس کا مطلب ہے کہ وہ آپ کے پروجیکٹ کے لیے آپ کے مخصوص شعبے کے کافی تجربہ اور علم رکھنے والے مترجمین کو تفویض کر سکیں گے (یعنی تکنیکی مترجمین)۔ +- انہیں مختلف پروجیکٹس پر کام کرنے اور اپنے کلائنٹس کی متنوع ضروریات کو پورا کرنے کا اہم تجربہ ہے۔ اس کا مطلب ہے کہ وہ آپ کے مخصوص ورک فلو کے مطابق ڈھالنے، آپ کے ترجمے کے عمل کے لیے قیمتی تجاویز اور ممکنہ بہتری پیش کرنے، اور آپ کی ضروریات، تقاضوں اور آخری تاریخوں کو پورا کرنے کا زیادہ امکان رکھتے ہیں۔ +- زیادہ تر سب سے بڑی زبان کی خدمت فراہم کرنے والوں کے پاس اپنے لوکلائزیشن ٹولز، ترجمہ میموریز، اور لغات بھی ہوتی ہیں جنہیں آپ استعمال کرسکتے ہیں۔ اگر نہیں، تو ان کے پاس کم از کم اپنے پول میں کافی ماہرین لسانیات ہیں تاکہ یہ یقینی بنایا جا سکے کہ ان کے مترجم اس سے واقف ہوں گے اور آپ جس بھی لوکلائزیشن ٹول کو استعمال کرنا چاہتے ہیں اس کے ساتھ کام کر سکیں گے۔ + +آپ دنیا کی سب سے بڑی زبان کی خدمت فراہم کرنے والوں کا گہرا موازنہ، ان میں سے ہر ایک کے بارے میں کچھ تفصیلات اور ان کی فراہم کردہ خدمات، جغرافیائی ڈیٹا، وغیرہ کے لحاظ سے بریک ڈاؤن [2021 Nimdzi 100 رپورٹ](https://www.nimdzi.com/nimdzi-100-top-lsp/) میں حاصل کرسکتے ہیں۔ + +**غیر پیشہ ور مترجمین کے ساتھ کام کرنا** + +آپ شاید غیر پیشہ ور مترجمین کے ساتھ کام کر رہے ہوں گے اور ترجمہ میں مدد کے لیے رضاکاروں کی تلاش میں ہوں گے۔ + +لوگوں تک پہنچنے اور انہیں اپنے پروجیکٹ میں شامل ہونے کی دعوت دینے کے کئی طریقے ہیں۔ یہ بڑی حد تک آپ کے پروڈکٹ پر اور اس بات پر منحصر ہوگا کہ آپ کے پاس پہلے سے کتنی بڑی کمیونٹی ہے۔ + +رضاکاروں کو آن بورڈ کرنے کے کچھ طریقے ذیل میں بیان کیے گئے ہیں: + +**آؤٹ ریچ –** جبکہ یہ ذیل کے نکات میں کسی حد تک شامل ہے، ممکنہ رضاکاروں تک پہنچنا اور اس بات کو یقینی بنانا کہ وہ آپ کے ترجمے کے اقدام سے واقف ہیں، خود ہی موثر ثابت ہوسکتا ہے۔ + +بہت سے لوگ اپنے پسندیدہ پروجیکٹس میں شامل ہونا اور حصہ ڈالنا چاہتے ہیں، لیکن اکثر ڈویلپر ہونے یا خاص تکنیکی مہارتوں کے بغیر ایسا کرنے کا کوئی واضح طریقہ نہیں دیکھتے۔ اگر آپ اپنے پروجیکٹ کے بارے میں بیداری پھیلا سکتے ہیں، تو بہت سے دو لسانی لوگ ممکنہ طور پر اس میں شامل ہونے کے خواہشمند ہوں گے۔ + +**اپنی کمیونٹی کے اندر تلاش کرنا –** اس شعبے میں زیادہ تر پروجیکٹس کے پاس پہلے سے ہی بڑی اور فعال کمیونٹیز ہیں۔ آپ کے بہت سے کمیونٹی ممبران شاید ایک سادہ طریقے سے پروجیکٹ میں حصہ ڈالنے کے موقع کی تعریف کریں گے۔ + +جبکہ اوپن سورس پروجیکٹس میں حصہ ڈالنا اکثر اندرونی ترغیب پر مبنی ہوتا ہے، یہ ایک شاندار سیکھنے کا تجربہ بھی ہے۔ جو بھی آپ کے پروجیکٹ کے بارے میں مزید جاننے میں دلچسپی رکھتا ہے وہ ممکنہ طور پر ایک رضاکار کے طور پر ترجمہ پروگرام میں شامل ہونے پر خوش ہوگا، کیونکہ یہ انہیں اس حقیقت کو جوڑنے کی اجازت دے گا کہ انہوں نے کسی ایسی چیز میں حصہ ڈالا ہے جس کا وہ خیال رکھتے ہیں ایک گہرے ہینڈز آن سیکھنے کے تجربے کے ساتھ۔ + +**اپنے پروڈکٹ میں پہل کا ذکر کرنا –** اگر آپ کا پروڈکٹ مقبول ہے اور بڑی تعداد میں لوگ اسے استعمال کرتے ہیں، تو اپنے ترجمہ پروگرام کو نمایاں کرنا اور پروڈکٹ استعمال کرتے وقت صارفین کو کارروائی کی کال دینا انتہائی موثر ثابت ہوسکتا ہے۔ + +یہ اتنا آسان ہوسکتا ہے جتنا ایپلی کیشنز اور ویب سائٹس کے لیے اپنے پروڈکٹ میں CTA کے ساتھ ایک بینر یا پاپ اپ شامل کرنا۔ یہ موثر ہے کیونکہ آپ کے ہدف والے سامعین آپ کی کمیونٹی ہیں - وہ لوگ جو سب سے پہلے شامل ہونے کا سب سے زیادہ امکان رکھتے ہیں۔ + +**سوشل میڈیا –** سوشل میڈیا آپ کے ترجمہ پروگرام کے بارے میں بیداری پھیلانے اور آپ کے کمیونٹی ممبران کے ساتھ ساتھ دوسرے لوگوں تک پہنچنے کا ایک موثر طریقہ ہوسکتا ہے جو ابھی تک آپ کی کمیونٹی کے ممبر نہیں ہیں۔ + +اگر آپ کے پاس Discord سرور یا Telegram چینل ہے، تو اسے آؤٹ ریچ، اپنے مترجمین کے ساتھ مواصلت، اور اپنے شراکت داروں کو تسلیم کرنے کے لیے استعمال کرنا آسان ہے۔ + +پلیٹ فارمز جیسے X (سابقہ Twitter) نئے کمیونٹی ممبران کو آن بورڈ کرنے اور اپنے شراکت داروں کو عوامی طور پر تسلیم کرنے کے لیے بھی مددگار ثابت ہوسکتے ہیں۔ + +لینکس فاؤنڈیشن نے ایک وسیع [2020 FOSS شراکت دار سروے پر رپورٹ](https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf) بنائی ہے، جس میں اوپن سورس شراکت داروں اور ان کی ترغیبات کا تجزیہ کیا گیا ہے۔ + +## نتیجہ {#conclusion} + +اس دستاویز میں کچھ کلیدی غور و خوض ہیں جن سے ہر ترجمہ پروگرام کو آگاہ ہونا چاہیے۔ یہ کسی بھی طرح سے ایک مکمل گائیڈ نہیں ہے، حالانکہ یہ ترجمہ کی صنعت میں کوئی تجربہ نہ رکھنے والے کسی بھی شخص کو اپنے پروجیکٹ کے لیے ترجمہ پروگرام منظم کرنے میں مدد کرسکتا ہے۔ + +اگر آپ مختلف ٹولز، عمل، اور ترجمہ پروگرام کے انتظام کے اہم پہلوؤں کی مزید تفصیلی ہدایات اور بریک ڈاؤن تلاش کر رہے ہیں، تو کچھ سب سے بڑی زبان کی خدمت فراہم کرنے والے بلاگ برقرار رکھتے ہیں اور اکثر لوکلائزیشن کے عمل کے مختلف پہلوؤں پر مضامین شائع کرتے ہیں۔ یہ بہترین وسائل ہیں اگر آپ مندرجہ بالا کسی بھی موضوع میں گہرائی میں جانا چاہتے ہیں اور سمجھنا چاہتے ہیں کہ لوکلائزیشن کا عمل پیشہ ورانہ طور پر کیسے کام کرتا ہے۔ + +کچھ متعلقہ لنکس ہر سیکشن کے آخر میں شامل ہیں؛ تاہم، آپ آن لائن بہت سے دوسرے وسائل تلاش کرسکتے ہیں۔ + +تعاون کی تجاویز یا اضافی معلومات، سیکھنے، اور بہترین طریقوں کے لیے جو ہم نے ethereum.org ترجمہ پروگرام کو برقرار رکھتے ہوئے حاصل کیے ہیں، بلا جھجھک ہم سے translations@ethereum.org پر رابطہ کریں۔ diff --git a/public/content/translations/ur/contributing/translation-program/resources/index.md b/public/content/translations/ur/contributing/translation-program/resources/index.md new file mode 100644 index 00000000000..1747002d851 --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/resources/index.md @@ -0,0 +1,49 @@ +--- +title: "مترجمین کے لیے وسائل" +lang: ur-in +description: "ethereum.org کے مترجمین کے لیے مفید وسائل" +--- + +# وسائل {#resources} + +آپ ethereum.org کے مترجمین کے لیے کچھ مفید گائیڈز اور ٹولز کے ساتھ ساتھ نیچے ترجمہ کمیونٹیز اور اپ ڈیٹس بھی تلاش کر سکتے ہیں۔ + +## گائیڈز {#guides} + +- [ترجمہ اسٹائل گائیڈ](/contributing/translation-program/translators-guide/) _– ethereum.org کے مترجمین کے لیے ہدایات اور ٹپس_ +- [ترجمہ کے عمومی سوالات](/contributing/translation-program/faq/) _– ethereum.org ترجمہ پروگرام کے بارے میں اکثر پوچھے جانے والے سوالات اور جوابات_ +- [Crowdin آن لائن ایڈیٹر گائیڈ](https://support.crowdin.com/online-editor/) _– Crowdin آن لائن ایڈیٹر اور Crowdin کی کچھ جدید خصوصیات کو استعمال کرنے کے لیے ایک گہرائی سے گائیڈ_ + +## ٹولز {#tools} + +- [Linguee](https://www.linguee.com/) + _– ترجموں اور ڈکشنری کے لیے سرچ انجن جو لفظ یا فقرے کے ذریعے تلاش کرنے کے قابل بناتا ہے_ +- [Proz ٹرم سرچ](https://www.proz.com/search/) + _– خصوصی اصطلاحات کے لیے ترجمہ لغات اور اصطلاحات کا ڈیٹا بیس_ +- [Eurotermbank](https://www.eurotermbank.com/) + _– 42 زبانوں میں یورپی اصطلاحات کے مجموعے_ + +## کمیونٹیز {#communities} + +- [زبان کے لیے مخصوص Discord ترجمہ گروپس](https://discord.gg/ethereum-org) + _– ethereum.org کے مترجمین کو ٹرانسلیشن گروپس سے جوڑنے کی ایک پہل_ +- [چینی مترجمین کا گروپ](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) + _– چینی مترجمین کے درمیان آسان کوآرڈینیشن کے لیے Notion صفحہ_ + +## تازہ ترین اپ ڈیٹس {#latest-updates} + +تازہ ترین ٹرانسلیشن پروگرام کی پیشرفت سے باخبر رہنے کے لیے، آپ [Ethereum فاؤنڈیشن بلاگ](https://blog.ethereum.org/) کو فالو کر سکتے ہیں: + +- [اکتوبر 2021 سنگ میل اپ ڈیٹ](https://blog.ethereum.org/2021/10/04/translation-program-update/) +- [دسمبر 2020 سنگ میل اپ ڈیٹ](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/) +- [جولائی 2020 سنگ میل اپ ڈیٹ](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/) +- [اگست 2019 ٹرانسلیشن پروگرام کا آغاز](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/) + +## مترجمین کے لیے دفتری اوقات {#office-hours} + +ہمارے پاس ہر مہینے کے دوسرے بدھ کو مترجمین کے لیے دفتری اوقات ہوتے ہیں۔ یہ [ethereum.org Discord](https://discord.gg/ethereum-org) پر #office-hours وائس چینل میں منعقد ہوتے ہیں، جہاں آپ درست اوقات اور اضافی تفصیلات بھی حاصل کر سکتے ہیں۔ + +دفتری اوقات ہمارے مترجمین کو ترجمہ کے عمل کے بارے میں سوالات پوچھنے، پروگرام پر فیڈ بیک فراہم کرنے، اپنے خیالات کا اشتراک کرنے، یا صرف کور ethereum.org ٹیم کے ساتھ بات چیت کرنے کی اجازت دیتے ہیں۔ +آخر میں، ہم ان کالز کا استعمال ٹرانسلیشن پروگرام کے ساتھ حالیہ پیشرفتوں کو بات چیت کرنے اور اپنے معاونین کے ساتھ کلیدی ٹپس اور ہدایات کا اشتراک کرنے کے لیے کرنا چاہتے ہیں۔ + +اگر آپ ایک ethereum.org مترجم ہیں یا بننا چاہتے ہیں، تو ان میں سے کسی ایک سیشن کے دوران بلا جھجک ہمارے ساتھ شامل ہوں۔ diff --git a/public/content/translations/ur/contributing/translation-program/translatathon/details/index.md b/public/content/translations/ur/contributing/translation-program/translatathon/details/index.md new file mode 100644 index 00000000000..c256f8d9b22 --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/translatathon/details/index.md @@ -0,0 +1,90 @@ +--- +title: "تفصیلات اور قواعد" +lang: ur-in +template: translatathon +--- + +![](./participate.png) + +Translatathon کھلا ہے اور کوئی بھی درخواست فارم بھر کر اور Crowdin میں پروجیکٹ میں شامل ہو کر حصہ لے سکتا ہے۔ + +مترجمین ترجمہ کی مدت کے دوران Crowdin ایڈیٹر میں اپنی زبان میں غیر ترجمہ شدہ اسٹرنگز کے لیے ترجمے تجویز کر کے پوائنٹس اکٹھا کرتے ہیں۔ + +ہر شریک کا حتمی اسکور لیڈر بورڈ پر ان کی پوزیشن سے طے ہوتا ہے جو ترجمہ کی مدت کے دوران ان کے ترجمہ کردہ الفاظ کی تعداد اور ان کے جمع کردہ کسی بھی ممکنہ بونس پوائنٹس پر مبنی ہوتا ہے۔ + +## شروعات کرنا {#getting-started} + +ترجمہ کا عمل Crowdin میں ethereum.org پروجیکٹ میں ہوتا ہے اور مترجمین غیر ترجمہ شدہ اسٹرنگز کے لیے اپنے تراجم تجویز کرتے ہیں، جو ethereum.org ویب سائٹ کے تقریباً تمام مواد پر مشتمل ہوتے ہیں۔ + +تراجم براہ راست آن لائن ایڈیٹر میں تجویز کیے جاتے ہیں لہذا کسی بھی فائل یا ڈیلیوریبلز کو ڈاؤن لوڈ یا اپ لوڈ کرنے کی ضرورت نہیں ہے۔ ہر ترجمہ شدہ لفظ کو ٹریک اور شمار کیا جاتا ہے۔ + +**1) پروجیکٹ میں شامل ہوں** + +- تعاون شروع کرنے کے لیے، [Crowdin میں ethereum.org پروجیکٹ](https://crowdin.com/project/ethereum-org) میں شامل ہوں۔ +- آپ کو سائن ان کرنا ہوگا یا ایک اکاؤنٹ بنانا ہوگا - جس کے لیے صرف ایک ای میل ایڈریس اور پاس ورڈ درکار ہے۔ + +**2) اپنی زبان منتخب کریں** + +- ہدف کی زبانوں کی فہرست میں اپنی زبان تلاش کریں اور اس کے نام یا پرچم پر کلک کرکے اسے کھولیں۔ +- اگر آپ کسی ایسی زبان میں ترجمہ کرنا چاہتے ہیں جو دستیاب نہیں ہے، تو Crowdin پر [Ethereum.org ٹیم](https://crowdin.com/profile/ethdotorg) سے رابطہ کریں یا ہمیں translations@ethereum.org پر ایک ای میل بھیجیں اور ہم درخواست کے مطابق اضافی ہدف کی زبانیں شامل کریں گے۔ + +**3) ایک غیر ترجمہ شدہ فائل کھولیں** + +- ترجمہ شروع کرنے کے لیے پہلی غیر ترجمہ شدہ فائل تلاش کریں۔ سورس فائلوں پر مشتمل فولڈرز ترجیح پر مبنی ہیں، لہذا آپ کو پہلے اس فولڈر کا ترجمہ شروع کرنا چاہیے جس میں غیر ترجمہ شدہ فائلیں ہیں۔ +- ہر فائل میں ایک پیش رفت کا اشارہ ہوتا ہے جو یہ ظاہر کرتا ہے کہ فائل میں قابلِ ترجمہ مواد کا کتنا ترجمہ اور منظور کیا گیا ہے... اگر کسی فائل کے لیے ترجمہ کی پیش رفت %100 سے کم ہے، تو براہ کرم اس کا ترجمہ کریں۔ + +**4) غیر ترجمہ شدہ اسٹرنگز کا ترجمہ کریں** + +- جب آپ ترجمہ کرنے کے لیے کوئی فائل کھولتے ہیں، تو یقینی بنائیں کہ آپ صرف غیر ترجمہ شدہ اسٹرنگز کا ترجمہ کر رہے ہیں! +- ہر اسٹرنگ میں ایک اسٹیٹس انڈیکیٹر ہوتا ہے جو یہ ظاہر کرتا ہے کہ آیا یہ _ترجمہ شدہ_، _غیر ترجمہ شدہ_، یا _منظور شدہ_ ہے۔ اگر کسی سورس اسٹرنگ کا آپ کی زبان میں پہلے سے ہی کوئی تجویز کردہ ترجمہ موجود ہے، تو اس کا ترجمہ کرنے کی ضرورت نہیں ہے۔ +- آپ ایڈیٹر میں اسٹرنگز کو فلٹر بھی کر سکتے ہیں تاکہ _پہلے غیر ترجمہ شدہ_ یا _صرف غیر ترجمہ شدہ_ دکھائے جائیں۔ + +Crowdin ایڈیٹر کو نیویگیٹ کرنے اور استعمال کرنے کے بارے میں تفصیلی گائیڈ کے لیے، ہم تمام Translatathon شرکاء کو ہماری [ترجمہ کیسے کریں](/contributing/translation-program/how-to-translate/) گائیڈ پڑھنے کی تجویز دیتے ہیں۔ + +آپ ہماری [ترجمہ اسٹائل گائیڈ](/contributing/translation-program/translators-guide/) دیکھ کر کچھ تجاویز اور بہترین طریقے بھی تلاش کر سکتے ہیں۔ + +**پوائنٹس کیسے کام کرتے ہیں** + +ہر Translatathon شریک ethereum.org Crowdin پروجیکٹ اور دیگر اہل پروجیکٹس (اہل پروجیکٹس کی مکمل فہرست ذیل میں دستیاب ہے) میں مواد کا ترجمہ کرکے اپنے حتمی اسکور کے لیے پوائنٹس حاصل کرے گا۔ + +اسکورنگ آسان ہے: **1 ترجمہ شدہ لفظ = 1 پوائنٹ** + +اپنے حتمی پوائنٹس کی تقسیم حاصل کرنے کے لیے، آپ کے تجویز کردہ تراجم کو تشخیصی عمل سے گزرنا ہوگا، جہاں پیشہ ور جائزہ کار ہر شریک کے تراجم کی جانچ کریں گے تاکہ یہ یقینی بنایا جا سکے کہ وہ کم از کم معیار کی حد کو پورا کرتے ہیں اور اس عمل میں کوئی مشین یا AI تراجم استعمال نہیں کیے گئے تھے۔ + +## ایکو سسٹم مواد {#ecosystem-content} + +چونکہ ethereum.org ترجمہ پروگرام ہر وقت فعال رہتا ہے، اس لیے ویب سائٹ پر کچھ ہدف کی زبانوں میں ترجمہ کی پیش رفت دوسروں کے مقابلے میں نمایاں طور پر زیادہ ہے۔ + +اس بات کو یقینی بنانے کے لیے کہ تمام Translatathon شرکاء کو زیادہ سے زیادہ مواد کا ترجمہ کرنے اور اعلیٰ انعامات کے لیے مقابلہ کرنے کا یکساں موقع ملے، Translatathon کا حصہ بننے والا سورس مواد صرف ethereum.org ویب سائٹ کے مواد تک محدود نہیں ہے۔ + +کسی بھی اہل پروجیکٹ کا ترجمہ کرنے والے شرکاء برابر پوائنٹس حاصل کریں گے، کسی بھی پروجیکٹ میں 1 ترجمہ شدہ لفظ = 1 پوائنٹ۔ + +یہ ان تمام اہل پروجیکٹس کی فہرست ہے جو 2025 Translatathon کا حصہ ہیں: + +- [Ethereum.org](https://crowdin.com/project/ethereum-org) + +- [Ethereum.org ڈیولپر ٹیوٹوریلز](https://crowdin.com/project/33388446abbe9d7aa21e42e49bba7f97) + +- [EthStaker ڈپازٹ CLI](https://crowdin.com/project/ethstaker-deposit-cli) + +- [Eth Docker دستاویزات](https://crowdin.com/project/eth-docker-docs) + +- [Remix IDE دستاویزات](https://crowdin.com/project/remix-translation) + +- [Remix LearnEth](https://crowdin.com/project/remix-learneth) + +- [web3.py](https://crowdin.com/project/web3py) + +## تشخیصی عمل {#evaluation-process} + +تمام تراجم QA اور فیڈ بیک کے تابع ہوں گے، جہاں پیشہ ور ماہر لسانیات معیار اور درستگی کی بنیاد پر جمع کرائے گئے تراجم کا جائزہ لیں گے۔ + +ہم کچھ ایسے ٹولز کا استعمال کرتے ہوئے **اینٹی مشین ٹرانسلیشن اقدامات** بھی چلائیں گے جو خود بخود مشین یا AI تراجم کا پتہ لگاتے ہیں۔ + +اگرچہ اسکورنگ میں ترجمہ کا معیار کوئی اہم کردار ادا نہیں کرے گا، لیکن کوئی بھی **شرکاء جو مشین یا AI تراجم کا استعمال کرتے ہوئے پائے گئے** یا کم معیار اور غلط تراجم تجویز کرتے ہیں وہ انعامات کے اہل نہیں ہوں گے! + +تشخیص کی مدت پورے ستمبر میں ہوگی اور نتائج کا اعلان 25 ستمبر کو ethereum.org کمیونٹی کال پر کیا جائے گا۔ + +ویب سائٹ میں شامل کرنے سے پہلے تمام تراجم کا مکمل جائزہ بھی لیا جائے گا۔ + + diff --git a/public/content/translations/ur/contributing/translation-program/translatathon/index.md b/public/content/translations/ur/contributing/translation-program/translatathon/index.md new file mode 100644 index 00000000000..a9833d0e2cc --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/translatathon/index.md @@ -0,0 +1,100 @@ +--- +title: "2025 ethereum.org ٹرانسلیتھون" +lang: ur-in +template: translatathon +--- + + + + + + + +## تعارف {#introduction} + +ہمارا ماننا ہے کہ Ethereum کا مواد اور آن بورڈنگ وسائل ہر کسی کے لیے قابل رسائی ہونے چاہئیں، چاہے وہ کوئی بھی زبان بولتے ہوں۔ +اس مقصد کے قریب جانے کے لیے، ethereum.org ٹرانسلیشن پروگرام ویب سائٹ کا زیادہ سے زیادہ زبانوں میں ترجمہ کرنے کی ایک پہل ہے۔ + +ٹرانسلیشن پروگرام کے حصے کے طور پر، ہم ٹرانسلیتھون کا تیسرا ایڈیشن منعقد کر رہے ہیں، جو کہ ہمارا ٹرانسلیشن مقابلہ ہے جس کا مقصد کم فعال زبانوں میں ٹرانسلیشن کے تعاون کی حوصلہ افزائی کرنا، سائٹ پر دستیاب زبانوں اور مواد کی مقدار میں اضافہ کرنا، نئے شراکت داروں کو شامل کرنا اور ہمارے موجودہ شراکت داروں کو انعام دینا ہے۔ + +اگر آپ انگریزی کے علاوہ کسی دوسری زبان کے مقامی بولنے والے ہیں اور انعامات کے لیے مقابلہ کرتے ہوئے Ethereum مواد کو مزید قابل رسائی بنانے میں مدد کرنا چاہتے ہیں، تو مزید جاننے کے لیے آگے پڑھیں! + +[ethereum.org ٹرانسلیشن پروگرام کے بارے میں مزید جانیں](/contributing/translation-program/) + +## ٹائم لائن {#timeline} + +2025 ٹرانسلیتھون کے لیے اہم تاریخیں یہ ہیں: + + + + + +## حصہ لیں {#participate} + +![کمیونٹی اور گلوب کی تصویر](./participate.png) + + + +

کون حصہ لے سکتا ہے؟

+ 18 سال سے زیادہ عمر کا کوئی بھی شخص، جو کم از کم ایک غیر انگریزی زبان کا مقامی بولنے والا ہو اور انگریزی میں ماہر ہو۔ +
+ +

کیا مجھے مترجم بننے کی ضرورت ہے؟

+ نہیں. آپ کو صرف دو لسانی ہونا ہوگا اور انسانی ترجمے تجویز کرنے ہوں گے (مشینی ترجمہ کا استعمال منع ہے!) اپنی بہترین صلاحیت کے مطابق، کسی پیشہ ورانہ تجربے کی ضرورت نہیں ہے۔ +
+
+ + + +

مجھے کتنا وقت دینا ہوگا؟

+ جتنا آپ چاہیں۔ انعامات کے اہل ہونے کے لیے کم از کم حد 1,000 ترجمہ شدہ الفاظ ہیں، جنہیں مکمل کرنے میں تقریباً 2 گھنٹے لگنے چاہئیں، جبکہ سرفہرست انعامات کے لیے مقابلہ کرنے کے لیے زیادہ وقت درکار ہوگا۔ +
+ +

کیا مجھے Ethereum سے واقف ہونے کی ضرورت ہے؟

+ نہیں. جبکہ Ethereum سے واقفیت آپ کی پیداواریت اور معیار میں مدد کر سکتی ہے، ٹرانسلیتھون ایک سیکھنے کا تجربہ بھی ہے، اور ہر کسی کو شرکت کرتے ہوئے Ethereum کے بارے میں مزید جاننے اور شامل ہونے کے لیے مدعو کیا جاتا ہے۔ +
+
+ +مزید تفصیلات کے لیے، [مکمل شرائط و ضوابط دیکھیں](/contributing/translation-program/translatathon/terms-and-conditions) + +### مرحلہ وار ہدایات {#step-by-step-instructions} + + + +## انعامات {#prizes} + +| مقام | انعام کی رقم | +| ---------------------- | ------------ | +| پہلا مقام | $4000 | +| دوسرا مقام | $2500 | +| تیسرا مقام | $1500 | +| چوتھا مقام | $1100 | +| پانچواں مقام | $1000 | +| چھٹا مقام | $600 | +| ساتواں مقام | $550 | +| آٹھواں مقام | $500 | +| نواں مقام | $450 | +| دسواں مقام | $400 | +| 11 واں - 20 واں مقام | $240 | +| 21 واں - 50 واں مقام | $120 | +| 51 واں - 100 واں مقام | $60 | +| 101 واں - 150 واں مقام | $40 | +| باقی | $20 | + +تمام انعامات ETH میں ادا کیے جائیں گے۔ + + + + diff --git a/public/content/translations/ur/contributing/translation-program/translators-guide/index.md b/public/content/translations/ur/contributing/translation-program/translators-guide/index.md new file mode 100644 index 00000000000..4ccbedab40e --- /dev/null +++ b/public/content/translations/ur/contributing/translation-program/translators-guide/index.md @@ -0,0 +1,299 @@ +--- +title: "مترجمین کے لیے گائیڈ" +lang: ur-in +description: "ethereum.org کے مترجمین کے لیے ہدایات اور تجاویز" +--- + +# Ethereum.org ترجمہ کا اسٹائل گائیڈ {#style-guide} + +ethereum.org ترجمہ کا اسٹائل گائیڈ مترجمین کے لیے کچھ اہم ترین رہنما خطوط، ہدایات، اور تجاویز پر مشتمل ہے، جو ہمیں ویب سائٹ کو مقامی بنانے میں مدد کرتا ہے۔ + +یہ دستاویز ایک عمومی گائیڈ کے طور پر کام کرتی ہے اور کسی ایک زبان کے لیے مخصوص نہیں ہے۔ + +اگر آپ کے کوئی سوالات، تجاویز یا تاثرات ہیں، تو بلا جھجھک ہم سے translations@ethereum.org پر رابطہ کریں، Crowdin پر @ethdotorg کو پیغام بھیجیں، یا [ہمارے Discord میں شامل ہوں](https://discord.gg/ethereum-org)، جہاں آپ ہمیں #translations چینل میں پیغام بھیج سکتے ہیں یا ٹیم کے کسی بھی رکن سے رابطہ کر سکتے ہیں۔ + +## Crowdin کا استعمال {#using-crowdin} + +آپ Crowdin میں پروجیکٹ میں شامل ہونے اور Crowdin آن لائن ایڈیٹر کا استعمال کرنے کے طریقے کے بارے میں بنیادی ہدایات [ترجمہ پروگرام کے صفحہ](/contributing/translation-program/#how-to-translate) پر حاصل کر سکتے ہیں۔ + +اگر آپ Crowdin اور اس کی کچھ جدید خصوصیات کے استعمال کے بارے میں مزید جاننا چاہتے ہیں، تو [Crowdin نالج بیس](https://support.crowdin.com/online-editor/) میں Crowdin کی تمام فعالیت کے بارے میں بہت ساری گہرائی سے رہنمائی اور جائزے موجود ہیں۔ + +## پیغام کے جوہر کو سمجھنا {#capturing-the-essence} + +ethereum.org کے مواد کا ترجمہ کرتے وقت، لفظی ترجمہ سے گریز کریں۔ + +یہ ضروری ہے کہ ترجمہ پیغام کے جوہر کو سمجھے۔ اس کا مطلب کچھ جملوں کو دوبارہ بیان کرنا، یا مواد کا لفظ بہ لفظ ترجمہ کرنے کے بجائے وضاحتی ترجمے استعمال کرنا ہو سکتا ہے۔ + +مختلف زبانوں میں گرامر کے اصول، روایات اور الفاظ کی ترتیب مختلف ہوتی ہے۔ ترجمہ کرتے وقت، براہ کرم اس بات کا خیال رکھیں کہ ہدف کی زبانوں میں جملے کیسے بنائے جاتے ہیں، اور انگریزی ماخذ کا لفظی ترجمہ کرنے سے گریز کریں، کیونکہ اس سے جملے کی ناقص ساخت اور پڑھنے میں دشواری ہو سکتی ہے۔ + +ماخذ متن کا لفظ بہ لفظ ترجمہ کرنے کے بجائے، یہ تجویز کیا جاتا ہے کہ آپ پورا جملہ پڑھیں اور اسے ہدف کی زبان کی روایات کے مطابق ڈھالیں۔ + +## رسمی بمقابلہ غیر رسمی {#formal-vs-informal} + +ہم خطاب کا رسمی طریقہ استعمال کرتے ہیں، جو ہمیشہ شائستہ اور تمام آنے والوں کے لیے موزوں ہوتا ہے۔ + +رسمی خطاب کا استعمال ہمیں غیر سرکاری یا ناگوار لگنے سے بچنے کی اجازت دیتا ہے، اور یہ آنے والے کی عمر اور جنس سے قطع نظر کام کرتا ہے۔ + +زیادہ تر ہند-یورپی اور افریقی-ایشیائی زبانیں جنس کے لحاظ سے مخصوص دوسرے شخص کے ذاتی ضمیر استعمال کرتی ہیں، جو مرد اور عورت کے درمیان فرق کرتی ہیں۔ صارف کو مخاطب کرتے وقت یا ملکیتی ضمیروں کا استعمال کرتے وقت، ہم آنے والے کی جنس کا اندازہ لگانے سے بچ سکتے ہیں، کیونکہ خطاب کا رسمی طریقہ عام طور پر قابل اطلاق اور مستقل ہوتا ہے، چاہے وہ خود کو کیسے بھی شناخت کریں۔ + +## سادہ اور واضح الفاظ اور معنی {#simple-vocabulary} + +ہمارا مقصد ویب سائٹ پر موجود مواد کو زیادہ سے زیادہ لوگوں کے لیے قابل فہم بنانا ہے۔ + +زیادہ تر معاملات میں، یہ آسانی سے چھوٹے اور سادہ الفاظ استعمال کرکے حاصل کیا جاسکتا ہے جو آسانی سے قابل فہم ہوں۔ اگر آپ کی زبان میں کسی مخصوص لفظ کے لیے ایک ہی معنی کے ساتھ متعدد ممکنہ ترجمے ہیں، تو بہترین آپشن اکثر سب سے چھوٹا لفظ ہوتا ہے جو معنی کو واضح طور پر ظاہر کرتا ہے۔ + +## تحریری نظام {#writing-system} + +Ethereum.org متعدد زبانوں میں دستیاب ہے، جو لاطینی کے متبادل تحریری نظام (یا تحریری اسکرپٹس) کا استعمال کرتی ہیں۔ + +تمام مواد کا ترجمہ آپ کی زبان کے صحیح تحریری نظام کا استعمال کرتے ہوئے کیا جانا چاہیے، اور اس میں لاطینی حروف کا استعمال کرتے ہوئے لکھے گئے کوئی بھی الفاظ شامل نہیں ہونے چاہئیں۔ + +مواد کا ترجمہ کرتے وقت، آپ کو یہ یقینی بنانا چاہیے کہ ترجمے مستقل ہوں اور ان میں کوئی لاطینی حروف شامل نہ ہوں۔ + +ایک عام غلط فہمی یہ ہے کہ Ethereum کو ہمیشہ لاطینی میں لکھا جانا چاہیے۔ یہ زیادہ تر غلط ہے، براہ کرم اپنی زبان میں Ethereum کی ہجے استعمال کریں (مثلاً چینی میں 以太坊، عربی میں إيثيريوم، وغیرہ)۔ + +**مذکورہ بالا ان زبانوں پر لاگو نہیں ہوتا، جہاں اصولاً خاص ناموں کا ترجمہ نہیں کیا جانا چاہیے۔** + +## صفحہ کے میٹا ڈیٹا کا ترجمہ کرنا {#translating-metadata} + +کچھ صفحات پر میٹا ڈیٹا ہوتا ہے، جیسے 'title'، 'lang'، 'description'، 'sidebar' وغیرہ۔ + +ہم Crowdin پر نئے صفحات اپ لوڈ کرتے وقت وہ مواد چھپا دیتے ہیں جس کا مترجمین کو کبھی ترجمہ نہیں کرنا چاہیے، جس کا مطلب ہے کہ Crowdin میں مترجمین کو نظر آنے والے تمام میٹا ڈیٹا کا ترجمہ کیا جانا چاہیے۔ + +براہ کرم کسی بھی اسٹرنگ کا ترجمہ کرتے وقت خاص طور پر محتاط رہیں جہاں ماخذ متن 'en' ہو۔ یہ اس زبان کی نمائندگی کرتا ہے جس میں صفحہ دستیاب ہے اور اس کا ترجمہ آپ کی زبان کے [ISO لینگویج کوڈ](https://www.andiamo.co.uk/resources/iso-language-codes/) میں کیا جانا چاہیے۔ ان اسٹرنگز کا ترجمہ ہمیشہ لاطینی حروف کا استعمال کرتے ہوئے کیا جانا چاہیے، نہ کہ ہدف کی زبان کے مقامی تحریری اسکرپٹ کا۔ + +اگر آپ کو یقین نہیں ہے کہ کون سا لینگویج کوڈ استعمال کرنا ہے، تو آپ Crowdin میں ٹرانسلیشن میموری چیک کر سکتے ہیں یا Crowdin آن لائن ایڈیٹر میں صفحہ کے URL میں اپنی زبان کا لینگویج کوڈ تلاش کر سکتے ہیں۔ + +سب سے زیادہ بولی جانے والی زبانوں کے لیے لینگویج کوڈز کی کچھ مثالیں: + +- عربی - ar +- آسان چینی - zh +- فرانسیسی - fr +- ہندی - hi +- ہسپانوی - es + +## بیرونی مضامین کے عنوانات {#external-articles} + +کچھ اسٹرنگز میں بیرونی مضامین کے عنوانات ہوتے ہیں۔ ہمارے زیادہ تر ڈیولپر دستاویزات کے صفحات میں مزید پڑھنے کے لیے بیرونی مضامین کے لنکس ہوتے ہیں۔ مضامین کے عنوانات پر مشتمل اسٹرنگز کا ترجمہ کرنا ضروری ہے، چاہے مضمون کی زبان کچھ بھی ہو، تاکہ اپنی زبان میں صفحہ دیکھنے والے وزیٹرز کے لیے زیادہ مستقل صارف کا تجربہ یقینی بنایا جا سکے۔ + +آپ ذیل میں کچھ مثالیں دیکھ سکتے ہیں کہ یہ اسٹرنگز مترجمین کے لیے کیسی دکھتی ہیں اور ان کی شناخت کیسے کی جائے (مضامین کے لنکس زیادہ تر ان صفحات کے نیچے 'مزید پڑھیں' سیکشن میں مل سکتے ہیں): + +![سائڈبار میں مضمون کے عنوانات.png](./article-titles-in-sidebar.png) +![ایڈیٹر میں مضمون کے عنوانات.png](./article-titles-in-editor.png) + +## Crowdin کی وارننگز {#crowdin-warnings} + +Crowdin میں ایک بلٹ ان فیچر ہے جو مترجمین کو خبردار کرتا ہے جب وہ کوئی غلطی کرنے والے ہوں۔ اگر آپ ماخذ سے کوئی ٹیگ شامل کرنا بھول جاتے ہیں، ان عناصر کا ترجمہ کرتے ہیں جن کا ترجمہ نہیں کیا جانا چاہیے، کئی لگاتار خالی جگہیں شامل کرتے ہیں، آخری وقفہ کاری بھول جاتے ہیں، وغیرہ، تو Crowdin آپ کے ترجمے کو محفوظ کرنے سے پہلے خود بخود آپ کو اس کے بارے میں خبردار کرے گا۔ +اگر آپ کو ایسی کوئی وارننگ نظر آتی ہے، تو براہ کرم واپس جائیں اور تجویز کردہ ترجمے کو دوبارہ چیک کریں۔ + +**ان وارننگز کو کبھی نظر انداز نہ کریں، کیونکہ ان کا عام طور پر مطلب ہوتا ہے کہ کچھ غلط ہے، یا ترجمہ میں ماخذ متن کا ایک اہم حصہ غائب ہے۔** + +جب آپ اپنے ترجمے میں کوئی ٹیگ شامل کرنا بھول جاتے ہیں تو Crowdin کی وارننگ کی ایک مثال: +![Crowdin وارننگ کی مثال](./crowdin-warning-example.png) + +## ٹیگز اور کوڈ کے ٹکڑوں سے نمٹنا {#dealing-with-tags} + +بہت سارے ماخذ مواد میں ٹیگز اور متغیرات ہوتے ہیں، جو Crowdin ایڈیٹر میں پیلے رنگ میں نمایاں ہوتے ہیں۔ یہ مختلف افعال انجام دیتے ہیں اور ان سے صحیح طریقے سے نمٹا جانا چاہیے۔ + +**Crowdin کی سیٹنگز** + +ٹیگز کا نظم کرنا اور انہیں براہ راست ماخذ سے کاپی کرنا آسان بنانے کے لیے، ہم Crowdin ایڈیٹر میں اپنی سیٹنگز کو تبدیل کرنے کی تجویز کرتے ہیں۔ + +1. سیٹنگز کھولیں + ![ایڈیٹر میں سیٹنگز کیسے کھولیں](./editor-settings.png) + +2. 'HTML tags displaying' سیکشن تک نیچے اسکرول کریں + +3. 'Hide' کو منتخب کریں + ![براہ کرم 'Hide' کو منتخب کریں](./hide-tags.png) + +4. 'Save' پر کلک کریں + +اس آپشن کو منتخب کرنے سے، مکمل ٹیگ کا متن اب نہیں دکھایا جائے گا، اور اس کی جگہ ایک نمبر لے لے گا۔ +ترجمہ کرتے وقت، اس ٹیگ پر کلک کرنے سے خود بخود وہی ٹیگ ترجمہ کے فیلڈ میں کاپی ہو جائے گا۔ + +**لنکس** + +آپ کو ethereum.org یا دیگر ویب سائٹس کے صفحات کے مکمل لنکس نظر آ سکتے ہیں۔ + +یہ ماخذ کے یکساں ہونے چاہئیں اور انہیں تبدیل یا ترجمہ نہیں کیا جانا چاہیے۔ اگر آپ کسی لنک کا ترجمہ کرتے ہیں یا اسے کسی بھی طرح سے تبدیل کرتے ہیں، یہاں تک کہ اس کا صرف ایک حصہ ہٹاتے ہیں، جیسے کہ سلیش (/)، تو اس سے ٹوٹے ہوئے اور ناقابل استعمال لنکس بن جائیں گے۔ + +لنکس سے نمٹنے کا بہترین طریقہ یہ ہے کہ انہیں براہ راست ماخذ سے کاپی کریں، یا تو ان پر کلک کرکے یا ‘Copy Source’ بٹن (Alt+C) کا استعمال کرکے۔ + +![لنک کی مثال.png](./example-of-link.png) + +لنکس ماخذ متن میں ٹیگز کی شکل میں بھی ظاہر ہوتے ہیں (یعنی `<0>` ``)۔ اگر آپ ٹیگ پر ہوور کرتے ہیں، تو ایڈیٹر اس کا مکمل مواد دکھائے گا - کبھی کبھی یہ ٹیگز لنکس کی نمائندگی کریں گے۔ + +ماخذ سے لنکس کو کاپی کرنا اور ان کی ترتیب کو تبدیل نہ کرنا بہت ضروری ہے۔ + +اگر ٹیگز کی ترتیب تبدیل ہو جاتی ہے، تو وہ جس لنک کی نمائندگی کرتے ہیں وہ ٹوٹ جائے گا۔ + +![ٹیگز کے اندر لنکس کی مثال.png](./example-of-links-inside-tags.png) + +**ٹیگز اور متغیرات** + +ماخذ متن میں کئی مختلف قسم کے ٹیگز ہوتے ہیں، جنہیں ہمیشہ ماخذ سے کاپی کیا جانا چاہیے اور کبھی تبدیل نہیں کیا جانا چاہیے۔ مذکورہ بالا کی طرح، ترجمہ میں ان ٹیگز کی ترتیب بھی ماخذ کی طرح ہی رہنی چاہیے۔ + +ٹیگز میں ہمیشہ ایک اوپننگ اور ایک کلوزنگ ٹیگ ہوتا ہے۔ زیادہ تر معاملات میں، اوپننگ اور کلوزنگ ٹیگز کے درمیان متن کا ترجمہ کیا جانا چاہیے۔ + +مثال: ``غیر مرکزی`` + +`` - _اوپننگ ٹیگ جو متن کو بولڈ بناتا ہے_ + +غیر مرکزی - _قابلِ ترجمہ متن_ + +`` - _کلوزنگ ٹیگ_ + +![ 'strong' ٹیگز کی مثال.png](./example-of-strong-tags.png) + +کوڈ کے ٹکڑوں کو دوسرے ٹیگز سے تھوڑا مختلف طریقے سے نمٹا جانا چاہیے، کیونکہ ان میں وہ کوڈ ہوتا ہے جس کا ترجمہ نہیں کیا جانا چاہیے۔ + +مثال: ``nonce`` + +`` - _اوپننگ ٹیگ، جس میں کوڈ کا ایک ٹکڑا ہوتا ہے_ + +nonce - _ناقابلِ ترجمہ متن_ + +`` - _کلوزنگ ٹیگ_ + +![کوڈ کے ٹکڑوں کی مثال.png](./example-of-code-snippets.png) + +ماخذ متن میں مختصر ٹیگز بھی ہوتے ہیں، جن میں صرف نمبر ہوتے ہیں، جس کا مطلب ہے کہ ان کا کام فوری طور پر واضح نہیں ہوتا۔ آپ ان ٹیگز پر ہوور کرکے دیکھ سکتے ہیں کہ وہ کون سا کام انجام دیتے ہیں۔ + +نیچے دی گئی مثال میں، آپ دیکھ سکتے ہیں کہ `<0>` ٹیگ پر ہوور کرنے سے یہ ظاہر ہوتا ہے کہ یہ `` کی نمائندگی کرتا ہے اور اس میں کوڈ کا ایک ٹکڑا ہے، لہذا ان ٹیگز کے اندر موجود مواد کا ترجمہ نہیں کیا جانا چاہیے۔ + +![مبہم ٹیگز کی مثال.png](./example-of-ambiguous-tags.png) + +## مختصر بمقابلہ مکمل شکلیں/مخففات {#short-vs-full-forms} + +ویب سائٹ پر بہت سے مخففات استعمال کیے گئے ہیں، مثلاً، dapps، NFT، DAO، DeFi، وغیرہ۔ یہ مخففات عام طور پر انگریزی میں استعمال ہوتے ہیں اور ویب سائٹ پر آنے والے زیادہ تر لوگ ان سے واقف ہیں۔ + +چونکہ عام طور پر دوسری زبانوں میں ان کے قائم شدہ ترجمے نہیں ہوتے ہیں، ان اور اسی طرح کی اصطلاحات سے نمٹنے کا بہترین طریقہ یہ ہے کہ مکمل شکل کا وضاحتی ترجمہ فراہم کیا جائے، اور بریکٹ میں انگریزی مخفف شامل کیا جائے۔ + +ان مخففات کا ترجمہ نہ کریں، کیونکہ زیادہ تر لوگ ان سے واقف نہیں ہوں گے، اور مقامی ورژن زیادہ تر وزیٹرز کے لیے زیادہ معنی نہیں رکھیں گے۔ + +dapps کا ترجمہ کرنے کا طریقہ کی مثال: + +- غیر مرکزی ایپلیکیشنز (dapps) → _ترجمہ شدہ مکمل شکل (بریکٹ میں انگریزی مخفف)_ + +## قائم شدہ ترجمے کے بغیر اصطلاحات {#terms-without-established-translations} + +کچھ اصطلاحات کے دوسری زبانوں میں قائم شدہ ترجمے نہیں ہو سکتے ہیں، اور وہ اصل انگریزی اصطلاح سے وسیع پیمانے پر جانی جاتی ہیں۔ ایسی اصطلاحات میں زیادہ تر نئے تصورات شامل ہیں، جیسے proof-of-work، proof-of-stake، Beacon Chain، staking، وغیرہ۔ + +اگرچہ ان اصطلاحات کا ترجمہ غیر فطری لگ سکتا ہے، کیونکہ انگریزی ورژن عام طور پر دوسری زبانوں میں بھی استعمال ہوتا ہے، لیکن یہ انتہائی سفارش کی جاتی ہے کہ ان کا ترجمہ کیا جائے۔ + +ان کا ترجمہ کرتے وقت، تخلیقی بننے، وضاحتی ترجمے استعمال کرنے، یا صرف ان کا لفظی ترجمہ کرنے میں آزاد محسوس کریں۔ + +**زیادہ تر اصطلاحات کا ترجمہ کرنے کی وجہ، کچھ کو انگریزی میں چھوڑنے کے بجائے، یہ حقیقت ہے کہ یہ نئی اصطلاحات مستقبل میں مزید پھیل جائیں گی، کیونکہ زیادہ لوگ Ethereum اور متعلقہ ٹیکنالوجیز کا استعمال شروع کر دیں گے۔** **اگر ہم دنیا بھر سے مزید لوگوں کو اس جگہ پر لانا چاہتے ہیں، تو ہمیں زیادہ سے زیادہ زبانوں میں قابل فہم اصطلاحات فراہم کرنے کی ضرورت ہے، چاہے ہمیں اسے خود ہی بنانا پڑے۔** + +## بٹنز اور CTAs {#buttons-and-ctas} + +ویب سائٹ پر متعدد بٹنز ہیں، جن کا ترجمہ دوسرے مواد سے مختلف طریقے سے کیا جانا چاہیے۔ + +بٹن کا متن زیادہ تر اسٹرنگز سے منسلک سیاق و سباق کے اسکرین شاٹس کو دیکھ کر، یا ایڈیٹر میں سیاق و سباق کو چیک کرکے پہچانا جاسکتا ہے، جس میں ‘’button’’ کا جملہ شامل ہوتا ہے۔ + +بٹنز کے ترجمے جتنے ممکن ہو مختصر ہونے چاہئیں، تاکہ فارمیٹنگ میں عدم مطابقت سے بچا جا سکے۔ مزید برآں، بٹن کے ترجمے لازمی ہونے چاہئیں، یعنی، ایک حکم یا درخواست پیش کریں۔ + +![بٹن کیسے تلاش کریں.png](./how-to-find-a-button.png) + +## شمولیت کے لیے ترجمہ کرنا {#translating-for-inclusivity} + +Ethereum.org پر آنے والے دنیا بھر سے اور مختلف پس منظر سے آتے ہیں۔ لہذا ویب سائٹ پر زبان غیر جانبدار، سب کے لیے خوش آئند اور غیر خصوصی ہونی چاہیے۔ + +اس کا ایک اہم پہلو صنفی غیر جانبداری ہے۔ یہ خطاب کا رسمی طریقہ استعمال کرکے، اور ترجمے میں کسی بھی جنس سے متعلق مخصوص الفاظ سے گریز کرکے آسانی سے حاصل کیا جاسکتا ہے۔ + +شمولیت کی ایک اور شکل عالمی سامعین کے لیے ترجمہ کرنے کی کوشش کرنا ہے، جو کسی ملک، نسل یا علاقے کے لیے مخصوص نہ ہو۔ + +آخر میں، زبان تمام سامعین اور عمروں کے لیے موزوں ہونی چاہیے۔ + +## زبان سے متعلق مخصوص ترجمے {#language-specific-translations} + +ترجمہ کرتے وقت، یہ ضروری ہے کہ آپ اپنی زبان میں استعمال ہونے والے گرامر کے اصولوں، روایات اور فارمیٹنگ کی پیروی کریں، بجائے اس کے کہ ماخذ سے کاپی کریں۔ ماخذ متن انگریزی گرامر کے اصولوں اور روایات کی پیروی کرتا ہے، جو بہت سی دوسری زبانوں پر لاگو نہیں ہوتا۔ + +آپ کو اپنی زبان کے اصولوں سے آگاہ ہونا چاہیے اور اسی کے مطابق ترجمہ کرنا چاہیے۔ اگر آپ کو مدد کی ضرورت ہے، تو ہم سے رابطہ کریں اور ہم آپ کو اپنی زبان میں ان عناصر کو استعمال کرنے کے طریقے کے بارے میں کچھ وسائل تلاش کرنے میں مدد کریں گے۔ + +کچھ مثالیں جن پر خاص طور پر دھیان دینا ہے: + +### وقفہ کاری، فارمیٹنگ {#punctuation-and-formatting} + +**بڑے حروف کا استعمال** + +- مختلف زبانوں میں بڑے حروف کے استعمال میں بہت فرق ہے۔ +- انگریزی میں، عنوانات اور ناموں، مہینوں اور دنوں، زبانوں کے ناموں، تعطیلات وغیرہ میں تمام الفاظ کو بڑے حروف میں لکھنا عام ہے۔ بہت سی دوسری زبانوں میں، یہ گرامر کے لحاظ سے غلط ہے، کیونکہ ان کے بڑے حروف کے استعمال کے اصول مختلف ہیں۔ +- کچھ زبانوں میں ذاتی ضمیروں، اسموں، اور کچھ صفتوں کو بڑے حروف میں لکھنے کے اصول بھی ہیں، جو انگریزی میں بڑے حروف میں نہیں لکھے جاتے۔ + +**خالی جگہ** + +- املا کے اصول ہر زبان کے لیے خالی جگہوں کے استعمال کی وضاحت کرتے ہیں۔ چونکہ خالی جگہیں ہر جگہ استعمال ہوتی ہیں، اس لیے یہ اصول کچھ سب سے زیادہ مخصوص ہیں، اور خالی جگہیں کچھ سب سے زیادہ غلط ترجمہ شدہ عناصر ہیں۔ +- انگریزی اور دیگر زبانوں کے درمیان خالی جگہ کے استعمال میں کچھ عام فرق: + - پیمائش کی اکائیوں اور کرنسیوں سے پہلے خالی جگہ (مثلاً USD، EUR، kB، MB) + - ڈگری کے نشانات سے پہلے خالی جگہ (مثلاً °C، ℉) + - کچھ وقفہ کاری کے نشانات سے پہلے خالی جگہ، خاص طور پر حذف کا نشان (…)۔ + - سلیش (/) سے پہلے اور بعد میں خالی جگہ + +**فہرستیں** + +- ہر زبان میں فہرستیں لکھنے کے لیے اصولوں کا ایک متنوع اور پیچیدہ مجموعہ ہوتا ہے۔ یہ انگریزی سے نمایاں طور پر مختلف ہو سکتے ہیں۔ +- کچھ زبانوں میں، ہر نئی لائن کے پہلے لفظ کو بڑے حروف میں لکھنے کی ضرورت ہوتی ہے، جبکہ دیگر میں، نئی لائنیں چھوٹے حروف سے شروع ہونی چاہئیں۔ بہت سی زبانوں میں فہرستوں میں بڑے حروف کے استعمال کے بارے میں مختلف اصول بھی ہیں، جو ہر لائن کی لمبائی پر منحصر ہیں۔ +- یہی بات لائن آئٹمز کی وقفہ کاری پر بھی لاگو ہوتی ہے۔ فہرستوں میں آخری وقفہ کاری ایک فل اسٹاپ (**.**)، کوما (**,**)، یا سیمی کالون (**;**) ہو سکتا ہے، جو زبان پر منحصر ہے۔ + +**اقتباس کے نشانات** + +- زبانیں بہت سے مختلف اقتباس کے نشانات استعمال کرتی ہیں۔ ماخذ سے انگریزی اقتباس کے نشانات کو صرف کاپی کرنا اکثر غلط ہوتا ہے۔ +- اقتباس کے نشانات کی کچھ عام اقسام میں شامل ہیں: + - „مثال کا متن“ + - ‚مثال کا متن’ + - »مثال کا متن« + - “مثال کا متن” + - ‘مثال کا متن’ + - «مثال کا متن» + +**ہائیفن اور ڈیش** + +- انگریزی میں، ہائیفن (-) کا استعمال الفاظ یا کسی لفظ کے مختلف حصوں کو جوڑنے کے لیے کیا جاتا ہے، جبکہ ڈیش (–) کا استعمال کسی رینج یا وقفے کی نشاندہی کے لیے کیا جاتا ہے۔ +- بہت سی زبانوں میں ہائیفن اور ڈیش استعمال کرنے کے مختلف اصول ہیں جن کا خیال رکھنا چاہیے۔ + +### فارمیٹس {#formats} + +**نمبرز** + +- مختلف زبانوں میں نمبر لکھنے میں بنیادی فرق ڈیسیمل اور ہزاروں کے لیے استعمال ہونے والا الگ کرنے والا ہے۔ ہزاروں کے لیے، یہ ایک فل اسٹاپ، کوما یا خالی جگہ ہو سکتا ہے۔ اسی طرح، کچھ زبانیں ڈیسیمل پوائنٹ کا استعمال کرتی ہیں، جبکہ دیگر ڈیسیمل کوما کا استعمال کرتی ہیں۔ + - بڑے نمبروں کی کچھ مثالیں: + - انگریزی – **1,000.50** + - ہسپانوی – **1.000,50** + - فرانسیسی – **1 000,50** +- نمبروں کا ترجمہ کرتے وقت ایک اور اہم غور فیصد کی علامت ہے۔ اسے مختلف طریقوں سے لکھا جا سکتا ہے: **100%**، **100 %** یا **%100**۔ +- آخر میں، منفی نمبروں کو زبان کے لحاظ سے مختلف طریقے سے دکھایا جا سکتا ہے: -100، 100-، (100) یا [100]۔ + +**تاریخیں** + +- تاریخوں کا ترجمہ کرتے وقت، زبان کی بنیاد پر متعدد غور و فکر اور اختلافات ہوتے ہیں۔ ان میں تاریخ کا فارمیٹ، الگ کرنے والا، بڑے حروف کا استعمال اور لیڈنگ زیرو شامل ہیں۔ پوری لمبائی اور عددی تاریخوں کے درمیان بھی فرق ہیں۔ + - مختلف تاریخ کے فارمیٹس کی کچھ مثالیں: + - انگریزی UK (dd/mm/yyyy) – 1st January, 2022 + - انگریزی US (mm/dd/yyyy) – January 1st, 2022 + - چینی (yyyy-mm-dd) – 2022 年 1 月 1 日 + - فرانسیسی (dd/mm/yyyy) – 1er janvier 2022 + - اطالوی (dd/mm/yyyy) – 1º gennaio 2022 + - جرمن (dd/mm/yyyy) – 1. Januar 2022 + +**کرنسیاں** + +- مختلف فارمیٹس، روایات اور تبادلوں کی وجہ سے کرنسیوں کا ترجمہ کرنا مشکل ہو سکتا ہے۔ ایک عمومی اصول کے طور پر، براہ کرم کرنسیوں کو ماخذ کی طرح ہی رکھیں۔ آپ قاری کے فائدے کے لیے بریکٹ میں اپنی مقامی کرنسی اور تبادلہ شامل کر سکتے ہیں۔ +- مختلف زبانوں میں کرنسیاں لکھنے میں بنیادی فرق میں علامت کی جگہ، ڈیسیمل کوما بمقابلہ ڈیسیمل پوائنٹس، خالی جگہ، اور مخففات بمقابلہ علامتیں شامل ہیں۔ + - علامت کی جگہ: $100 یا 100$ + - ڈیسیمل کوما بمقابلہ ڈیسیمل پوائنٹس: 100,50$ یا 100.50$ + - خالی جگہ: 100$ یا 100 $ + - مخففات بمقابلہ علامتیں: 100 $ یا 100 USD + +**پیمائش کی اکائیاں** + +- ایک عمومی اصول کے طور پر، براہ کرم پیمائش کی اکائیوں کو ماخذ کے مطابق رکھیں۔ اگر آپ کا ملک ایک مختلف نظام استعمال کرتا ہے، تو آپ بریکٹ میں تبادلہ شامل کر سکتے ہیں۔ +- پیمائش کی اکائیوں کی لوکلائزیشن کے علاوہ، یہ بھی نوٹ کرنا ضروری ہے کہ زبانیں ان اکائیوں سے کیسے نمٹتی ہیں۔ بنیادی فرق نمبر اور اکائی کے درمیان خالی جگہ ہے، جو زبان کی بنیاد پر مختلف ہو سکتی ہے۔ اس کی مثالوں میں 100kB بمقابلہ 100 kB یا 50ºF بمقابلہ 50 ºF شامل ہیں۔ + +## نتیجہ {#conclusion} + +ethereum.org کا ترجمہ کرنا Ethereum کے مختلف پہلوؤں کے بارے میں جاننے کا ایک بہترین موقع ہے۔ + +ترجمہ کرتے وقت، جلدی نہ کریں۔ آرام سے کریں اور لطف اٹھائیں! + +ترجمہ پروگرام میں شامل ہونے اور ویب سائٹ کو وسیع تر سامعین تک قابل رسائی بنانے میں ہماری مدد کرنے کے لیے آپ کا شکریہ۔ Ethereum کمیونٹی عالمی ہے، اور ہمیں خوشی ہے کہ آپ اس کا حصہ ہیں! diff --git a/public/content/translations/ur/dao/index.md b/public/content/translations/ur/dao/index.md new file mode 100644 index 00000000000..d5c9200553e --- /dev/null +++ b/public/content/translations/ur/dao/index.md @@ -0,0 +1,167 @@ +--- +title: "DAO کیا ہے؟" +metaTitle: "DAO کیا ہے؟ | وکندریقرت خود مختار تنظیم" +description: "ایتھیریئم پر DAOs کا ایک جائزہ" +lang: ur-in +template: use-cases +emoji: ":handshake:" +sidebarDepth: 2 +image: /images/use-cases/dao-2.png +alt: "ایک تجویز پر ووٹنگ کرتے ہوئے DAO کی نمائندگی۔" +summaryPoint1: "مرکزی قیادت کے بغیر اراکین کی ملکیت والی کمیونٹیز۔" +summaryPoint2: "انٹرنیٹ پر اجنبیوں کے ساتھ تعاون کرنے کا ایک محفوظ طریقہ۔" +summaryPoint3: "کسی خاص مقصد کے لیے فنڈز دینے کے لیے ایک محفوظ جگہ۔" +--- + +## DAOs کیا ہیں؟ {#what-are-daos} + +DAO ایک مشترکہ ملکیت والی تنظیم ہے جو ایک مشترکہ مشن کی سمت میں کام کرتی ہے۔ + +DAOs ہمیں فنڈز یا آپریشنز کا انتظام کرنے کے لیے کسی خیر خواہ رہنما پر بھروسہ کیے بغیر دنیا بھر کے ہم خیال لوگوں کے ساتھ کام کرنے کی اجازت دیتے ہیں۔ کوئی ایسا CEO نہیں ہے جو اپنی مرضی سے فنڈز خرچ کر سکے یا کوئی CFO جو کھاتوں میں ہیرا پھیری کر سکے۔ اس کے بجائے، کوڈ میں شامل بلاک چین پر مبنی اصول یہ بتاتے ہیں کہ تنظیم کیسے کام کرتی ہے اور فنڈز کیسے خرچ کیے جاتے ہیں۔ + +ان کے پاس بلٹ ان خزانے ہوتے ہیں جن تک گروپ کی منظوری کے بغیر کسی کو رسائی حاصل کرنے کا اختیار نہیں ہوتا ہے۔ فیصلے تجاویز اور ووٹنگ کے ذریعے کیے جاتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ تنظیم میں ہر ایک کی آواز ہو، اور سب کچھ شفاف طریقے سے [آن چین](/glossary/#onchain) ہوتا ہے۔ + +## ہمیں DAOs کی ضرورت کیوں ہے؟ {#why-dao} + +کسی ایسے شخص کے ساتھ تنظیم شروع کرنا جس میں فنڈنگ اور پیسہ شامل ہو، ان لوگوں پر بہت زیادہ اعتماد کی ضرورت ہوتی ہے جن کے ساتھ آپ کام کر رہے ہیں۔ لیکن کسی ایسے شخص پر بھروسہ کرنا مشکل ہے جس سے آپ نے صرف انٹرنیٹ پر بات چیت کی ہو۔ DAOs کے ساتھ آپ کو گروپ میں کسی اور پر بھروسہ کرنے کی ضرورت نہیں ہے، صرف DAO کے کوڈ پر، جو 100% شفاف ہے اور کوئی بھی اس کی تصدیق کر سکتا ہے۔ + +یہ عالمی تعاون اور تال میل کے لیے بہت سے نئے مواقع کھولتا ہے۔ + +### ایک موازنہ {#dao-comparison} + +| DAO | ایک روایتی تنظیم | +| ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | +| عام طور پر فلیٹ، اور مکمل طور پر جمہوری۔ | عام طور پر درجہ بندی پر مبنی۔ | +| کسی بھی تبدیلی کو نافذ کرنے کے لیے اراکین کی طرف سے ووٹنگ کی ضرورت ہوتی ہے۔ | ساخت کے لحاظ سے، تبدیلیاں ایک واحد فریق سے طلب کی جا سکتی ہیں، یا ووٹنگ کی پیشکش کی جا سکتی ہے۔ | +| ووٹوں کی گنتی کی جاتی ہے، اور نتیجہ بغیر کسی بھروسہ مند ثالث کے خود بخود نافذ ہو جاتا ہے۔ | اگر ووٹنگ کی اجازت ہو، تو ووٹوں کی گنتی اندرونی طور پر کی جاتی ہے، اور ووٹنگ کے نتیجے کو دستی طور پر سنبھالنا ضروری ہے۔ | +| پیش کردہ خدمات کو وکندریقرت طریقے سے خود بخود سنبھالا جاتا ہے (مثال کے طور پر فلاحی فنڈز کی تقسیم)۔ | اس کے لیے انسانی ہینڈلنگ، یا مرکزی طور پر کنٹرول شدہ آٹومیشن کی ضرورت ہوتی ہے، جس میں ہیرا پھیری کا خطرہ ہوتا ہے۔ | +| تمام سرگرمیاں شفاف اور مکمل طور پر عوامی ہوتی ہیں۔ | سرگرمی عام طور پر نجی ہوتی ہے، اور عوام کے لیے محدود ہوتی ہے۔ | + +### DAO کی مثالیں {#dao-examples} + +اسے مزید سمجھنے میں مدد کے لیے، یہاں کچھ مثالیں ہیں کہ آپ DAO کا استعمال کیسے کر سکتے ہیں: + +- **ایک خیراتی ادارہ** – آپ دنیا میں کسی سے بھی عطیات قبول کر سکتے ہیں اور ووٹ دے سکتے ہیں کہ کن مقاصد کے لیے فنڈ فراہم کیا جائے۔ +- **اجتماعی ملکیت** – آپ طبعی یا ڈیجیٹل اثاثے خرید سکتے ہیں اور اراکین ان کے استعمال کے طریقے پر ووٹ دے سکتے ہیں۔ +- **وینچرز اور گرانٹس** – آپ ایک وینچر فنڈ بنا سکتے ہیں جو سرمایہ کاری کے سرمائے کو جمع کرتا ہے اور ان وینچرز پر ووٹ دیتا ہے جن کی حمایت کرنی ہے۔ واپس کی گئی رقم بعد میں DAO کے اراکین میں دوبارہ تقسیم کی جا سکتی ہے۔ + + + +## DAOs کیسے کام کرتے ہیں؟ {#how-daos-work} + +DAO کی بنیاد اس کا [اسمارٹ کنٹریکٹ](/glossary/#smart-contract) ہے جو تنظیم کے اصول وضع کرتا ہے اور گروپ کا خزانہ محفوظ رکھتا ہے۔ ایک بار جب کنٹریکٹ ایتھیریئم پر لائیو ہو جاتا ہے، تو کوئی بھی ووٹ کے علاوہ اصولوں کو تبدیل نہیں کر سکتا۔ اگر کوئی ایسا کچھ کرنے کی کوشش کرتا ہے جو کوڈ میں موجود اصولوں اور منطق کے تحت نہیں آتا ہے، تو وہ ناکام ہو جائے گا۔ اور چونکہ خزانہ بھی اسمارٹ کنٹریکٹ کے ذریعے طے کیا جاتا ہے، اس کا مطلب ہے کہ گروپ کی منظوری کے بغیر کوئی بھی پیسہ خرچ نہیں کر سکتا۔ اس کا مطلب ہے کہ DAOs کو کسی مرکزی اتھارٹی کی ضرورت نہیں ہے۔ اس کے بجائے، گروپ اجتماعی طور پر فیصلے کرتا ہے، اور ووٹ منظور ہونے پر ادائیگیاں خود بخود مجاز ہو جاتی ہیں۔ + +یہ اس لیے ممکن ہے کیونکہ ایتھیریئم پر لائیو ہونے کے بعد اسمارٹ کنٹریکٹس میں چھیڑ چھاڑ نہیں کی جا سکتی۔ آپ صرف کوڈ (DAOs کے اصول) میں لوگوں کے دیکھے بغیر ترمیم نہیں کر سکتے کیونکہ سب کچھ عوامی ہے۔ + +## ایتھیریئم اور DAOs {#ethereum-and-daos} + +ایتھیریئم کئی وجوہات کی بنا پر DAOs کے لیے ایک بہترین بنیاد ہے: + +- ایتھیریئم کا اپنا اتفاق رائے وکندریقرت اور اتنا قائم ہے کہ تنظیمیں نیٹ ورک پر بھروسہ کر سکیں۔ +- اسمارٹ کنٹریکٹ کوڈ کو ایک بار لائیو ہونے کے بعد تبدیل نہیں کیا جا سکتا، یہاں تک کہ اس کے مالکان بھی۔ یہ DAO کو ان اصولوں کے مطابق چلنے کی اجازت دیتا ہے جن کے ساتھ اسے پروگرام کیا گیا تھا۔ +- اسمارٹ کنٹریکٹس فنڈز بھیج/وصول کر سکتے ہیں۔ اس کے بغیر آپ کو گروپ فنڈز کا انتظام کرنے کے لیے ایک بھروسہ مند ثالث کی ضرورت ہوگی۔ +- ایتھیریئم کمیونٹی مسابقتی سے زیادہ باہمی تعاون پر مبنی ثابت ہوئی ہے، جس سے بہترین طریقوں اور معاون نظاموں کو تیزی سے ابھرنے کا موقع ملتا ہے۔ + +## DAO گورننس {#dao-governance} + +DAO کو چلانے میں بہت سے غور و فکر ہوتے ہیں، جیسے کہ ووٹنگ اور تجاویز کیسے کام کرتی ہیں۔ + +### نمائندگی {#governance-delegation} + +نمائندگی نمائندہ جمہوریت کے DAO ورژن کی طرح ہے۔ ٹوکن ہولڈرز ان صارفین کو ووٹ تفویض کرتے ہیں جو خود کو نامزد کرتے ہیں اور پروٹوکول کی نگرانی اور باخبر رہنے کا عہد کرتے ہیں۔ + +#### ایک مشہور مثال {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – ENS ہولڈرز اپنے ووٹوں کو کمیونٹی کے فعال اراکین کو اپنی نمائندگی کے لیے تفویض کر سکتے ہیں۔ + +### خودکار ٹرانزیکشن گورننس {#governance-example} + +بہت سے DAOs میں، اگر اراکین کا ایک کورم مثبت ووٹ دیتا ہے تو ٹرانزیکشنز خود بخود عمل میں آ جائیں گی۔ + +#### ایک مشہور مثال {#governance-example} + +[Nouns](https://nouns.wtf) – Nouns DAO میں، ایک ٹرانزیکشن خود بخود عمل میں آ جاتا ہے اگر ووٹوں کا ایک کورم پورا ہو جائے اور اکثریت مثبت ووٹ دے، جب تک کہ بانیان اسے ویٹو نہ کریں۔ + +### ملٹی سگ گورننس {#governance-example} + +جبکہ DAOs کے ہزاروں ووٹنگ اراکین ہو سکتے ہیں، فنڈز ایک [والیٹ](/glossary/#wallet) میں رہ سکتے ہیں جو 5-20 فعال کمیونٹی اراکین کے اشتراک سے ہوتا ہے جو قابل اعتماد ہیں اور عام طور پر ڈاکسڈ ہوتے ہیں (عوامی شناختیں کمیونٹی کو معلوم ہوتی ہیں)۔ ووٹ کے بعد، [ملٹی سگ](/glossary/#multisig) دستخط کنندگان کمیونٹی کی مرضی پر عمل درآمد کرتے ہیں۔ + +## DAO کے قوانین {#dao-laws} + +1977 میں، وایومنگ نے LLC ایجاد کیا، جو کاروباریوں کی حفاظت کرتا ہے اور ان کی ذمہ داری کو محدود کرتا ہے۔ حال ہی میں، انہوں نے DAO قانون کی پہل کی جو DAOs کے لیے قانونی حیثیت قائم کرتا ہے۔ فی الحال وایومنگ، ورمونٹ، اور ورجن آئی لینڈز میں کسی نہ کسی شکل میں DAO قوانین موجود ہیں۔ + +### ایک مشہور مثال {#law-example} + +[CityDAO](https://citizen.citydao.io/) – CityDAO نے یلوسٹون نیشنل پارک کے قریب 40 ایکڑ زمین خریدنے کے لیے وایومنگ کے DAO قانون کا استعمال کیا۔ + +## DAO کی رکنیت {#dao-membership} + +DAO کی رکنیت کے لیے مختلف ماڈل ہیں۔ رکنیت یہ طے کر سکتی ہے کہ ووٹنگ کیسے کام کرتی ہے اور DAO کے دیگر اہم حصے کیا ہیں۔ + +### ٹوکن پر مبنی رکنیت {#token-based-membership} + +عام طور پر مکمل طور پر [بغیر اجازت](/glossary/#permissionless)، استعمال شدہ ٹوکن پر منحصر ہے۔ زیادہ تر یہ گورننس ٹوکنز بغیر اجازت کے [وکندریقرت ایکسچینج](/glossary/#dex) پر ٹریڈ کیے جا سکتے ہیں۔ دیگر کو لیکویڈیٹی فراہم کرکے یا کسی اور 'پروف-آف-ورک' کے ذریعے حاصل کیا جانا چاہیے۔ کسی بھی طرح سے، صرف ٹوکن رکھنے سے ووٹنگ تک رسائی مل جاتی ہے۔ + +_عام طور پر وسیع وکندریقرت پروٹوکولز اور/یا خود ٹوکنز کو چلانے کے لیے استعمال ہوتا ہے۔_ + +#### ایک مشہور مثال {#token-example} + +[MakerDAO](https://makerdao.com) – MakerDAO کا ٹوکن MKR وکندریقرت ایکسچینجز پر وسیع پیمانے پر دستیاب ہے اور کوئی بھی میکر پروٹوکول کے مستقبل پر ووٹنگ کی طاقت حاصل کرنے کے لیے اسے خرید سکتا ہے۔ + +### حصص پر مبنی رکنیت {#share-based-membership} + +حصص پر مبنی DAOs زیادہ اجازت یافتہ ہوتے ہیں، لیکن پھر بھی کافی کھلے ہوتے ہیں۔ کوئی بھی ممکنہ رکن DAO میں شامل ہونے کی تجویز پیش کر سکتا ہے، عام طور پر ٹوکنز یا کام کی صورت میں کچھ قیمت پیش کر کے۔ حصص براہ راست ووٹنگ کی طاقت اور ملکیت کی نمائندگی کرتے ہیں۔ اراکین کسی بھی وقت خزانے میں اپنے متناسب حصے کے ساتھ باہر نکل سکتے ہیں۔ + +_عام طور پر زیادہ قریبی، انسان مرکز تنظیموں جیسے خیراتی اداروں، ورکر کلیکٹیوز، اور انویسٹمنٹ کلبز کے لیے استعمال ہوتا ہے۔ پروٹوکولز اور ٹوکنز کو بھی چلا سکتا ہے۔_ + +#### ایک مشہور مثال {#share-example} + +[MolochDAO](http://molochdao.com/) – MolochDAO ایتھیریئم پروجیکٹس کو فنڈ دینے پر مرکوز ہے۔ انہیں رکنیت کے لیے ایک تجویز کی ضرورت ہوتی ہے تاکہ گروپ یہ اندازہ لگا سکے کہ آیا آپ کے پاس ممکنہ گرانٹیز کے بارے میں باخبر فیصلے کرنے کے لیے ضروری مہارت اور سرمایہ ہے۔ آپ کھلے بازار میں DAO تک رسائی نہیں خرید سکتے۔ + +### شہرت پر مبنی رکنیت {#reputation-based-membership} + +شہرت شرکت کا ثبوت ہے اور DAO میں ووٹنگ کی طاقت دیتی ہے۔ ٹوکن یا شیئر پر مبنی رکنیت کے برعکس، شہرت پر مبنی DAOs میں شراکت داروں کو ملکیت منتقل نہیں کی جاتی۔ شہرت خریدی، منتقل یا تفویض نہیں کی جا سکتی؛ DAO کے اراکین کو شرکت کے ذریعے شہرت حاصل کرنی پڑتی ہے۔ آن چین ووٹنگ بغیر اجازت کے ہوتی ہے اور ممکنہ اراکین آزادانہ طور پر DAO میں شامل ہونے کی تجاویز پیش کر سکتے ہیں اور اپنی شراکت کے بدلے میں انعام کے طور پر شہرت اور ٹوکنز حاصل کرنے کی درخواست کر سکتے ہیں۔ + +_عام طور پر پروٹوکولز اور [dapps](/glossary/#dapp) کی وکندریقرت ترقی اور گورننس کے لیے استعمال ہوتا ہے، لیکن یہ خیراتی اداروں، ورکر کلیکٹیوز، انویسٹمنٹ کلبز وغیرہ جیسی متنوع تنظیموں کے لیے بھی موزوں ہے۔_ + +#### ایک مشہور مثال {#reputation-example} + +[DXdao](https://DXdao.eth.limo) – DXdao 2019 سے وکندریقرت پروٹوکولز اور ایپلیکیشنز کی تعمیر اور گورننس کرنے والا ایک عالمی خود مختار اجتماعی ادارہ تھا۔ اس نے فنڈز کو مربوط کرنے اور ان کا انتظام کرنے کے لیے شہرت پر مبنی گورننس اور [ہولوگرافک اتفاق رائے](/glossary/#holographic-consensus) کا فائدہ اٹھایا، جس کا مطلب ہے کہ کوئی بھی اس کے مستقبل یا گورننس کو متاثر کرنے کے لیے اپنا راستہ نہیں خرید سکتا تھا۔ + +## ایک DAO میں شامل ہوں / شروع کریں {#join-start-a-dao} + +### ایک DAO میں شامل ہوں {#join-a-dao} + +- [ایتھیریئم کمیونٹی DAOs](/community/get-involved/#decentralized-autonomous-organizations-daos) +- [DAOHaus کی DAOs کی فہرست](https://app.daohaus.club/explore) +- [Tally.xyz کی DAOs کی فہرست](https://www.tally.xyz/explore) +- [DeGov.AI کی DAOs کی فہرست](https://apps.degov.ai/) + +### ایک DAO شروع کریں {#start-a-dao} + +- [DAOHaus کے ساتھ ایک DAO طلب کریں](https://app.daohaus.club/summon) +- [Tally کے ساتھ ایک گورنر DAO شروع کریں](https://www.tally.xyz/get-started) +- [Aragon سے چلنے والا ایک DAO بنائیں](https://aragon.org/product) +- [ایک کالونی شروع کریں](https://colony.io/) +- [DAOstack کے ہولوگرافک اتفاق رائے کے ساتھ ایک DAO بنائیں](https://alchemy.daostack.io/daos/create) +- [DeGov لانچر کے ساتھ ایک DAO لانچ کریں](https://docs.degov.ai/integration/deploy) + +## مزید پڑھیں {#further-reading} + +### DAO مضامین {#dao-articles} + +- [DAO کیا ہے؟](https://aragon.org/dao) – [Aragon](https://aragon.org/) +- [House of DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/) +- [DAO کیا ہے اور یہ کس لیے ہے؟](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/) +- [DAO سے چلنے والی ڈیجیٹل کمیونٹی کیسے شروع کریں](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/) +- [DAO کیا ہے؟](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com) +- [ہولوگرافک اتفاق رائے کیا ہے؟](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/) +- [DAOs کارپوریشنز نہیں ہیں: جہاں خود مختار تنظیموں میں وکندریقرت اہمیت رکھتی ہے از وائٹلک](https://vitalik.eth.limo/general/2022/09/20/daos.html) +- [DAOs, DACs, DAs اور مزید: ایک نامکمل اصطلاحات کی گائیڈ](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [Ethereum بلاگ](https://blog.ethereum.org) + +### ویڈیوز {#videos} + +- [کرپٹو میں DAO کیا ہے؟](https://youtu.be/KHm0uUPqmVE) +- [کیا ایک DAO ایک شہر بنا سکتا ہے؟](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/) + + + + diff --git a/public/content/translations/ur/decentralized-identity/index.md b/public/content/translations/ur/decentralized-identity/index.md new file mode 100644 index 00000000000..18c74d08d7a --- /dev/null +++ b/public/content/translations/ur/decentralized-identity/index.md @@ -0,0 +1,218 @@ +--- +title: "غیر مرکزی شناخت" +description: "ڈی سینٹرلائزڈ شناخت کیا ہے، اور یہ کیوں اہمیت رکھتی ہے؟" +lang: ur-in +template: use-cases +emoji: ":id:" +sidebarDepth: 2 +image: /images/eth-gif-cat.png +summaryPoint1: "روایتی شناختی نظاموں نے آپ کے شناخت کنندگان کے اجراء، دیکھ بھال اور کنٹرول کو مرکزی بنا دیا ہے۔" +summaryPoint2: "ڈی سینٹرلائزڈ شناخت مرکزی فریق ثالث پر انحصار کو ختم کرتی ہے۔" +summaryPoint3: "کرپٹو کی بدولت، صارفین کے پاس اب ایک بار پھر اپنے شناخت کنندگان اور تصدیقات کو جاری کرنے، رکھنے اور کنٹرول کرنے کے اوزار ہیں۔" +--- + +شناخت آج آپ کی زندگی کے تقریباً ہر پہلو کی بنیاد ہے۔ آن لائن خدمات کا استعمال، بینک اکاؤنٹ کھولنا، انتخابات میں ووٹ ڈالنا، جائیداد خریدنا، ملازمت حاصل کرنا—ان سبھی چیزوں کے لیے آپ کی شناخت ثابت کرنے کی ضرورت ہوتی ہے۔ + +تاہم، روایتی شناختی نظام طویل عرصے سے مرکزی ثالثوں پر انحصار کرتے ہیں جو آپ کے شناخت کنندگان اور [تصدیقات](/glossary/#attestation) کو جاری کرتے، رکھتے اور کنٹرول کرتے ہیں۔ اس کا مطلب ہے کہ آپ اپنی شناخت سے متعلق معلومات کو کنٹرول نہیں کر سکتے یا یہ فیصلہ نہیں کر سکتے کہ ذاتی طور پر قابل شناخت معلومات (PII) تک کس کی رسائی ہے اور ان فریقوں کو کتنی رسائی حاصل ہے۔ + +ان مسائل کو حل کرنے کے لیے، ہمارے پاس Ethereum جیسے پبلک بلاک چینز پر بنے ڈی سینٹرلائزڈ شناختی نظام موجود ہیں۔ ڈی سینٹرلائزڈ شناخت افراد کو اپنی شناخت سے متعلق معلومات کا نظم کرنے کی اجازت دیتی ہے۔ ڈی سینٹرلائزڈ شناختی حل کے ساتھ، _آپ_ مرکزی حکام، جیسے سروس فراہم کنندگان یا حکومتوں پر انحصار کیے بغیر شناخت کنندگان بنا سکتے ہیں اور اپنی تصدیقات کا دعویٰ اور انعقاد کر سکتے ہیں۔ + +## شناخت کیا ہے؟ {#what-is-identity} + +شناخت کا مطلب ہے کسی فرد کا خود کا احساس، جس کی تعریف منفرد خصوصیات سے ہوتی ہے۔ شناخت سے مراد ایک _فرد_ ہونا ہے، یعنی ایک الگ انسانی وجود۔ شناخت دیگر غیر انسانی اداروں، جیسے کسی تنظیم یا اتھارٹی کا بھی حوالہ دے سکتی ہے۔ + + + +## شناخت کنندگان کیا ہیں؟ {#what-are-identifiers} + +شناخت کنندہ معلومات کا ایک ٹکڑا ہے جو کسی خاص شناخت یا شناخت کی طرف اشارہ کرتا ہے۔ عام شناخت کنندگان میں شامل ہیں: + +- نام +- سوشل سیکورٹی نمبر/ٹیکس آئی ڈی نمبر +- موبائل نمبر +- تاریخ اور جائے پیدائش +- ڈیجیٹل شناختی اسناد، مثلاً، ای میل پتے، صارف نام، اوتار + +شناخت کنندگان کی یہ روایتی مثالیں مرکزی اداروں کے ذریعہ جاری، رکھی اور کنٹرول کی جاتی ہیں۔ آپ کو اپنا نام تبدیل کرنے کے لیے اپنی حکومت سے یا اپنا ہینڈل تبدیل کرنے کے لیے سوشل میڈیا پلیٹ فارم سے اجازت کی ضرورت ہے۔ + +## ڈی سینٹرلائزڈ شناخت کے فوائد {#benefits-of-decentralized-identity} + +1. ڈی سینٹرلائزڈ شناخت شناختی معلومات پر انفرادی کنٹرول کو بڑھاتی ہے۔ مرکزی حکام اور فریق ثالث کی خدمات پر انحصار کیے بغیر ڈی سینٹرلائزڈ شناخت کنندگان اور تصدیقات کی تصدیق کی جا سکتی ہے۔ + +2. ڈی سینٹرلائزڈ شناختی حل صارف کی شناخت کی تصدیق اور انتظام کے لیے ایک بے اعتماد، ہموار، اور رازداری کے تحفظ کا طریقہ فراہم کرتے ہیں۔ + +3. ڈی سینٹرلائزڈ شناخت بلاک چین ٹیکنالوجی کا استعمال کرتی ہے، جو مختلف فریقوں کے درمیان اعتماد پیدا کرتی ہے اور تصدیقات کی صداقت کو ثابت کرنے کے لیے کرپٹوگرافک ضمانتیں فراہم کرتی ہے۔ + +4. ڈی سینٹرلائزڈ شناخت شناختی ڈیٹا کو پورٹیبل بناتی ہے۔ صارفین تصدیقات اور شناخت کنندگان کو موبائل والیٹ میں محفوظ کرتے ہیں اور اپنی پسند کے کسی بھی فریق کے ساتھ شیئر کر سکتے ہیں۔ ڈی سینٹرلائزڈ شناخت کنندگان اور تصدیقات جاری کرنے والی تنظیم کے ڈیٹا بیس میں مقفل نہیں ہیں۔ + +5. ڈی سینٹرلائزڈ شناخت کو ابھرتی ہوئی [زیرو نالج](/glossary/#zk-proof) ٹیکنالوجیز کے ساتھ اچھی طرح کام کرنا چاہیے جو افراد کو یہ ظاہر کیے بغیر کہ وہ چیز کیا ہے، یہ ثابت کرنے کے قابل بنائے گی کہ وہ کسی چیز کے مالک ہیں یا انہوں نے کچھ کیا ہے۔ یہ ووٹنگ جیسی ایپلی کیشنز کے لیے اعتماد اور رازداری کو یکجا کرنے کا ایک طاقتور طریقہ بن سکتا ہے۔ + +6. ڈی سینٹرلائزڈ شناخت [اینٹی سائبل](/glossary/#anti-sybil) میکانزم کو یہ شناخت کرنے کے قابل بناتی ہے کہ کب ایک فرد انسان کسی سسٹم کو گیم کرنے یا سپیم کرنے کے لیے متعدد انسان ہونے کا بہانہ کر رہا ہے۔ + +## ڈی سینٹرلائزڈ شناخت کے استعمال کے معاملات {#decentralized-identity-use-cases} + +ڈی سینٹرلائزڈ شناخت کے بہت سے ممکنہ استعمال کے معاملات ہیں: + +### 1۔ یونیورسل لاگ ان {#universal-dapp-logins} + +ڈی سینٹرلائزڈ شناخت پاس ورڈ پر مبنی لاگ ان کو ڈی سینٹرلائزڈ تصدیق کے ساتھ تبدیل کرنے میں مدد کر سکتی ہے۔ سروس فراہم کنندگان صارفین کو تصدیقات جاری کر سکتے ہیں، جنہیں Ethereum والیٹ میں محفوظ کیا جا سکتا ہے۔ ایک مثال کی تصدیق ایک [NFT](/glossary/#nft) ہوگی جو ہولڈر کو آن لائن کمیونٹی تک رسائی فراہم کرتی ہے۔ + +[ایتھیریم کے ساتھ سائن ان](https://siwe.xyz/) فنکشن پھر سرورز کو صارف کے ایتھیریم اکاؤنٹ کی تصدیق کرنے اور ان کے اکاؤنٹ کے پتے سے مطلوبہ تصدیق حاصل کرنے کے قابل بنائے گا۔ اس کا مطلب ہے کہ صارفین لمبے پاس ورڈ یاد کیے بغیر پلیٹ فارمز اور ویب سائٹس تک رسائی حاصل کر سکتے ہیں اور صارفین کے لیے آن لائن تجربے کو بہتر بناتا ہے۔ + +### 2۔ KYC تصدیق {#kyc-authentication} + +بہت سی آن لائن خدمات کا استعمال افراد کو تصدیقات اور اسناد فراہم کرنے کا تقاضا کرتا ہے، جیسے کہ ڈرائیونگ لائسنس یا قومی پاسپورٹ۔ لیکن یہ طریقہ مسئلہ ہے کیونکہ صارف کی نجی معلومات سے سمجھوتہ کیا جا سکتا ہے اور سروس فراہم کرنے والے تصدیق کی صداقت کی تصدیق نہیں کر سکتے ہیں۔ + +ڈی سینٹرلائزڈ شناخت کمپنیوں کو روایتی [Know-Your-Customer (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) کے عمل کو چھوڑنے اور قابل تصدیق اسناد کے ذریعے صارف کی شناخت کی تصدیق کرنے کی اجازت دیتی ہے۔ یہ شناختی انتظام کی لاگت کو کم کرتا ہے اور جعلی دستاویزات کے استعمال کو روکتا ہے۔ + +### 3۔ ووٹنگ اور آن لائن کمیونٹیز {#voting-and-online-communities} + +آن لائن ووٹنگ اور سوشل میڈیا ڈی سینٹرلائزڈ شناخت کے لیے دو نئی ایپلی کیشنز ہیں۔ آن لائن ووٹنگ اسکیمیں ہیرا پھیری کا شکار ہیں، خاص طور پر اگر بدنیتی پر مبنی اداکار ووٹ ڈالنے کے لیے جھوٹی شناختیں بنائیں۔ افراد سے آن چین تصدیقات پیش کرنے کا مطالبہ آن لائن ووٹنگ کے عمل کی سالمیت کو بہتر بنا سکتا ہے۔ + +ڈی سینٹرلائزڈ شناخت ایسی آن لائن کمیونٹیز بنانے میں مدد کر سکتی ہے جو جعلی اکاؤنٹس سے پاک ہوں۔ مثال کے طور پر، ہر صارف کو اپنی شناخت کی تصدیق Ethereum Name Service جیسے آن چین شناختی نظام کا استعمال کرتے ہوئے کرنی پڑ سکتی ہے، جس سے بوٹس کے امکانات کم ہو جاتے ہیں۔ + +### 4. اینٹی سائبل تحفظ {#sybil-protection} + +گرانٹ دینے والی ایپلی کیشنز جو [quadratic voting](/glossary/#quadratic-voting) کا استعمال کرتی ہیں وہ [Sybil attacks](/glossary/#sybil-attack) کے لیے کمزور ہیں کیونکہ گرانٹ کی قدر اس وقت بڑھ جاتی ہے جب زیادہ افراد اس کے لیے ووٹ دیتے ہیں، جو صارفین کو اپنی شراکت کو کئی شناختوں میں تقسیم کرنے کی ترغیب دیتا ہے۔ ڈی سینٹرلائزڈ شناختیں ہر شریک پر یہ ثابت کرنے کے بوجھ کو بڑھا کر اسے روکنے میں مدد کرتی ہیں کہ وہ واقعی انسان ہیں، حالانکہ اکثر مخصوص نجی معلومات کو ظاہر کیے بغیر۔ + +### 5. قومی اور سرکاری شناختی کارڈ {#national-and-government-id} + +حکومتیں ڈی سینٹرلائزڈ شناخت کے اصولوں کا استعمال بنیادی شناختی دستاویزات — جیسے قومی شناختی کارڈ، پاسپورٹ، یا ڈرائیونگ لائسنس — کو Ethereum پر قابل تصدیق اسناد کے طور پر جاری کرنے کے لیے کر سکتی ہیں، جس سے آن لائن شناختی تصدیق میں دھوکہ دہی اور جعلسازی کو کم کرنے کے لیے صداقت کی مضبوط کرپٹوگرافک ضمانتیں فراہم کی جاتی ہیں۔ شہری ان تصدیقات کو اپنے ذاتی [والیٹ](/wallets/) میں محفوظ کر سکتے ہیں اور اپنی شناخت، عمر، یا ووٹ کا حق ثابت کرنے کے لیے ان کا استعمال کر سکتے ہیں۔ + +یہ ماڈل منتخب انکشاف کی اجازت دیتا ہے، خاص طور پر جب [زیرو نالج پروف (ZKP)](/zero-knowledge-proofs/) پرائیویسی ٹیکنالوجی کے ساتھ ملایا جائے۔ مثال کے طور پر، ایک شہری کرپٹوگرافک طور پر یہ ثابت کر سکتا ہے کہ وہ 18 سال سے زیادہ عمر کے ہیں تاکہ عمر کی پابندی والی سروس تک رسائی حاصل کر سکیں بغیر اپنی صحیح تاریخ پیدائش ظاہر کیے، جو روایتی شناختی کارڈ سے زیادہ رازداری کی پیشکش کرتا ہے۔ + +#### 💡کیس اسٹڈی: ایتھیریم پر بھوٹان قومی ڈیجیٹل ID (NDI) {#case-study-bhutan-ndi} + +- بھوٹان کے تقریباً 800,000 شہریوں کے لیے قابل تصدیق شناختی اسناد تک رسائی فراہم کرتا ہے +- اکتوبر 2025 میں پولی گون نیٹ ورک سے [ایتھیریم مین نیٹ پر منتقل ہوا](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878) +- مارچ 2025 تک [234,000 سے زیادہ ڈیجیٹل آئی ڈیز](https://www.blockchain-council.org/blockchain/bhutan-uses-blockchain-in-digital-id-project/) جاری کی گئیں + +بھوٹان کی بادشاہی نے اکتوبر 2025 میں اپنے قومی ڈیجیٹل شناختی (NDI) نظام کو [ایتھیریم میں منتقل کر دیا](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)۔ ڈی سینٹرلائزڈ شناخت اور خود مختار شناخت کے اصولوں پر بنایا گیا، بھوٹان کا NDI نظام ڈی سینٹرلائزڈ شناخت کنندگان اور قابل تصدیق اسناد کا استعمال کرتا ہے تاکہ ڈیجیٹل طور پر دستخط شدہ اسناد کو براہ راست شہری کے ذاتی والیٹ میں جاری کیا جا سکے۔ ایتھیریم پر ان اسناد کے کرپٹوگرافک ثبوتوں کو لنگر انداز کرکے، یہ نظام یقینی بناتا ہے کہ وہ مستند، چھیڑ چھاڑ سے پاک ہیں، اور کسی بھی فریق کے ذریعہ مرکزی اتھارٹی سے استفسار کیے بغیر تصدیق کی جاسکتی ہے۔ + +سسٹم کا فن تعمیر [زیرو نالج پروف (ZKP)](/zero-knowledge-proofs/) ٹیکنالوجی کے استعمال کے ذریعے رازداری پر زور دیتا ہے۔ "منتخب انکشاف" کا یہ نفاذ شہریوں کو مخصوص حقائق (مثلاً، "میں 18 سال سے زیادہ ہوں" یا "میں ایک شہری ہوں") کو ثابت کرنے کی اجازت دیتا ہے تاکہ وہ بنیادی ذاتی ڈیٹا، جیسے ان کا مکمل شناختی نمبر یا صحیح تاریخ پیدائش، کو ظاہر کیے بغیر خدمات تک رسائی حاصل کر سکیں۔ یہ ایک محفوظ، صارف پر مبنی، اور رازداری کے تحفظ والے قومی شناختی نظام کے لیے Ethereum کے ایک طاقتور، حقیقی دنیا کے استعمال کا مظاہرہ کرتا ہے۔ + +#### 💡کیس اسٹڈی: ایتھیریم [لیئر 2](/layer-2/) ZKSync Era پر بیونس آئرس شہر کا QuarkID {#case-study-buenos-aires-quarkid} + +- لانچ کے وقت [3.6 ملین سے زیادہ صارفین](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo) کو ڈی سینٹرلائزڈ شناختی اسناد جاری کی گئیں +- QuarkID ایک اوپن سورس پروٹوکول ہے جسے اقوام متحدہ کے پائیدار ترقیاتی اہداف کے تحت [ڈیجیٹل پبلک گڈ](https://www.digitalpublicgoods.net/r/quarkid) کے طور پر تسلیم کیا گیا ہے +- "[حکومت بطور صارف](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)" ماڈل پر زور دیتا ہے، جہاں شہر پروٹوکول کا مالک نہیں ہے، جس سے شہریوں کو مکمل ڈیٹا کی ملکیت اور رازداری ملتی ہے۔ + +2024 میں، بیونس آئرس شہر کی حکومت (GCBA) نے QuarkID کو مربوط کیا، جو GCBA کے سیکرٹریٹ آف انوویشن اینڈ ڈیجیٹل ٹرانسفارمیشن کے ذریعہ بنایا گیا اوپن سورس "ڈیجیٹل ٹرسٹ فریم ورک" ہے، miBA میں، جو رہائشیوں کو سرکاری خدمات اور سرکاری دستاویزات تک رسائی کے لیے شہر کی سرکاری ایپ ہے۔ لانچ کے وقت، miBA کے تمام 3.6 ملین سے زیادہ صارفین کو ڈی سینٹرلائزڈ ڈیجیٹل شناختیں جاری کی گئیں جو انہیں قابل تصدیق ڈیجیٹل دستاویزات اور سرٹیفکیٹس کو آن چین منظم اور شیئر کرنے کی اجازت دیتی ہیں، بشمول شہریت کی اسناد، پیدائش، شادی، اور موت کے سرٹیفکیٹس، ٹیکس ریکارڈز، ویکسینیشن ریکارڈز، اور بہت کچھ۔ + +ایتھیریم [لیئر 2](/layer-2/) نیٹ ورک ZKSync Era پر بنایا گیا، QuarkID نظام ZKP ٹیکنالوجی کا استعمال کرتا ہے تاکہ شہری اپنے موبائل آلات کے ذریعے ذاتی اسناد کی پیئر ٹو پیئر تصدیق کر سکیں — بغیر غیر ضروری ذاتی ڈیٹا کو ظاہر کیے۔ یہ پروگرام ایک "حکومت بطور صارف" ماڈل کو نمایاں کرتا ہے جس میں GCBA ایک مرکزی مالک کے طور پر کام کرنے کے بجائے، اوپن سورس، انٹرآپریبل QuarkID پروٹوکول کے ایک صارف کے طور پر کام کرتا ہے۔ یہ ZKP- فعال فن تعمیر ایک کلیدی رازداری کی خصوصیت فراہم کرتا ہے: کوئی فریق ثالث، یہاں تک کہ GCBA بھی، یہ ٹریک نہیں کر سکتا کہ کوئی شہری اپنی اسناد کا استعمال کیسے، کب، یا کیوں کرتا ہے۔ یہ کامیاب پروگرام شہریوں کو ان کے حساس ڈیٹا پر مکمل خود مختار شناخت اور کنٹرول فراہم کرتا ہے، یہ سب Ethereum کے عالمی سطح پر تقسیم شدہ نیٹ ورک کے ذریعے محفوظ ہے۔ + +## تصدیقات کیا ہیں؟ {#what-are-attestations} + +تصدیق ایک ادارہ کی طرف سے دوسرے ادارہ کے بارے میں کیا گیا دعویٰ ہے۔ اگر آپ ریاستہائے متحدہ میں رہتے ہیں، تو محکمہ موٹر وہیکلز (ایک ادارہ) کی طرف سے آپ کو جاری کردہ ڈرائیونگ لائسنس اس بات کی تصدیق کرتا ہے کہ آپ (دوسرا ادارہ) قانونی طور پر کار چلانے کے مجاز ہیں۔ + +تصدیقات شناخت کنندگان سے مختلف ہیں۔ ایک تصدیق میں کسی خاص شناخت کا حوالہ دینے کے لیے شناخت کنندگان _شامل_ ہوتے ہیں، اور اس شناخت سے متعلق کسی وصف کے بارے میں دعویٰ کرتا ہے۔ لہذا، آپ کے ڈرائیونگ لائسنس میں شناخت کنندگان (نام، تاریخ پیدائش، پتہ) ہوتے ہیں لیکن یہ آپ کے قانونی ڈرائیونگ کے حق کے بارے میں بھی تصدیق ہے۔ + +### ڈی سینٹرلائزڈ شناخت کنندگان کیا ہیں؟ {#what-are-decentralized-identifiers} + +روایتی شناخت کنندگان جیسے آپ کا قانونی نام یا ای میل پتہ فریق ثالث پر انحصار کرتے ہیں — حکومتیں اور ای میل فراہم کنندگان۔ ڈی سینٹرلائزڈ شناخت کنندگان (DIDs) مختلف ہیں — وہ کسی بھی مرکزی ادارے کے ذریعہ جاری، منظم یا کنٹرول نہیں کیے جاتے ہیں۔ + +ڈی سینٹرلائزڈ شناخت کنندگان افراد کے ذریعہ جاری، رکھے اور کنٹرول کیے جاتے ہیں۔ ایک [Ethereum account](/glossary/#account) ڈی سینٹرلائزڈ شناخت کنندہ کی ایک مثال ہے۔ آپ کسی کی اجازت کے بغیر جتنے چاہیں اکاؤنٹس بنا سکتے ہیں اور انہیں مرکزی رجسٹری میں محفوظ کرنے کی ضرورت نہیں ہے۔ + +ڈی سینٹرلائزڈ شناخت کنندگان تقسیم شدہ لیجرز ([بلاک چینز](/glossary/#blockchain)) یا [پیئر ٹو پیئر نیٹ ورکس](/glossary/#peer-to-peer-network) پر محفوظ کیے جاتے ہیں۔ یہ DIDs کو [عالمی سطح پر منفرد، اعلی دستیابی کے ساتھ قابل حل، اور کرپٹوگرافک طور پر قابل تصدیق](https://w3c-ccg.github.io/did-primer/) بناتا ہے۔ ایک ڈی سینٹرلائزڈ شناخت کنندہ مختلف اداروں سے منسلک ہو سکتا ہے، بشمول لوگ، تنظیمیں، یا سرکاری ادارے۔ + +## کیا چیز ڈی سینٹرلائزڈ شناخت کنندگان کو ممکن بناتی ہے؟ {#what-makes-decentralized-identifiers-possible} + +### 1۔ پبلک کی کرپٹوگرافی {#public-key-cryptography} + +پبلک کی کرپٹوگرافی ایک معلوماتی حفاظتی اقدام ہے جو کسی ادارے کے لیے ایک [پبلک کی](/glossary/#public-key) اور [پرائیویٹ کی](/glossary/#private-key) تیار کرتا ہے۔ پبلک کی [کرپٹوگرافی](/glossary/#cryptography) کا استعمال بلاک چین نیٹ ورکس میں صارف کی شناخت کی تصدیق اور ڈیجیٹل اثاثوں کی ملکیت کو ثابت کرنے کے لیے کیا جاتا ہے۔ + +کچھ ڈی سینٹرلائزڈ شناخت کنندگان، جیسے Ethereum اکاؤنٹ، میں پبلک اور پرائیویٹ کیز ہوتی ہیں۔ پبلک کی اکاؤنٹ کے کنٹرولر کی شناخت کرتی ہے، جبکہ پرائیویٹ کیز اس اکاؤنٹ کے لیے پیغامات پر دستخط اور ڈیکرپٹ کر سکتی ہیں۔ پبلک کی کرپٹوگرافی اداروں کی تصدیق کے لیے درکار ثبوت فراہم کرتی ہے اور تمام دعووں کی تصدیق کے لیے [کرپٹوگرافک دستخط](https://andersbrownworth.com/blockchain/public-private-keys/) کا استعمال کرتے ہوئے نقالی اور جعلی شناختوں کے استعمال کو روکتی ہے۔ + +### 2۔ ڈی سینٹرلائزڈ ڈیٹا اسٹورز {#decentralized-datastores} + +ایک بلاک چین ایک قابل تصدیق ڈیٹا رجسٹری کے طور پر کام کرتا ہے: معلومات کا ایک کھلا، بے اعتماد، اور ڈی سینٹرلائزڈ ذخیرہ۔ پبلک بلاک چینز کا وجود مرکزی رجسٹریوں میں شناخت کنندگان کو محفوظ کرنے کی ضرورت کو ختم کرتا ہے۔ + +اگر کسی کو ڈی سینٹرلائزڈ شناخت کنندہ کی صداقت کی تصدیق کرنے کی ضرورت ہے، تو وہ بلاک چین پر متعلقہ پبلک کی تلاش کر سکتے ہیں۔ یہ روایتی شناخت کنندگان سے مختلف ہے جن کی تصدیق کے لیے فریق ثالث کی ضرورت ہوتی ہے۔ + +## ڈی سینٹرلائزڈ شناخت کنندگان اور تصدیقات ڈی سینٹرلائزڈ شناخت کو کیسے فعال کرتی ہیں؟ {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity} + +ڈی سینٹرلائزڈ شناخت یہ خیال ہے کہ شناخت سے متعلق معلومات خود کنٹرول، نجی، اور پورٹیبل ہونی چاہئیں، جس میں ڈی سینٹرلائزڈ شناخت کنندگان اور تصدیقات بنیادی تعمیراتی بلاکس ہیں۔ + +ڈی سینٹرلائزڈ شناخت کے تناظر میں، تصدیقات (جنہیں [قابل تصدیق اسناد](https://www.w3.org/TR/vc-data-model/) بھی کہا جاتا ہے) جاری کنندہ کے ذریعہ کیے گئے چھیڑ چھاڑ سے پاک، کرپٹوگرافک طور پر قابل تصدیق دعوے ہیں۔ ہر تصدیق یا قابل تصدیق اسناد جو ایک ادارہ (مثلاً، ایک تنظیم) جاری کرتا ہے اس کے DID سے وابستہ ہے۔ + +چونکہ DIDs بلاک چین پر محفوظ ہیں، کوئی بھی Ethereum پر جاری کنندہ کے DID کی کراس چیکنگ کرکے تصدیق کی صداقت کی تصدیق کرسکتا ہے۔ بنیادی طور پر، Ethereum بلاک چین ایک عالمی ڈائرکٹری کی طرح کام کرتا ہے جو بعض اداروں سے وابستہ DIDs کی تصدیق کو قابل بناتا ہے۔ + +ڈی سینٹرلائزڈ شناخت کنندگان ہی وجہ ہیں کہ تصدیقات خود کنٹرول اور قابل تصدیق ہیں۔ یہاں تک کہ اگر جاری کنندہ اب موجود نہیں ہے، ہولڈر کے پاس ہمیشہ تصدیق کے ماخذ اور صداقت کا ثبوت ہوتا ہے۔ + +ڈی سینٹرلائزڈ شناخت کنندگان ڈی سینٹرلائزڈ شناخت کے ذریعے ذاتی معلومات کی رازداری کے تحفظ کے لیے بھی اہم ہیں۔ مثال کے طور پر، اگر کوئی فرد تصدیق کا ثبوت (ڈرائیونگ لائسنس) جمع کرتا ہے، تو تصدیق کرنے والے فریق کو ثبوت میں موجود معلومات کی صداقت کی جانچ کرنے کی ضرورت نہیں ہے۔ اس کے بجائے، تصدیق کنندہ کو یہ تعین کرنے کے لیے صرف تصدیق کی صداقت اور جاری کرنے والی تنظیم کی شناخت کی کرپٹوگرافک ضمانتوں کی ضرورت ہے کہ آیا ثبوت درست ہے۔ + +## ڈی سینٹرلائزڈ شناخت میں تصدیقات کی اقسام {#types-of-attestations-in-decentralized-identity} + +Ethereum پر مبنی شناختی ماحولیاتی نظام میں تصدیقی معلومات کو کس طرح ذخیرہ اور بازیافت کیا جاتا ہے یہ روایتی شناختی انتظام سے مختلف ہے۔ یہاں ڈی سینٹرلائزڈ شناختی نظاموں میں تصدیقات کو جاری کرنے، ذخیرہ کرنے اور تصدیق کرنے کے مختلف طریقوں کا ایک جائزہ ہے: + +### آف چین تصدیقات {#offchain-attestations} + +آن چین تصدیقات کو ذخیرہ کرنے کے ساتھ ایک تشویش یہ ہے کہ ان میں ایسی معلومات ہوسکتی ہیں جنہیں افراد نجی رکھنا چاہتے ہیں۔ Ethereum بلاک چین کی عوامی نوعیت ایسی تصدیقات کو ذخیرہ کرنے کے لیے اسے غیر پرکشش بناتی ہے۔ + +حل یہ ہے کہ تصدیقات جاری کی جائیں، جو صارفین کے ذریعے آف چین ڈیجیٹل والیٹس میں رکھی جائیں، لیکن آن چین ذخیرہ شدہ جاری کنندہ کے DID کے ساتھ دستخط شدہ ہوں۔ یہ تصدیقات [JSON Web Tokens](https://en.wikipedia.org/wiki/JSON_Web_Token) کے طور پر انکوڈ کی گئی ہیں اور ان میں جاری کنندہ کے ڈیجیٹل دستخط ہوتے ہیں — جو آف چین دعووں کی آسان تصدیق کی اجازت دیتا ہے۔ + +آف چین تصدیقات کی وضاحت کے لیے یہاں ایک فرضی منظر نامہ ہے: + +1. ایک یونیورسٹی (جاری کنندہ) ایک تصدیق (ایک ڈیجیٹل تعلیمی سرٹیفکیٹ) تیار کرتی ہے، اپنی کیز کے ساتھ دستخط کرتی ہے، اور اسے باب (شناخت کے مالک) کو جاری کرتی ہے۔ + +2. باب نوکری کے لیے درخواست دیتا ہے اور ایک آجر کو اپنی تعلیمی قابلیت ثابت کرنا چاہتا ہے، لہذا وہ اپنے موبائل والیٹ سے تصدیق شیئر کرتا ہے۔ کمپنی (تصدیق کنندہ) پھر جاری کنندہ کے DID (یعنی، Ethereum پر اس کی پبلک کی) کی جانچ کرکے تصدیق کی صداقت کی تصدیق کر سکتی ہے۔ + +### مستقل رسائی کے ساتھ آف چین تصدیقات {#offchain-attestations-with-persistent-access} + +اس انتظام کے تحت تصدیقات کو JSON فائلوں میں تبدیل کیا جاتا ہے اور آف چین (مثالی طور پر ایک [ڈی سینٹرلائزڈ کلاؤڈ اسٹوریج](/developers/docs/storage/) پلیٹ فارم، جیسے IPFS یا Swarm پر) ذخیرہ کیا جاتا ہے۔ تاہم، JSON فائل کا ایک [ہیش](/glossary/#hash) آن چین ذخیرہ کیا جاتا ہے اور ایک آن چین رجسٹری کے ذریعے DID سے منسلک ہوتا ہے۔ متعلقہ DID یا تو تصدیق جاری کرنے والے کا ہو سکتا ہے یا وصول کنندہ کا۔ + +یہ نقطہ نظر تصدیقات کو بلاک چین پر مبنی استقامت حاصل کرنے کے قابل بناتا ہے، جبکہ دعووں کی معلومات کو انکرپٹڈ اور قابل تصدیق رکھتا ہے۔ یہ منتخب انکشاف کی بھی اجازت دیتا ہے کیونکہ پرائیویٹ کی کا حامل معلومات کو ڈیکرپٹ کر سکتا ہے۔ + +### آن چین تصدیقات {#onchain-attestations} + +آن چین تصدیقات Ethereum بلاک چین پر [اسمارٹ معاہدوں](/glossary/#smart-contract) میں رکھی جاتی ہیں۔ اسمارٹ معاہدہ (ایک رجسٹری کے طور پر کام کرتا ہے) ایک تصدیق کو متعلقہ آن چین ڈی سینٹرلائزڈ شناخت کنندہ (ایک پبلک کی) سے نقشہ بنائے گا۔ + +یہاں ایک مثال ہے کہ آن چین تصدیقات عملی طور پر کیسے کام کر سکتی ہیں: + +1. ایک کمپنی (XYZ Corp) ایک اسمارٹ معاہدے کا استعمال کرتے ہوئے ملکیت کے حصص فروخت کرنے کا ارادہ رکھتی ہے لیکن صرف ایسے خریدار چاہتی ہے جنہوں نے بیک گراؤنڈ چیک مکمل کر لیا ہو۔ + +2. XYZ Corp Ethereum پر آن چین تصدیقات جاری کرنے کے لیے بیک گراؤنڈ چیک کرنے والی کمپنی رکھ سکتی ہے۔ یہ تصدیق اس بات کی تصدیق کرتی ہے کہ کسی فرد نے بغیر کسی ذاتی معلومات کو ظاہر کیے بیک گراؤنڈ چیک پاس کر لیا ہے۔ + +3. حصص فروخت کرنے والا اسمارٹ معاہدہ اسکرین شدہ خریداروں کی شناخت کے لیے رجسٹری معاہدے کی جانچ کر سکتا ہے، جس سے اسمارٹ معاہدے کے لیے یہ تعین کرنا ممکن ہو جاتا ہے کہ کس کو حصص خریدنے کی اجازت ہے یا نہیں۔ + +### سول باؤنڈ ٹوکنز اور شناخت {#soulbound} + +[سول باؤنڈ ٹوکنز](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([نان ٹرانسفرایبل NFTs](/glossary/#nft)) کا استعمال کسی مخصوص والیٹ کے لیے منفرد معلومات جمع کرنے کے لیے کیا جا سکتا ہے۔ یہ مؤثر طریقے سے ایک خاص Ethereum پتے سے منسلک ایک منفرد آن چین شناخت بناتا ہے جس میں کامیابیوں (مثلاً، کچھ مخصوص آن لائن کورس مکمل کرنا یا کسی گیم میں تھریشولڈ اسکور پاس کرنا) یا کمیونٹی کی شرکت کی نمائندگی کرنے والے ٹوکن شامل ہوسکتے ہیں۔ + +## ڈی سینٹرلائزڈ شناخت کا استعمال کریں {#use-decentralized-identity} + +بہت سے مہتواکانکشی منصوبے ہیں جو Ethereum کو ڈی سینٹرلائزڈ شناختی حل کی بنیاد کے طور پر استعمال کرتے ہیں: + +- **[Ethereum Name Service (ENS)](https://ens.domains/)** - _آن چین، مشین سے پڑھنے کے قابل شناخت کنندگان کے لیے ایک ڈی سینٹرلائزڈ نام دینے کا نظام، جیسے، Ethereum والیٹ پتے، مواد کے ہیشز، اور میٹا ڈیٹا۔_ +- **[Sign in with Ethereum (SIWE)](https://siwe.xyz/)** - _Ethereum اکاؤنٹس کے ساتھ تصدیق کے لیے کھلا معیار۔_ +- **[SpruceID](https://www.spruceid.com/)** - _ایک ڈی سینٹرلائزڈ شناختی پروجیکٹ جو صارفین کو فریق ثالث کی خدمات پر انحصار کرنے کے بجائے Ethereum اکاؤنٹس اور ENS پروفائلز کے ساتھ ڈیجیٹل شناخت کو کنٹرول کرنے کی اجازت دیتا ہے۔_ +- **[Ethereum Attestation Service (EAS)](https://attest.org/)** - _کسی بھی چیز کے بارے میں آن چین یا آف چین تصدیقات کرنے کے لیے ایک ڈی سینٹرلائزڈ لیجر/پروٹوکول۔_ +- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (یا PoH) Ethereum پر بنایا گیا ایک سماجی شناختی تصدیقی نظام ہے۔_ +- **[BrightID](https://www.brightid.org/)** - _ایک ڈی سینٹرلائزڈ، اوپن سورس سماجی شناختی نیٹ ورک جو سماجی گراف کی تخلیق اور تجزیہ کے ذریعے شناختی تصدیق میں اصلاح کی کوشش کرتا ہے۔_ +- **[walt.id](https://walt.id)** — _اوپن سورس ڈی سینٹرلائزڈ شناخت اور والیٹ انفراسٹرکچر جو ڈویلپرز اور تنظیموں کو خود مختار شناخت اور NFTs/SBTs سے فائدہ اٹھانے کے قابل بناتا ہے۔_ +- **[Veramo](https://veramo.io/)** - _ایک JavaScript فریم ورک جو کسی کے لیے بھی اپنی ایپلی کیشنز میں کرپٹوگرافک طور پر قابل تصدیق ڈیٹا کا استعمال آسان بناتا ہے۔_ + +## مزید پڑھیں {#further-reading} + +### مضامین {#articles} + +- [بلاک چین کے استعمال کے معاملات: ڈیجیٹل شناخت میں بلاک چین](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_ +- [ایتھیریم ERC725 کیا ہے؟ بلاک چین پر خود مختار شناختی انتظام](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ +- [بلاک چین ڈیجیٹل شناخت کے مسئلے کو کیسے حل کر سکتا ہے](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_ +- [ڈی سینٹرلائزڈ شناخت کیا ہے اور آپ کو کیوں پرواہ کرنی چاہئے؟](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_ +- [ڈی سینٹرلائزڈ شناخت کا تعارف](https://walt.id/white-paper/digital-identity) — _Dominik Beron_ + +### ویڈیوز {#videos} + +- [ڈی سینٹرلائزڈ شناخت (بونس لائیو اسٹریم سیشن)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _اینڈریاس اینٹونوپولوس کی طرف سے ڈی سینٹرلائزڈ شناخت پر ایک بہترین وضاحتی ویڈیو_ +- [ایتھیریم کے ساتھ سائن ان کریں اور سیرامک، آئی ڈی ایکس، ری ایکٹ، اور 3 آئی ڈی کنیکٹ کے ساتھ ڈی سینٹرلائزڈ شناخت](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _نادر دابت کے ذریعہ اپنے Ethereum والیٹ کا استعمال کرتے ہوئے صارف کے پروفائل کو بنانے، پڑھنے اور اپ ڈیٹ کرنے کے لیے شناختی انتظام کا نظام بنانے پر YouTube ٹیوٹوریل_ +- [BrightID - ایتھیریم پر ڈی سینٹرلائزڈ شناخت](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Bankless پوڈکاسٹ ایپی سوڈ جس میں BrightID پر بحث کی گئی ہے، جو Ethereum کے لیے ایک ڈی سینٹرلائزڈ شناختی حل ہے۔_ +- [آف چین انٹرنیٹ: ڈی سینٹرلائزڈ شناخت اور قابل تصدیق اسناد](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — ایون میک مولن کی طرف سے EthDenver 2022 پیشکش +- [قابل تصدیق اسناد کی وضاحت](https://www.youtube.com/watch?v=ce1IdSr-Kig) - تمینو باؤمن کے ڈیمو کے ساتھ YouTube وضاحتی ویڈیو + +### کمیونٹیز {#communities} + +- [GitHub پر ERC-725 الائنس](https://github.com/erc725alliance) — _Ethereum بلاک چین پر شناخت کا انتظام کرنے کے لیے ERC725 معیار کے حامی_ +- [EthID Discord سرور](https://discord.com/invite/ZUyG3mSXFD) — _ایتھیریم کے ساتھ سائن ان کرنے اور ایتھیریم فالو پروٹوکول پر کام کرنے والے شائقین اور ڈویلپرز کے لیے کمیونٹی_ +- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _ایپلی کیشنز کے لیے قابل تصدیق ڈیٹا کے لیے ایک فریم ورک بنانے میں تعاون کرنے والے ڈویلپرز کی ایک کمیونٹی_ +- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _مختلف صنعتوں میں ڈی سینٹرلائزڈ شناخت کے استعمال کے معاملات پر کام کرنے والے ڈویلپرز اور بلڈرز کی ایک کمیونٹی_ diff --git a/public/content/translations/ur/defi/index.md b/public/content/translations/ur/defi/index.md new file mode 100644 index 00000000000..dd0a89730b6 --- /dev/null +++ b/public/content/translations/ur/defi/index.md @@ -0,0 +1,364 @@ +--- +title: "غیر مرکزی مالیات (DeFi)" +metaTitle: "ڈی فائی کیا ہے؟ غیر مرکزی فائینانس کے فوائد اور استعمال" +description: "ایتھیریئم پر ڈی فائی کا جائزہ" +lang: ur-in +template: use-cases +emoji: ":money_with_wings:" +image: /images/use-cases/defi.png +alt: "لیگو برکس سے بنا ایک Eth لوگو۔" +sidebarDepth: 2 +summaryPoint1: "موجودہ مالیاتی نظام کا ایک عالمی، کھلا متبادل۔" +summaryPoint2: "ایسی پروڈکٹس جو آپ کو قرض لینے، بچت کرنے، سرمایہ کاری کرنے، تجارت کرنے اور بہت کچھ کرنے کی سہولت دیتی ہیں۔" +summaryPoint3: "اوپن سورس ٹیکنالوجی پر مبنی جس کے ساتھ کوئی بھی پروگرامنگ کر سکتا ہے۔" +--- + +ڈی فائی مصنوعات مالیاتی خدمات کو ان سب کے لیے کھولتی ہیں جن کے پاس انٹرنیٹ کنکشن ہے، اور یہ زیادہ تر اپنے صارفین کے زیرِ ملکیت اور زیرِ انتظام ہیں یہ آپ کو اپنے پیسے پر کنٹرول اور نگرانی فراہم کرتا ہے۔ یہ آپ کو عالمی بازاروں اور آپ کی مقامی کرنسی یا بینکنگ کے اختیارات کے متبادل تک رسائی فراہم کرتا ہے۔ DeFi پروڈکٹس انٹرنیٹ کنکشن رکھنے والے کسی بھی شخص کے لیے مالیاتی خدمات مہیا کرتی ہیں اور ان کی ملکیت اور دیکھ بھال زیادہ تر ان کے صارفین ہی کرتے ہیں۔ اب تک، دسیوں ارب ڈالر مالیت کی کرپٹو DeFi ایپلیکیشنز کے ذریعے استعمال ہوچکی ہے اور یہ ہر روز بڑھ رہی ہے۔ + +## ڈی فائی کیا ہے؟ {#what-is-defi} + +ڈی فائی ایک مجموعی اصطلاح ہے مالیاتی مصنوعات اور خدمات کے لیے جو کسی بھی شخص کے لیے قابل رسائی ہیں جو ایتھیریم استعمال کر سکتا ہے – یعنی ہر وہ شخص جس کے پاس انٹرنیٹ کنکشن ہو ڈی فائی کے ساتھ، منڈیاں ہمیشہ کھلی رہتی ہیں اور کوئی مرکزی اتھارٹی نہیں ہوتی جو آپ کی ادائیگیوں کو روک سکے یا آپ کی رسائی بند کرے وہ خدمات جو پہلے سست تھیں اور انسانی غلطی کے خطرے میں تھیں، اب خودکار اور زیادہ محفوظ ہیں کیونکہ اب انہیں ایسے کوڈ کے ذریعے سنبھالا جاتا ہے جسے کوئی بھی جانچ اور پرکھ سکتا ہے + +وہاں ایک تیزی سے بڑھتی ہوئی کرپٹو معیشت ہے، جہاں آپ قرض دے سکتے ہیں، لے سکتے ہیں، لانگ/شارٹ کر سکتے ہیں، منافع کما سکتے ہیں اور مزید کچھ بھی کرپٹو سمجھ رکھنے والے ارجنٹائنی باشندوں نے کمر توڑ مہنگائی سے بچنے کے لیے ڈی فائی کا استعمال کیا ہے کمپنیاں اپنے ملازمین کو ان کی تنخواہیں براہِ راست وقت پر بھیجنا شروع کر چکی ہیں کچھ لوگوں نے لاکھوں ڈالر کے قرضے لیے اور واپس بھی کیے بغیر کسی ذاتی شناخت کی ضرورت کے + + + +## DeFi بمقابلہ روایتی مالیات {#defi-vs-tradfi} + +ڈی فائی کی صلاحیت کو دیکھنے کے بہترین طریقوں میں سے ایک یہ ہے کہ آج موجود مسائل کو سمجھا جائے + +- کچھ لوگوں کو بینک اکاؤنٹ کھولنے یا مالیاتی خدمات استعمال کرنے کی اجازت نہیں دی جاتی +- مالیاتی خدمات تک رسائی نہ ہونے سے لوگ ملازمت کے قابل نہیں رہ سکتے +- مالیاتی خدمات آپ کو ادائیگی حاصل کرنے سے روک سکتی ہیں +- مالیاتی خدمات کی ایک پوشیدہ قیمت آپ کا ذاتی ڈیٹا ہے +- حکومتیں اور مرکزی ادارے جب چاہیں منڈیاں بند کر سکتے ہیں +- تجارتی اوقات اکثر کسی مخصوص ٹائم زون کے کاروباری اوقات تک محدود ہوتے ہیں +- رقم کی منتقلی انسانی عمل کی وجہ سے کئی دن لے سکتی ہے +- مالیاتی خدمات پر اضافی لاگت آتی ہے کیونکہ درمیانی اداروں کو اپنا حصہ چاہیے + +### ایک موازنہ {#defi-comparison} + +| DeFi | روایتی مالیات | +| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | +| آپ اپنا پیسہ خود رکھتے ہیں | آپ کا پیسہ کمپنیوں کے پاس رکھا جاتا ہے | +| آپ کنٹرول کرتے ہیں کہ آپ کا پیسہ کہاں جائے اور کیسے خرچ ہو | آپ کو کمپنیوں پر بھروسہ کرنا پڑتا ہے کہ وہ آپ کے پیسے کا غلط استعمال نہ کریں، جیسے خطرناک قرض لینے والوں کو دینا | +| رقوم کی منتقلی منٹوں میں ہوتی ہے | ادائیگیاں دستی عمل کی وجہ سے کئی دن لے سکتی ہیں | +| لین دین کی سرگرمی نیم گمنام ہوتی ہے | مالیاتی سرگرمی آپ کی شناخت سے سختی سے جڑی ہوتی ہے | +| ڈی فائی سب کے لیے کھلا ہے | آپ کو مالیاتی خدمات استعمال کرنے کے لیے درخواست دینا پڑتی ہے | +| منڈیاں ہمیشہ کھلی رہتی ہیں | منڈیاں اس لیے بند ہوتی ہیں کیونکہ ملازمین کو وقفہ چاہیے ہوتا ہے | +| یہ شفافیت پر مبنی ہے – کوئی بھی کسی پروڈکٹ کا ڈیٹا دیکھ سکتا ہے اور جانچ سکتا ہے کہ نظام کیسے کام کرتا ہے | مالیاتی ادارے بند کتابوں کی طرح ہیں: آپ ان کی قرضوں کی تاریخ، ان کے اثاثوں کا ریکارڈ وغیرہ نہیں دیکھ سکتے | + + + DeFi ایپس دریافت کریں + + +## یہ بٹ کوائن سے شروع ہوا… {#bitcoin} + +کئی پہلوؤں سے بٹ کوائن پہلی ڈی فائی ایپلیکیشن تھا بٹ کوائن آپ کو اصل میں اپنی دولت کا مالک بناتا ہے اور آپ اسے دنیا میں کہیں بھی بھیج سکتے ہیں یہ اس طرح ممکن ہوتا ہے کہ بڑی تعداد میں لوگ، جو ایک دوسرے پر بھروسہ نہیں کرتے، کسی قابلِ اعتماد ثالث کے بغیر ایک لیجر پر متفق ہو جاتے ہیں بٹ کوائن سب کے لیے کھلا ہے اور کسی کو اس کے قوانین بدلنے کا اختیار نہیں ہے بٹ کوائن کے اصول، جیسے اس کی کمیابی اور کھلا پن، ٹیکنالوجی میں شامل ہیں یہ روایتی مالیات جیسا نہیں ہے جہاں حکومتیں پیسہ چھاپ کر آپ کی بچت کی قدر کم کر دیتی ہیں اور کمپنیاں منڈیاں بند کر دیتی ہیں + +ایتھیریم اسی پر آگے بڑھتا ہے بٹ کوائن کی طرح، اصول آپ پر بدلے نہیں جا سکتے اور سب کو رسائی حاصل ہے لیکن یہ [اسمارٹ کنٹریکٹس](/glossary/#smart-contract) کا استعمال کرتے ہوئے، اس ڈیجیٹل رقم کو قابل پروگرام بھی بناتا ہے، تاکہ آپ قدر کو ذخیرہ کرنے اور بھیجنے سے آگے بڑھ سکیں۔ + + + +## قابل پروگرام پیسہ {#programmable-money} + +یہ عجیب لگتا ہے... "میں اپنے پیسے کو پروگرام کیوں کرنا چاہوں گا"؟ تاہم، یہ Ethereum پر ٹوکنز کی محض ایک ڈیفالٹ خصوصیت سے زیادہ ہے۔ کوئی بھی ادائیگیوں میں منطق شامل کر سکتا ہے اس طرح آپ کو بٹ کوائن کا کنٹرول اور تحفظ ملتا ہے جو مالیاتی اداروں کی فراہم کردہ خدمات کے ساتھ ملا ہوا ہے یہ آپ کو کرپٹو کرنسی کے ساتھ وہ کام کرنے دیتا ہے جو آپ بٹ کوائن کے ساتھ نہیں کر سکتے، جیسے قرض دینا اور لینا، ادائیگیاں شیڈول کرنا، انڈیکس فنڈز میں سرمایہ کاری کرنا اور مزید + + + + +
اگر آپ ایتھیریم میں نئے ہیں تو ڈی فائی ایپلیکیشنز کے لیے ہماری تجاویز دیکھیں
+ + DeFi ایپس دریافت کریں + +
+
+ +## آپ ڈی فائی کے ساتھ کیا کر سکتے ہیں؟ {#defi-use-cases} + +زیادہ تر مالیاتی خدمات کے لیے ایک غیر مرکزی متبادل موجود ہے لیکن ایتھیریم بالکل نئی مالیاتی مصنوعات بنانے کے مواقع بھی پیدا کرتا ہے یہ ایک مسلسل بڑھتی ہوئی فہرست ہے + +- [دنیا بھر میں پیسہ بھیجیں](#send-money) +- [دنیا بھر میں پیسہ اسٹریم کریں](#stream-money) +- [مستحکم کرنسیوں تک رسائی حاصل کریں](#stablecoins) +- [ضمانت کے ساتھ فنڈز ادھار لیں](#lending) +- [بغیر ضمانت کے ادھار لیں](#flash-loans) +- [کرپٹو بچت شروع کریں](#saving) +- [ٹوکنز کی تجارت کریں](#swaps) +- [اپنا پورٹ فولیو بڑھائیں](#investing) +- [اپنے خیالات کو فنڈ دیں](#crowdfunding) +- [انشورنس خریدیں](#insurance) +- [اپنے پورٹ فولیو کا نظم کریں](#aggregators) + + + +### دنیا بھر میں تیزی سے پیسہ بھیجیں {#send-money} + +بطور بلاک چین، ایتھیریم لین دین کو محفوظ اور عالمی انداز میں بھیجنے کے لیے ڈیزائن کیا گیا ہے بٹ کوائن کی طرح، ایتھیریم دنیا بھر میں پیسہ بھیجنے کو ای میل بھیجنے جتنا آسان بناتا ہے بس اپنے وصول کنندہ کا [ENS نام](/glossary/#ens) (جیسے bob.eth) یا اپنے والٹ سے ان کے اکاؤنٹ کا پتہ درج کریں اور آپ کی ادائیگی منٹوں میں (عام طور پر) براہ راست ان تک پہنچ جائے گی۔ ادائیگی بھیجنے یا وصول کرنے کے لیے، آپ کو ایک [والٹ](/wallets/) کی ضرورت ہوگی۔ + + + ادائیگی کی dapps دیکھیں + + +#### دنیا بھر میں پیسہ بہائیں (اسٹریم کریں) {#stream-money} + +آپ ایتھیریم کے ذریعے بھی پیسہ بہا سکتے ہیں یہ آپ کو کسی کو فی سیکنڈ تنخواہ دینے کی اجازت دیتا ہے، جس سے وہ جب چاہیں اپنے پیسے تک رسائی حاصل کر سکیں یا کسی چیز کو سیکنڈ کے حساب سے کرایہ پر لیں جیسے اسٹوریج لاکر یا الیکٹرک اسکوٹر۔ + +اور اگر آپ [ETH](/glossary/#ether) کو بھیجنا یا اسٹریم نہیں کرنا چاہتے کیونکہ اس کی قدر میں بہت زیادہ تبدیلی آسکتی ہے، تو Ethereum پر متبادل کرنسیاں موجود ہیں: [اسٹیبل کوائنز](/glossary/#stablecoin)۔ + + + +### مستحکم کرنسیوں تک رسائی {#stablecoins} + +کریپٹو کرنسی کا اتار چڑھاؤ بہت سی مالیاتی مصنوعات اور عمومی اخراجات کے لیے ایک مسئلہ ہے۔ DeFi کمیونٹی نے اسے اسٹیبل کوائنز سے حل کیا ہے۔ ان کی قدر کسی دوسرے اثاثے سے منسلک رہتی ہے، عام طور پر ڈالر جیسی مقبول کرنسی۔ + +Dai یا USDC جیسے کوائنز کی قدر ایک ڈالر کے چند سینٹ کے اندر رہتی ہے۔ یہ انہیں کمانے یا خوردہ فروشی کے لیے بہترین بناتا ہے۔ لاطینی امریکہ میں بہت سے لوگوں نے اپنی حکومت کی جاری کردہ کرنسیوں کے ساتھ شدید غیر یقینی صورتحال کے وقت اپنی بچتوں کے تحفظ کے لیے اسٹیبل کوائنز کا استعمال کیا ہے۔ + + + + + +### ادھار لینا {#lending} + +وکندریقرت فراہم کنندگان سے پیسہ ادھار لینا دو اہم اقسام میں آتا ہے۔ + +- پیئر ٹو پیئر، یعنی قرض لینے والا براہ راست کسی مخصوص قرض دہندہ سے قرض لے گا۔ +- پول پر مبنی جہاں قرض دہندگان فنڈز (لیکویڈیٹی) ایک پول کو فراہم کرتے ہیں جہاں سے قرض لینے والے قرض لے سکتے ہیں۔ + + + ادھار لینے والی dapps دیکھیں + + +وکندریقرت قرض دہندہ استعمال کرنے کے بہت سے فوائد ہیں... + +#### رازداری کے ساتھ ادھار لینا {#borrowing-privacy} + +آج، پیسہ قرض دینا اور لینا سب کچھ اس میں شامل افراد کے گرد گھومتا ہے۔ بینکوں کو قرض دینے سے پہلے یہ جاننے کی ضرورت ہے کہ کیا آپ قرض کی ادائیگی کا امکان رکھتے ہیں۔ + +وکندریقرت قرض کا نظام کسی بھی فریق کی شناخت کے بغیر کام کرتا ہے۔ اس کے بجائے، قرض لینے والے کو ضمانت رکھنی چاہیے جو قرض دہندہ کو خود بخود مل جائے گی اگر اس کا قرض واپس نہیں کیا جاتا ہے۔ کچھ قرض دہندگان [NFTs](/glossary/#nft) کو بھی ضمانت کے طور پر قبول کرتے ہیں۔ NFTs ایک منفرد اثاثے کا ڈیڈ ہیں، جیسے کہ ایک پینٹنگ۔ [NFTs کے بارے میں مزید](/nft/) + +یہ آپ کو کریڈٹ چیک کے بغیر یا نجی معلومات حوالے کیے بغیر پیسہ ادھار لینے کی اجازت دیتا ہے۔ + +#### عالمی فنڈز تک رسائی {#access-global-funds} + +جب آپ وکندریقرت قرض دہندہ استعمال کرتے ہیں تو آپ کو دنیا بھر سے جمع کردہ فنڈز تک رسائی حاصل ہوتی ہے، نہ کہ صرف آپ کے منتخب کردہ بینک یا ادارے کی تحویل میں موجود فنڈز تک۔ اس سے قرضے زیادہ قابل رسائی ہو جاتے ہیں اور سود کی شرحیں بہتر ہوتی ہیں۔ + +#### ٹیکس کی بچت {#tax-efficiencies} + +ادھار لینا آپ کو اپنے ETH (ایک قابل ٹیکس واقعہ) کو فروخت کرنے کی ضرورت کے بغیر آپ کو درکار فنڈز تک رسائی دے سکتا ہے۔ اس کے بجائے، آپ اسٹیبل کوائن لون کے لیے ETH کو ضمانت کے طور پر استعمال کر سکتے ہیں۔ یہ آپ کو درکار کیش فلو فراہم کرتا ہے اور آپ کو اپنا ETH رکھنے دیتا ہے۔ اسٹیبل کوائنز ایسے ٹوکن ہیں جو اس وقت کے لیے بہت بہتر ہیں جب آپ کو نقد رقم کی ضرورت ہو کیونکہ ان کی قدر ETH کی طرح کم زیادہ نہیں ہوتی۔ [اسٹیبل کوائنز کے بارے میں مزید](#stablecoins) + +#### فلیش لونز {#flash-loans} + +فلیش لونز وکندریقرت قرض کی ایک زیادہ تجرباتی شکل ہیں جو آپ کو ضمانت یا کوئی ذاتی معلومات فراہم کیے بغیر قرض لینے کی اجازت دیتی ہیں۔ + +وہ ابھی غیر تکنیکی لوگوں کے لیے وسیع پیمانے پر قابل رسائی نہیں ہیں لیکن وہ اس بات کا اشارہ دیتے ہیں کہ مستقبل میں ہر ایک کے لیے کیا ممکن ہو سکتا ہے۔ + +یہ اس بنیاد پر کام کرتا ہے کہ قرض ایک ہی لین دین کے اندر لیا اور واپس ادا کیا جاتا ہے۔ اگر اسے واپس ادا نہیں کیا جاسکتا ہے، تو لین دین اس طرح واپس ہوجاتا ہے جیسے کچھ ہوا ہی نہ ہو۔ + +جو فنڈز اکثر استعمال کیے جاتے ہیں وہ لیکویڈیٹی پولز (ادھار لینے کے لیے استعمال ہونے والے فنڈز کے بڑے پول) میں رکھے جاتے ہیں۔ اگر وہ کسی بھی وقت استعمال نہیں ہو رہے ہیں، تو یہ کسی کے لیے ان فنڈز کو ادھار لینے، ان کے ساتھ کاروبار کرنے، اور انہیں لفظی طور پر اسی وقت مکمل طور پر واپس کرنے کا موقع پیدا کرتا ہے جب وہ ادھار لیے گئے تھے۔ + +اس کا مطلب ہے کہ بہت زیادہ منطق کو ایک بہت ہی مخصوص لین دین میں شامل کیا جانا چاہیے۔ ایک سادہ سی مثال یہ ہو سکتی ہے کہ کوئی شخص فلیش لون کا استعمال کرتے ہوئے ایک قیمت پر زیادہ سے زیادہ اثاثہ ادھار لے تاکہ وہ اسے کسی دوسرے ایکسچینج پر بیچ سکے جہاں قیمت زیادہ ہو۔ + +لہذا ایک ہی لین دین میں، درج ذیل ہوتا ہے: + +- آپ ایکسچینج A سے $1.00 میں X رقم کا $asset ادھار لیتے ہیں +- آپ ایکسچینج B پر X $asset کو $1.10 میں بیچتے ہیں +- آپ ایکسچینج A کو قرض واپس کرتے ہیں +- آپ ٹرانزیکشن فیس کو منہا کرکے منافع رکھتے ہیں + +اگر ایکسچینج B کی سپلائی اچانک گر جاتی ہے اور صارف اصل قرض کو پورا کرنے کے لیے کافی خریدنے کے قابل نہیں ہوتا ہے، تو لین دین آسانی سے ناکام ہو جائے گا۔ + +روایتی مالیاتی دنیا میں مذکورہ بالا مثال کو کرنے کے قابل ہونے کے لیے، آپ کو بہت بڑی رقم کی ضرورت ہوگی۔ پیسہ کمانے کی یہ حکمت عملی صرف ان لوگوں کے لیے قابل رسائی ہے جن کے پاس پہلے سے دولت موجود ہے۔ فلیش لونز ایک ایسے مستقبل کی مثال ہیں جہاں پیسہ کمانے کے لیے پیسہ ہونا ضروری نہیں ہے۔ + + + فلیش لونز کے بارے میں مزید + + + + +### کرپٹو کے ساتھ بچت شروع کریں {#saving} + +#### قرض دینا {#lending} + +آپ اپنی کرپٹو کو قرض دے کر اس پر سود کما سکتے ہیں اور اپنے فنڈز کو حقیقی وقت میں بڑھتے ہوئے دیکھ سکتے ہیں۔ ابھی سود کی شرحیں اس سے کہیں زیادہ ہیں جو آپ کو اپنے مقامی بینک سے ملنے کا امکان ہے (اگر آپ خوش قسمت ہیں کہ آپ کسی تک رسائی حاصل کرسکتے ہیں)۔ یہاں ایک مثال ہے: + +- آپ اپنے 100 Dai، جو کہ ایک [اسٹیبل کوائن](/stablecoins/) ہے، کو Aave جیسی پروڈکٹ کو قرض دیتے ہیں۔ +- آپ کو 100 Aave Dai (aDai) ملتا ہے جو آپ کے قرض دیے گئے Dai کی نمائندگی کرنے والا ایک ٹوکن ہے۔ +- آپ کا aDai سود کی شرحوں کی بنیاد پر بڑھے گا اور آپ اپنے والٹ میں اپنے بیلنس کو بڑھتے ہوئے دیکھ سکتے ہیں۔ [APR](/glossary/#apr) پر منحصر ہے، آپ کے والٹ کا بیلنس کچھ دنوں یا گھنٹوں کے بعد 100.1234 جیسا کچھ پڑھے گا! +- آپ کسی بھی وقت اپنے aDai بیلنس کے برابر عام Dai کی رقم نکال سکتے ہیں۔ + + + قرض دینے والی dapps دیکھیں + + +#### بغیر نقصان والی لاٹریاں {#no-loss-lotteries} + +PoolTogether جیسی بغیر نقصان والی لاٹریاں پیسہ بچانے کا ایک تفریحی اور جدید نیا طریقہ ہیں۔ + +- آپ 100 Dai ٹوکنز کا استعمال کرکے 100 ٹکٹ خریدتے ہیں۔ +- آپ کو 100 plDai ملتے ہیں جو آپ کے 100 ٹکٹوں کی نمائندگی کرتے ہیں۔ +- اگر آپ کا کوئی ایک ٹکٹ فاتح کے طور پر منتخب ہوتا ہے، تو آپ کا plDai بیلنس پرائز پول کی رقم سے بڑھ جائے گا۔ +- اگر آپ نہیں جیتتے ہیں، تو آپ کا 100 plDai اگلے ہفتے کی قرعہ اندازی میں چلا جائے گا۔ +- آپ کسی بھی وقت اپنے plDai بیلنس کے برابر عام Dai کی رقم نکال سکتے ہیں۔ + +پرائز پول اوپر قرض دینے کی مثال کی طرح ٹکٹ ڈپازٹس کو قرض دے کر پیدا ہونے والے تمام سود سے پیدا ہوتا ہے۔ + + + PoolTogether آزمائیں + + + + +### ٹوکنز کا تبادلہ کریں {#swaps} + +Ethereum پر ہزاروں ٹوکنز ہیں۔ وکندریقرت ایکسچینجز (DEXs) آپ کو جب چاہیں مختلف ٹوکنز کی تجارت کرنے کی اجازت دیتی ہیں۔ آپ کبھی بھی اپنے اثاثوں پر کنٹرول نہیں چھوڑتے ہیں۔ یہ کسی دوسرے ملک کا دورہ کرتے وقت کرنسی ایکسچینج استعمال کرنے جیسا ہے۔ لیکن DeFi ورژن کبھی بند نہیں ہوتا ہے۔ بازار سال میں 24/7، 365 دن کھلے رہتے ہیں اور ٹیکنالوجی اس بات کی ضمانت دیتی ہے کہ تجارت کو قبول کرنے کے لیے ہمیشہ کوئی نہ کوئی موجود ہوگا۔ + +مثال کے طور پر، اگر آپ بغیر نقصان والی لاٹری PoolTogether (اوپر بیان کیا گیا ہے) استعمال کرنا چاہتے ہیں، تو آپ کو Dai یا USDC جیسے ٹوکن کی ضرورت ہوگی۔ یہ DEXs آپ کو اپنے ETH کو ان ٹوکنز کے لیے تبدیل کرنے اور کام ختم ہونے پر واپس تبدیل کرنے کی اجازت دیتے ہیں۔ + + + ٹوکن ایکسچینجز دیکھیں + + + + +### جدید تجارت {#trading} + +ان تاجروں کے لیے زیادہ جدید اختیارات ہیں جو تھوڑا زیادہ کنٹرول پسند کرتے ہیں۔ لمیٹ آرڈرز، پرپیچوئلز، مارجن ٹریڈنگ اور بہت کچھ ممکن ہے۔ وکندریقرت ٹریڈنگ کے ساتھ آپ کو عالمی لیکویڈیٹی تک رسائی حاصل ہوتی ہے، مارکیٹ کبھی بند نہیں ہوتی، اور آپ ہمیشہ اپنے اثاثوں پر کنٹرول رکھتے ہیں۔ + +جب آپ مرکزی ایکسچینج استعمال کرتے ہیں تو آپ کو تجارت سے پہلے اپنے اثاثے جمع کروانے ہوتے ہیں اور ان کی دیکھ بھال کے لیے ان پر بھروسہ کرنا پڑتا ہے۔ جب آپ کے اثاثے جمع ہوتے ہیں، تو وہ خطرے میں ہوتے ہیں کیونکہ مرکزی ایکسچینجز ہیکرز کے لیے پرکشش اہداف ہوتے ہیں۔ + + + ٹریڈنگ dapps دیکھیں + + + + +### اپنا پورٹ فولیو بڑھائیں {#investing} + +Ethereum پر فنڈ مینجمنٹ پروڈکٹس ہیں جو آپ کی پسند کی حکمت عملی کی بنیاد پر آپ کے پورٹ فولیو کو بڑھانے کی کوشش کریں گی۔ یہ خودکار ہے، ہر ایک کے لیے کھلا ہے، اور آپ کے منافع میں سے کٹوتی لینے والے انسانی مینیجر کی ضرورت نہیں ہے۔ + +اس کی ایک اچھی مثال [DeFi Pulse Index fund (DPI)](https://defipulse.com/blog/defi-pulse-index/) ہے۔ یہ ایک فنڈ ہے جو خود بخود توازن برقرار رکھتا ہے تاکہ یہ یقینی بنایا جا سکے کہ آپ کے پورٹ فولیو میں مارکیٹ کیپٹلائزیشن کے لحاظ سے سرفہرست DeFi ٹوکنز ہمیشہ شامل ہوں۔ آپ کو کبھی بھی کسی بھی تفصیلات کا انتظام نہیں کرنا پڑتا اور آپ جب چاہیں فنڈ سے رقم نکال سکتے ہیں۔ + + + سرمایہ کاری کی dapps دیکھیں + + + + +### اپنے خیالات کو فنڈ دیں {#crowdfunding} + +Ethereum کراؤڈ فنڈنگ کے لیے ایک مثالی پلیٹ فارم ہے: + +- ممکنہ فنڈرز کہیں سے بھی آ سکتے ہیں - Ethereum اور اس کے ٹوکنز دنیا میں کہیں بھی، کسی کے لیے بھی کھلے ہیں۔ +- یہ شفاف ہے لہذا فنڈ جمع کرنے والے ثابت کر سکتے ہیں کہ کتنی رقم جمع ہوئی ہے۔ آپ یہ بھی ٹریس کر سکتے ہیں کہ بعد میں فنڈز کیسے خرچ کیے جا رہے ہیں۔ +- فنڈ جمع کرنے والے خودکار رقم کی واپسی کا انتظام کر سکتے ہیں اگر، مثال کے طور پر، کوئی مخصوص آخری تاریخ اور کم از کم رقم پوری نہ ہو۔ + + + کراؤڈ فنڈنگ dapps دیکھیں + + +#### کوڈریٹک فنڈنگ {#quadratic-funding} + +Ethereum ایک اوپن سورس سافٹ ویئر ہے اور اب تک کا زیادہ تر کام کمیونٹی نے فنڈ کیا ہے۔ اس نے ایک دلچسپ نئے فنڈ ریزنگ ماڈل کی ترقی کا باعث بنا ہے: کوڈریٹک فنڈنگ۔ اس میں مستقبل میں عوامی بھلائی کے تمام اقسام کو فنڈ دینے کے طریقے کو بہتر بنانے کی صلاحیت ہے۔ + +کوڈریٹک فنڈنگ اس بات کو یقینی بناتی ہے کہ سب سے زیادہ فنڈنگ حاصل کرنے والے پروجیکٹس وہ ہیں جن کی سب سے زیادہ منفرد مانگ ہے۔ دوسرے لفظوں میں، وہ پروجیکٹس جو زیادہ تر لوگوں کی زندگیوں کو بہتر بنانے کے لیے ہیں۔ یہ اس طرح کام کرتا ہے: + +1. عطیہ کردہ فنڈز کا ایک میچنگ پول ہے۔ +2. عوامی فنڈنگ کا ایک دور شروع ہوتا ہے۔ +3. لوگ کچھ رقم عطیہ کرکے کسی پروجیکٹ کے لیے اپنی مانگ کا اشارہ دے سکتے ہیں۔ +4. دور ختم ہونے کے بعد، میچنگ پول پروجیکٹس میں تقسیم کیا جاتا ہے۔ سب سے زیادہ منفرد مانگ والے میچنگ پول سے سب سے زیادہ رقم حاصل کرتے ہیں۔ + +اس کا مطلب ہے کہ 1 ڈالر کے 100 عطیات کے ساتھ پروجیکٹ A کو 10,000 ڈالر کے ایک عطیہ کے ساتھ پروجیکٹ B سے زیادہ فنڈنگ مل سکتی ہے (میچنگ پول کے سائز پر منحصر ہے)۔ + + + کوڈریٹک فنڈنگ کے بارے میں مزید + + + + +### انشورنس {#insurance} + +وکندریقرت انشورنس کا مقصد انشورنس کو سستا، تیزی سے ادائیگی اور زیادہ شفاف بنانا ہے۔ زیادہ آٹومیشن کے ساتھ، کوریج زیادہ سستی ہے اور ادائیگی بہت تیز ہے۔ آپ کے دعوے پر فیصلہ کرنے کے لیے استعمال ہونے والا ڈیٹا مکمل طور پر شفاف ہے۔ + +Ethereum پروڈکٹس، کسی بھی سافٹ ویئر کی طرح، بگز اور ایکسپلوئٹس کا شکار ہو سکتے ہیں۔ لہذا ابھی اس شعبے میں بہت سی انشورنس پروڈکٹس اپنے صارفین کو فنڈز کے نقصان سے بچانے پر توجہ مرکوز کرتی ہیں۔ تاہم، ایسے پروجیکٹس ہیں جو زندگی میں پیش آنے والی ہر چیز کے لیے کوریج بنانا شروع کر رہے ہیں۔ اس کی ایک اچھی مثال Etherisc کا فصل کا کور ہے جس کا مقصد [کینیا میں چھوٹے کسانوں کو خشک سالی اور سیلاب سے بچانا](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc) ہے۔ وکندریقرت انشورنس ان کسانوں کے لیے سستا کور فراہم کر سکتی ہے جو اکثر روایتی انشورنس سے باہر ہو جاتے ہیں۔ + + + انشورنس dapps دیکھیں + + + + +### ایگریگیٹرز اور پورٹ فولیو مینیجرز {#aggregators} + +اتنا کچھ ہونے کے ساتھ، آپ کو اپنی تمام سرمایہ کاری، قرضوں اور تجارت پر نظر رکھنے کے لیے ایک طریقے کی ضرورت ہوگی۔ بہت سی پروڈکٹس ہیں جو آپ کو اپنی تمام DeFi سرگرمیوں کو ایک جگہ سے مربوط کرنے کی اجازت دیتی ہیں۔ یہ DeFi کے اوپن آرکیٹیکچر کی خوبصورتی ہے۔ ٹیمیں ایسے انٹرفیس بنا سکتی ہیں جہاں آپ نہ صرف پروڈکٹس میں اپنے بیلنس دیکھ سکتے ہیں، بلکہ آپ ان کی خصوصیات بھی استعمال کر سکتے ہیں۔ جیسے جیسے آپ DeFi کو مزید دریافت کریں گے آپ کو یہ کارآمد لگ سکتا ہے۔ + + + پورٹ فولیو dapps دیکھیں + + + + +## DeFi کیسے کام کرتا ہے؟ {#how-defi-works} + +DeFi ان خدمات کو فراہم کرنے کے لیے کرپٹو کرنسیوں اور اسمارٹ کنٹریکٹس کا استعمال کرتا ہے جنہیں بیچوانوں کی ضرورت نہیں ہوتی۔ آج کی مالیاتی دنیا میں، مالیاتی ادارے لین دین کے ضامن کے طور پر کام کرتے ہیں۔ یہ ان اداروں کو بے پناہ طاقت دیتا ہے کیونکہ آپ کا پیسہ ان کے ذریعے بہتا ہے۔ اس کے علاوہ، دنیا بھر میں اربوں لوگ بینک اکاؤنٹ تک بھی رسائی حاصل نہیں کر سکتے۔ + +DeFi میں، ایک اسمارٹ کنٹریکٹ لین دین میں مالیاتی ادارے کی جگہ لے لیتا ہے۔ اسمارٹ کنٹریکٹ ایک قسم کا Ethereum اکاؤنٹ ہے جو فنڈز رکھ سکتا ہے اور بعض شرائط کی بنیاد پر انہیں بھیج/واپس کر سکتا ہے۔ جب اسمارٹ کنٹریکٹ لائیو ہوتا ہے تو کوئی بھی اسے تبدیل نہیں کر سکتا – یہ ہمیشہ پروگرام کے مطابق چلے گا۔ + +ایک کنٹریکٹ جو الاؤنس یا جیب خرچ دینے کے لیے ڈیزائن کیا گیا ہے، اسے ہر جمعہ کو اکاؤنٹ A سے اکاؤنٹ B میں رقم بھیجنے کے لیے پروگرام کیا جا سکتا ہے۔ اور یہ صرف تب تک کرے گا جب تک اکاؤنٹ A کے پاس مطلوبہ فنڈز موجود ہوں۔ کوئی بھی کنٹریکٹ کو تبدیل نہیں کر سکتا اور فنڈز چوری کرنے کے لیے اکاؤنٹ C کو وصول کنندہ کے طور پر شامل نہیں کر سکتا۔ + +کنٹریکٹس بھی کسی کے بھی معائنہ اور آڈٹ کے لیے عوامی ہیں۔ اس کا مطلب ہے کہ خراب کنٹریکٹس اکثر بہت جلد کمیونٹی کی جانچ پڑتال کی زد میں آجاتے ہیں۔ + +اس کا مطلب یہ ہے کہ فی الحال Ethereum کمیونٹی کے زیادہ تکنیکی ممبران پر بھروسہ کرنے کی ضرورت ہے جو کوڈ پڑھ سکتے ہیں۔ اوپن سورس پر مبنی کمیونٹی ڈیولپرز کو قابو میں رکھنے میں مدد کرتی ہے، لیکن وقت کے ساتھ ساتھ یہ ضرورت کم ہوتی جائے گی کیونکہ اسمارٹ کنٹریکٹس کو پڑھنا آسان ہو جائے گا اور کوڈ کی معتبریت کو ثابت کرنے کے دیگر طریقے تیار کیے جائیں گے۔ + +## Ethereum اور DeFi {#ethereum-and-defi} + +Ethereum کئی وجوہات کی بنا پر DeFi کے لیے بہترین بنیاد ہے: + +- کوئی بھی Ethereum یا اس پر موجود اسمارٹ کنٹریکٹس کا مالک نہیں ہے - یہ ہر ایک کو DeFi استعمال کرنے کا موقع فراہم کرتا ہے۔ اس کا مطلب یہ بھی ہے کہ کوئی بھی آپ پر قوانین تبدیل نہیں کر سکتا۔ +- DeFi پروڈکٹس سب پردے کے پیچھے ایک ہی زبان بولتے ہیں: Ethereum۔ اس کا مطلب ہے کہ بہت سی پروڈکٹس بغیر کسی رکاوٹ کے ایک ساتھ کام کرتی ہیں۔ آپ ایک پلیٹ فارم پر ٹوکنز قرض دے سکتے ہیں اور سود والے ٹوکن کو بالکل مختلف ایپلیکیشن پر ایک مختلف مارکیٹ میں تبدیل کر سکتے ہیں۔ یہ آپ کے بینک میں لائلٹی پوائنٹس کو کیش کرانے کے قابل ہونے جیسا ہے۔ +- ٹوکنز اور کرپٹو کرنسی Ethereum میں بنائے گئے ہیں، جو ایک مشترکہ لیجر ہے – لین دین اور ملکیت پر نظر رکھنا Ethereum کا کام ہے۔ +- Ethereum مکمل مالیاتی آزادی کی اجازت دیتا ہے - زیادہ تر پروڈکٹس کبھی بھی آپ کے فنڈز کی تحویل نہیں لیں گے، جس سے آپ کو کنٹرول حاصل ہوگا۔ + +آپ DeFi کو تہوں میں سوچ سکتے ہیں: + +1. بلاک چین - Ethereum میں لین دین کی تاریخ اور اکاؤنٹس کی حالت ہوتی ہے۔ +2. اثاثے – [ETH](/what-is-ether/) اور دیگر ٹوکنز (کرنسیاں)۔ +3. پروٹوکولز – [اسمارٹ کنٹریکٹس](/glossary/#smart-contract) جو فعالیت فراہم کرتے ہیں، مثال کے طور پر، ایک ایسی سروس جو اثاثوں کی وکندریقرت قرض دینے کی اجازت دیتی ہے۔ +4. [ایپلیکیشنز](/apps/) – وہ پروڈکٹس جن کا استعمال ہم پروٹوکولز کو منظم کرنے اور ان تک رسائی کے لیے کرتے ہیں۔ + +نوٹ: DeFi کا زیادہ تر حصہ [ERC-20 معیار](/glossary/#erc-20) استعمال کرتا ہے۔ DeFi میں ایپلیکیشنز ETH کے لیے ایک ریپر استعمال کرتی ہیں جسے Wrapped ether (WETH) کہا جاتا ہے۔ [ریپڈ ایتھر کے بارے میں مزید جانیں](/wrapped-eth)۔ + +## DeFi بنائیں {#build-defi} + +DeFi ایک اوپن سورس تحریک ہے۔ DeFi پروٹوکولز اور ایپلیکیشنز آپ کے معائنہ، فورک، اور ان پر اختراع کرنے کے لیے سب کھلے ہیں۔ اس تہہ دار اسٹیک کی وجہ سے (وہ سب ایک ہی بیس بلاک چین اور اثاثے شیئر کرتے ہیں)، پروٹوکولز کو منفرد کومبو مواقع کو کھولنے کے لیے ملایا اور ملایا جا سکتا ہے۔ + + + dapps بنانے کے بارے میں مزید + + +## مزید پڑھیں {#further-reading} + +### DeFi ڈیٹا {#defi-data} + +- [DeFi Prime](https://defiprime.com/) +- [DeFi Llama](https://defillama.com/) + +### DeFi مضامین {#defi-articles} + +- [DeFi کے لیے ایک ابتدائی رہنما](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6 جنوری، 2020_ +- [EEA DeFi رسک اسیسمنٹ گائیڈ لائنز](https://entethalliance.org/specs/defi-risks/) – DeFi پروٹوکولز میں کلیدی خطرات کی شناخت اور ان کا جائزہ لینے کے طریقے کا ایک صنعتی حمایت یافتہ جائزہ۔ + +### ویڈیوز {#videos} + +- [Finematics - وکندریقرت مالیاتی تعلیم](https://finematics.com/) – _DeFi پر ویڈیوز_ +- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _DeFi کی بنیادی باتیں: اس کبھی کبھار پریشان کن جگہ میں شروع کرنے کے لیے آپ کو جاننے کی ہر چیز۔_ +- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _DeFi کیا ہے؟_ + +### کمیونٹیز {#communities} + +- [DeFi Llama Discord سرور](https://discord.defillama.com/) +- [DeFi Pulse Discord سرور](https://discord.gg/Gx4TCTk) + + + + diff --git a/public/content/translations/ur/desci/index.md b/public/content/translations/ur/desci/index.md new file mode 100644 index 00000000000..937f66caf6a --- /dev/null +++ b/public/content/translations/ur/desci/index.md @@ -0,0 +1,139 @@ +--- +title: "غیر مرکزی سائنس (DeSci)" +description: "ایتھریم پر غیر مرکزی سائنس کا ایک جائزہ" +lang: ur-in +template: use-cases +emoji: ":microscope:" +sidebarDepth: 2 +image: /images/future_transparent.png +alt: "" +summaryPoint1: "موجودہ سائنسی نظام کا ایک عالمی، کھلا متبادل." +summaryPoint2: "ٹیکنالوجی جو سائنسدانوں کو فنڈنگ حاصل کرنے، تجربات کرنے، ڈیٹا شیئر کرنے، بصیرت کو تقسیم کرنے، اور بہت کچھ کرنے کے قابل بناتی ہے۔" +summaryPoint3: "اوپن سائنس تحریک پر مبنی ہے۔" +--- + +## غیر مرکزی سائنس (DeSci) کیا ہے؟ {#what-is-desci} + +غیر مرکزی سائنس (DeSci) ایک ایسی تحریک ہے جس کا مقصد [Web3](/glossary/#web3) اسٹیک کا استعمال کرتے ہوئے سائنسی علم کی منصفانہ اور مساویانہ طور پر فنڈنگ، تخلیق، جائزہ، کریڈٹ، ذخیرہ اور تقسیم کے لیے عوامی انفراسٹرکچر بنانا ہے۔ + +DeSci کا مقصد ایک ایسا ایکو سسٹم بنانا ہے جہاں سائنسدانوں کو اپنی تحقیق کو کھلے عام شیئر کرنے اور اپنے کام کا کریڈٹ حاصل کرنے کی ترغیب دی جاتی ہے، جبکہ کسی کو بھی آسانی سے تحقیق تک رسائی حاصل کرنے اور اس میں حصہ ڈالنے کی اجازت ہوتی ہے۔ DeSci اس خیال پر کام کرتا ہے کہ سائنسی علم سب کے لیے قابل رسائی ہونا چاہیے اور سائنسی تحقیق کا عمل شفاف ہونا چاہیے۔ DeSci ایک زیادہ غیر مرکزی اور تقسیم شدہ سائنسی تحقیقی ماڈل بنا رہا ہے، جو اسے مرکزی حکام کی سنسرشپ اور کنٹرول کے خلاف زیادہ مزاحم بناتا ہے۔ DeSci کو فنڈنگ، سائنسی ٹولز، اور مواصلاتی چینلز تک رسائی کو غیر مرکزی بنا کر ایک ایسا ماحول بنانے کی امید ہے جہاں نئے اور غیر روایتی خیالات پنپ سکیں۔ + +غیر مرکزی سائنس مزید متنوع فنڈنگ ذرائع ([DAOs](/glossary/#dao)، [کوڈریٹک عطیات](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) سے لے کر کراؤڈ فنڈنگ اور مزید)، زیادہ قابل رسائی ڈیٹا اور طریقوں، اور ری پروڈیوس ایبلٹی کے لیے ترغیبات فراہم کرنے کی اجازت دیتی ہے۔ + +### Juan Benet - DeSci تحریک + + + +## DeSci سائنس کو کیسے بہتر بناتا ہے {#desci-improves-science} + +سائنس میں کلیدی مسائل کی ایک نامکمل فہرست اور یہ کہ غیر مرکزی سائنس ان مسائل کو حل کرنے میں کیسے مدد کر سکتی ہے + +| **غیر مرکزی سائنس** | **روایتی سائنس** | +| ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | +| فنڈز کی تقسیم **عوام کے ذریعے** کوڈریٹک عطیات یا DAOs جیسے میکانزم کا استعمال کرتے ہوئے **طے کی جاتی ہے**۔ | چھوٹے، بند، **مرکزی گروپ** فنڈز کی تقسیم کو کنٹرول کرتے ہیں۔ | +| آپ متحرک ٹیموں میں **پوری دنیا کے** ساتھیوں کے ساتھ تعاون کرتے ہیں۔ | فنڈنگ ​​تنظیمیں اور ہوم ادارے آپ کے تعاون کو **محدود** کرتے ہیں۔ | +| فنڈنگ کے فیصلے آن لائن اور **شفاف طور پر** کیے جاتے ہیں۔ فنڈنگ کے نئے میکانزم تلاش کیے جاتے ہیں۔ | فنڈنگ کے فیصلے طویل ٹرناراؤنڈ وقت اور **محدود شفافیت** کے ساتھ کیے جاتے ہیں۔ فنڈنگ کے چند میکانزم موجود ہیں۔ | +| [Web3](/glossary/#web3) ٹیکنالوجی کا استعمال کرتے ہوئے لیبارٹری خدمات کا اشتراک آسان اور زیادہ شفاف بنایا گیا ہے۔ | لیبارٹری کے وسائل کا اشتراک اکثر **سست اور غیر شفاف** ہوتا ہے۔ | +| **اشاعت کے لیے نئے ماڈل** تیار کیے جا سکتے ہیں جو اعتماد، شفافیت اور عالمی رسائی کے لیے Web3 پرائمیٹیوز کا استعمال کرتے ہیں۔ | آپ قائم شدہ راستوں سے شائع کرتے ہیں جنہیں اکثر **غیر موثر، متعصب اور استحصالی** تسلیم کیا جاتا ہے۔ | +| آپ کام کا **پیئر ریویو کرنے پر ٹوکن اور ساکھ کما سکتے ہیں**۔ | آپ کا **پیئر ریویو کا کام بلا معاوضہ ہے**، جس سے منافع خور پبلشرز کو فائدہ ہوتا ہے۔ | +| آپ اپنے تیار کردہ **دانشورانہ املاک (IP) کے مالک ہیں** اور اسے شفاف شرائط کے مطابق تقسیم کرتے ہیں۔ | آپ کے تیار کردہ **IP کا مالک آپ کا ہوم ادارہ ہے**۔ IP تک رسائی شفاف نہیں ہے۔ | +| **تمام تحقیق کا اشتراک**، بشمول ناکام کوششوں کا ڈیٹا، تمام مراحل کو آن چین رکھ کر۔ | **اشاعتی تعصب** کا مطلب ہے کہ محققین ان تجربات کو شیئر کرنے کا زیادہ امکان رکھتے ہیں جن کے نتائج کامیاب رہے۔ | + +## ایتھریم اور DeSci {#ethereum-and-desci} + +ایک غیر مرکزی سائنس کے نظام کو مضبوط سیکیورٹی، کم سے کم مالی اور ٹرانزیکشن کے اخراجات، اور ایپلیکیشن کی ڈیولپمنٹ کے لیے ایک بھرپور ایکو سسٹم کی ضرورت ہوگی۔ ایتھریم ایک غیر مرکزی سائنس ٹیکنالوجی کی تعمیر کے لیے درکار ہر چیز فراہم کرتا ہے۔ + +## DeSci کے استعمال کے معاملات {#use-cases} + +DeSci روایتی اکیڈمیا کو ڈیجیٹل دنیا میں لانے کے لیے سائنسی ٹول سیٹ بنا رہا ہے۔ ذیل میں استعمال کے معاملات کا ایک نمونہ ہے جو Web3 سائنسی برادری کو پیش کر سکتا ہے۔ + +### اشاعت {#publishing} + +سائنس کی اشاعت مشہور طور پر ایک مسئلہ ہے کیونکہ اس کا انتظام پبلشنگ ہاؤسز کے ذریعے کیا جاتا ہے جو مقالے تیار کرنے کے لیے سائنسدانوں، مبصرین اور ایڈیٹرز کی مفت محنت پر انحصار کرتے ہیں لیکن پھر اشاعت کی بے تحاشہ فیس وصول کرتے ہیں۔ عوام، جنہوں نے عام طور پر ٹیکس کے ذریعے کام اور اشاعت کے اخراجات کے لیے بالواسطہ ادائیگی کی ہے، اکثر پبلشر کو دوبارہ ادائیگی کیے بغیر اسی کام تک رسائی حاصل نہیں کر سکتے۔ انفرادی سائنس کے مقالوں کو شائع کرنے کی کل فیس اکثر پانچ اعداد ($USD) میں ہوتی ہے، جو سائنسی علم کو [عوامی بھلائی](/glossary/#public-goods) کے طور پر پورے تصور کو کمزور کرتی ہے، جبکہ پبلشرز کے ایک چھوٹے گروپ کے لیے بہت زیادہ منافع پیدا کرتی ہے۔ + +مفت اور اوپن ایکسیس پلیٹ فارم پری پرنٹ سرورز کی شکل میں موجود ہیں، [جیسے ArXiv](https://arxiv.org/)۔ تاہم، ان پلیٹ فارمز میں کوالٹی کنٹرول، [اینٹی سائبل میکانزم](/glossary/#anti-sybil) کی کمی ہے، اور عام طور پر آرٹیکل لیول میٹرکس کو ٹریک نہیں کرتے ہیں، جس کا مطلب ہے کہ وہ عام طور پر صرف کسی روایتی پبلشر کو جمع کرانے سے پہلے کام کی تشہیر کے لیے استعمال ہوتے ہیں۔ SciHub بھی شائع شدہ مقالوں کو مفت رسائی کے لیے فراہم کرتا ہے، لیکن قانونی طور پر نہیں، اور صرف اس کے بعد جب پبلشرز اپنی ادائیگی پہلے ہی لے چکے ہوں اور کام کو سخت کاپی رائٹ قانون سازی میں لپیٹ دیا ہو۔ یہ ایک ایمبیڈڈ قانونی حیثیت کے میکانزم اور ترغیبی ماڈل کے ساتھ قابل رسائی سائنس کے مقالوں اور ڈیٹا کے لیے ایک اہم خلا چھوڑ دیتا ہے۔ ایسا نظام بنانے کے ٹولز Web3 میں موجود ہیں۔ + +### ری پروڈیوس ایبلٹی اور ریپلیک ایبلٹی {#reproducibility-and-replicability} + +ری پروڈیوس ایبلٹی اور ریپلیک ایبلٹی معیاری سائنسی دریافت کی بنیادیں ہیں۔ + +- ری پروڈیوس ایبل نتائج ایک ہی طریقہ کار کا استعمال کرتے ہوئے اسی ٹیم کے ذریعے لگاتار کئی بار حاصل کیے جا سکتے ہیں۔ +- ریپلیک ایبل نتائج ایک ہی تجرباتی سیٹ اپ کا استعمال کرتے ہوئے ایک مختلف گروپ کے ذریعے حاصل کیے جا سکتے ہیں۔ + +نئے Web3-نیٹیو ٹولز اس بات کو یقینی بنا سکتے ہیں کہ ری پروڈیوس ایبلٹی اور ریپلیک ایبلٹی دریافت کی بنیاد ہیں۔ ہم معیاری سائنس کو اکیڈمیا کے تکنیکی تانے بانے میں بُن سکتے ہیں۔ Web3 ہر تجزیاتی جزو: خام ڈیٹا، کمپیوٹیشنل انجن، اور ایپلیکیشن کے نتیجے کے لیے [تصدیقیں](/glossary/#attestation) بنانے کی صلاحیت پیش کرتا ہے۔ کنسنسس سسٹمز کی خوبصورتی یہ ہے کہ جب ان اجزاء کو برقرار رکھنے کے لیے ایک بھروسہ مند نیٹ ورک بنایا جاتا ہے، تو نیٹ ورک کا ہر شریک حساب کو دوبارہ پیش کرنے اور ہر نتیجے کی توثیق کرنے کا ذمہ دار ہو سکتا ہے۔ + +### فنڈنگ {#funding} + +سائنس کی فنڈنگ کا موجودہ معیاری ماڈل یہ ہے کہ سائنسدانوں کے افراد یا گروہ کسی فنڈنگ ایجنسی کو تحریری درخواستیں دیتے ہیں۔ بھروسہ مند افراد کا ایک چھوٹا پینل درخواستوں کو اسکور کرتا ہے اور پھر درخواست دہندگان کے ایک چھوٹے حصے کو فنڈز دینے سے پہلے امیدواروں کا انٹرویو کرتا ہے۔ گرانٹ کے لیے درخواست دینے اور وصول کرنے کے درمیان کبھی کبھی **سالوں کے انتظار** کے وقت کا باعث بننے والی رکاوٹوں کے علاوہ، یہ ماڈل جائزہ پینل کے **تعصبات، ذاتی مفادات اور سیاست کے لیے انتہائی کمزور** سمجھا جاتا ہے۔ + +مطالعات سے پتہ چلتا ہے کہ گرانٹ ریویو پینل اعلی معیار کی تجاویز کو منتخب کرنے میں ناقص کام کرتے ہیں کیونکہ مختلف پینلز کو دی گئی ایک ہی تجاویز کے نتائج بالکل مختلف ہوتے ہیں۔ جیسے جیسے فنڈنگ کی کمی ہوتی گئی ہے، یہ زیادہ دانشورانہ طور پر قدامت پسند پروجیکٹس کے ساتھ زیادہ سینئر محققین کے ایک چھوٹے پول میں مرکوز ہو گئی ہے۔ اس اثر نے ایک انتہائی مسابقتی فنڈنگ ​​کا منظر نامہ تیار کیا ہے، جس سے غلط ترغیبات کو تقویت ملی ہے اور جدت طرازی کا گلا گھونٹ دیا گیا ہے۔ + +Web3 میں DAOs اور Web3 کے ذریعے وسیع پیمانے پر تیار کیے گئے مختلف ترغیبی ماڈلز کے ساتھ تجربہ کرکے اس ٹوٹے ہوئے فنڈنگ ماڈل میں خلل ڈالنے کی صلاحیت ہے۔ [ریٹرو ایکٹیو پبلک گڈز فنڈنگ](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)، [کوڈریٹک فنڈنگ](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)، [DAO گورننس](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) اور [ٹوکنائزڈ ترغیبی ڈھانچے](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) کچھ Web3 ٹولز ہیں جو سائنس کی فنڈنگ میں انقلاب برپا کر سکتے ہیں۔ + +### IP کی ملکیت اور ترقی {#ip-ownership} + +دانشورانہ املاک (IP) روایتی سائنس میں ایک بڑا مسئلہ ہے: یونیورسٹیوں میں پھنسے رہنے یا بائیو ٹیکس میں غیر استعمال شدہ ہونے سے لے کر، بدنام زمانہ طور پر قدر کرنا مشکل ہے۔ تاہم، ڈیجیٹل اثاثوں کی ملکیت (جیسے سائنسی ڈیٹا یا مضامین) ایک ایسی چیز ہے جو Web3 [نان فنجیبل ٹوکنز (NFTs)](/glossary/#nft) کا استعمال کرتے ہوئے غیر معمولی طور پر اچھی طرح سے کرتا ہے۔ + +اسی طرح جس طرح NFTs مستقبل کے لین دین کے لیے ریونیو کو اصل تخلیق کار کو واپس دے سکتے ہیں، آپ محققین، گورننگ باڈیز (جیسے DAOs)، یا یہاں تک کہ ان مضامین کو انعام دینے کے لیے شفاف ویلیو انتساب کی زنجیریں قائم کر سکتے ہیں جن کا ڈیٹا اکٹھا کیا گیا ہے۔ + +[IP-NFTs](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) کیے جانے والے تحقیقی تجربات کی ایک غیر مرکزی ڈیٹا ریپوزٹری کی کلید کے طور پر بھی کام کر سکتے ہیں، اور NFT اور [DeFi](/glossary/#defi) فنانشلائزیشن (فریکشنلائزیشن سے لے کر لینڈنگ پولز اور ویلیو اپریزل تک) میں پلگ ان کر سکتے ہیں۔ یہ مقامی طور پر آن چین اداروں جیسے [VitaDAO](https://www.vitadao.com/) جیسے DAOs کو براہ راست آن چین تحقیق کرنے کی بھی اجازت دیتا ہے۔ +نان ٹرانسفرایبل ["سول باؤنڈ" ٹوکنز](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) کا ظہور بھی DeSci میں ایک اہم کردار ادا کر سکتا ہے جس سے افراد کو اپنے ایتھریم ایڈریس سے منسلک اپنے تجربے اور اسناد کو ثابت کرنے کی اجازت مل سکتی ہے۔ + +### ڈیٹا کا ذخیرہ، رسائی اور فن تعمیر {#data-storage} + +سائنسی ڈیٹا کو Web3 پیٹرن کا استعمال کرتے ہوئے بہت زیادہ قابل رسائی بنایا جا سکتا ہے، اور تقسیم شدہ اسٹوریج تحقیق کو تباہ کن واقعات سے بچانے کے قابل بناتا ہے۔ + +ابتدائی نقطہ ایک ایسا نظام ہونا چاہیے جو مناسب قابل تصدیق اسناد رکھنے والی کسی بھی غیر مرکزی شناخت کے ذریعے قابل رسائی ہو۔ یہ حساس ڈیٹا کو بھروسہ مند فریقوں کے ذریعے محفوظ طریقے سے نقل کرنے کی اجازت دیتا ہے، جس سے فالتو پن اور سنسرشپ مزاحمت، نتائج کی دوبارہ پیداوار، اور یہاں تک کہ متعدد فریقوں کو تعاون کرنے اور ڈیٹا سیٹ میں نیا ڈیٹا شامل کرنے کی صلاحیت بھی ملتی ہے۔ خفیہ کمپیوٹنگ کے طریقے جیسے [کمپیوٹ ٹو ڈیٹا](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol) خام ڈیٹا کی نقل کے لیے متبادل رسائی کے طریقہ کار فراہم کرتے ہیں، جو انتہائی حساس ڈیٹا کے لیے قابل اعتماد تحقیقی ماحول بناتے ہیں۔ بھروسہ مند تحقیقی ماحول کو [NHS کی طرف سے حوالہ دیا گیا ہے](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) جو ڈیٹا کی رازداری اور تعاون کے لیے مستقبل کا حل ہے، ایک ایسا ایکو سسٹم بنا کر جہاں محققین کوڈ اور طریقوں کو شیئر کرنے کے لیے معیاری ماحول کا استعمال کرتے ہوئے سائٹ پر محفوظ طریقے سے ڈیٹا کے ساتھ کام کر سکتے ہیں۔ + +لچکدار Web3 ڈیٹا حل مندرجہ بالا منظرناموں کی حمایت کرتے ہیں اور حقیقی اوپن سائنس کی بنیاد فراہم کرتے ہیں، جہاں محققین رسائی کی اجازت یا فیس کے بغیر عوامی سامان بنا سکتے ہیں۔ Web3 پبلک ڈیٹا حل جیسے IPFS، Arweave اور Filecoin کو غیر مرکزیت کے لیے بہتر بنایا گیا ہے۔ مثال کے طور پر، dClimate موسمیاتی اور موسم کے ڈیٹا تک عالمی رسائی فراہم کرتا ہے، بشمول موسمی اسٹیشنوں اور پیشین گوئی کرنے والے موسمیاتی ماڈلز سے۔ + +## شامل ہوں {#get-involved} + +پروجیکٹس کو دریافت کریں اور DeSci کمیونٹی میں شامل ہوں۔ + +- [DeSci.Global: عالمی ایونٹس اور میٹ اپ کیلنڈر](https://desci.global) +- [Blockchain for Science ٹیلی گرام](https://t.me/BlockchainForScience) +- [Molecule: اپنے تحقیقی منصوبوں کے لیے فنڈ دیں اور فنڈ حاصل کریں](https://www.molecule.xyz/) +- [VitaDAO: لمبی عمر کی تحقیق کے لیے اسپانسر شدہ تحقیقی معاہدوں کے ذریعے فنڈنگ حاصل کریں](https://www.vitadao.com/) +- [ResearchHub: ایک سائنسی نتیجہ پوسٹ کریں اور ساتھیوں کے ساتھ بات چیت میں مشغول ہوں](https://www.researchhub.com/) +- [dClimate API: ایک غیر مرکزی کمیونٹی کے ذریعے جمع کردہ موسمیاتی ڈیٹا سے استفسار کریں](https://www.dclimate.net/) +- [DeSci Foundation: DeSci پبلشنگ ٹول بلڈر](https://descifoundation.org/) +- [DeSci.World: صارفین کے لیے غیر مرکزی سائنس کو دیکھنے، اس کے ساتھ مشغول ہونے کے لیے ایک ون اسٹاپ شاپ](https://desci.world) +- [OceanDAO: ڈیٹا سے متعلقہ سائنس کے لیے DAO کے زیر انتظام فنڈنگ](https://oceanprotocol.com/) +- [Opscientia: اوپن ڈی سینٹرلائزڈ سائنس ورک فلوز](https://opsci.io/research/) +- [Bio.xyz: اپنے بائیو ٹیک DAO یا desci پروجیکٹ کے لیے فنڈ حاصل کریں](https://www.bio.xyz/) +- [Fleming Protocol: اوپن سورس ڈیٹا اکانومی جو باہمی بائیو میڈیکل دریافت کو ہوا دیتی ہے](http://flemingprotocol.io/) +- [Active Inference Institute](https://www.activeinference.org/) +- [IdeaMarkets: غیر مرکزی سائنسی ساکھ کو فعال کرنا](https://ideamarket.io/) +- [DeSci Labs](https://www.desci.com/) +- [ValleyDAO: ایک کھلی، عالمی برادری جو مصنوعی حیاتیات کی تحقیق کے لیے فنڈنگ اور ترجمہی مدد فراہم کرتی ہے](https://www.valleydao.bio) +- [Cerebrum DAO: دماغی صحت کو آگے بڑھانے اور نیوروڈیجنریشن کو روکنے کے لیے حل کی فراہمی اور پرورش](https://www.cerebrumdao.com/) +- [CryoDAO: کرائیو پریزرویشن کے شعبے میں مون شاٹ ریسرچ کے لیے فنڈنگ](https://www.cryodao.org) +- [Elata: نفسیاتی ادویات کے مستقبل میں اپنی رائے دیں](https://www.elata.bio/) + +ہم نئے پروجیکٹس کو فہرست میں شامل کرنے کی تجاویز کا خیرمقدم کرتے ہیں - براہ کرم شروع کرنے کے لیے ہماری [لسٹنگ پالیسی](/contributing/adding-desci-projects/) پر ایک نظر ڈالیں! + +## مزید پڑھیں {#further-reading} + +- [DeSci Wiki از Jocelynn Pearl and Ultrarare](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#) +- [a16z مستقبل کے لیے Jocelynn Pearl کی طرف سے غیر مرکزی بائیو ٹیک کے لیے ایک گائیڈ](https://future.a16z.com/a-guide-to-decentralized-biotech/) +- [DeSci کے لیے کیس](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/) +- [DeSci کے لیے گائیڈ](https://future.com/what-is-decentralized-science-aka-desci/) +- [غیر مرکزی سائنس کے وسائل](https://www.vincentweisser.com/desci) +- [Molecule’s Biopharma IP-NFTs - ایک تکنیکی تفصیل](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description) +- [جون اسٹار کی طرف سے سائنس کے بے اعتماد نظام کی تعمیر](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673) +- [Paul Kohlhaas - DeSci: غیر مرکزی سائنس کا مستقبل (پوڈ کاسٹ)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a) +- [غیر مرکزی سائنس کے لیے ایک فعال انفرنس آنٹولوجی: واقع شدہ سینس میکنگ سے لے کر ایپیسٹیمک کامنز تک](https://zenodo.org/record/6320575) +- [DeSci: سیموئیل اکینوشو کی طرف سے تحقیق کا مستقبل](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) +- [سائنس فنڈنگ (ایپیلاگ: DeSci اور نئے کرپٹو پرائمیٹوز) از نادیہ](https://nadia.xyz/science-funding) +- [غیر مرکزیت ادویات کی ترقی میں خلل ڈال رہی ہے](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) +- [DeSci کیا ہے - غیر مرکزی سائنس؟](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) + +### ویڈیوز {#videos} + +- [غیر مرکزی سائنس کیا ہے؟](https://www.youtube.com/watch?v=-DeMklVWNdA) +- [Vitalik Buterin اور سائنسدان Aubrey de Grey کے درمیان لمبی عمر کی تحقیق اور کرپٹو کے تعلق کے بارے میں گفتگو](https://www.youtube.com/watch?v=x9TSJK1widA) +- [سائنسی اشاعت ٹوٹ گئی ہے۔ کیا Web3 اسے ٹھیک کر سکتا ہے؟](https://www.youtube.com/watch?v=WkvzYgCvWj8) +- [Juan Benet - DeSci, Independent Labs, & Large Scale Data Science](https://www.youtube.com/watch?v=zkXM9H90g_E) +- [Sebastian Brunemeier - DeSci بائیو میڈیکل ریسرچ اور وینچر کیپیٹل کو کیسے تبدیل کر سکتا ہے](https://www.youtube.com/watch?v=qB4Tc3FcVbM) +- [Paige Donner - Web3 اور Blockchain کے ساتھ اوپن سائنس کو ٹول کرنا](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) diff --git a/public/content/translations/ur/developers/docs/accounts/index.md b/public/content/translations/ur/developers/docs/accounts/index.md new file mode 100644 index 00000000000..af5cc803d7d --- /dev/null +++ b/public/content/translations/ur/developers/docs/accounts/index.md @@ -0,0 +1,137 @@ +--- +title: "Ethereum اکاؤنٹس" +description: "Ethereum اکاؤنٹس کی وضاحت – ان کے ڈیٹا ڈھانچے اور کلیدی جوڑی کی خفیہ کاری کے ساتھ ان کا تعلق۔" +lang: ur-in +--- + +ایک Ethereum اکاؤنٹ ایک ایسی ہستی ہے جس میں ایتھر (ETH) بیلنس ہوتا ہے جو Ethereum پر پیغامات بھیج سکتا ہے۔ اکاؤنٹس صارف کے زیر کنٹرول ہو سکتے ہیں یا اسمارٹ معاہدوں کے طور پر تعینات کیے جا سکتے ہیں۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے میں آپ کی مدد کرنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے ہمارا [Ethereum کا تعارف](/developers/docs/intro-to-ethereum/) پڑھیں۔ + +## اکاؤنٹ کی اقسام {#types-of-account} + +Ethereum میں دو قسم کے اکاؤنٹس ہیں: + +- بیرونی ملکیت والا اکاؤنٹ (EOA) – پرائیویٹ کیز رکھنے والے کسی بھی شخص کے زیر کنٹرول +- کنٹریکٹ اکاؤنٹ – نیٹ ورک پر تعینات ایک اسمارٹ کنٹریکٹ، جو کوڈ کے ذریعے کنٹرول ہوتا ہے۔ [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) کے بارے میں جانیں + +دونوں قسم کے اکاؤنٹس میں یہ صلاحیت ہوتی ہے: + +- ETH اور ٹوکنز وصول کرنا، رکھنا اور بھیجنا +- تعینات کردہ اسمارٹ معاہدوں کے ساتھ تعامل کرنا + +### اہم فرق {#key-differences} + +**بیرونی ملکیت** + +- اکاؤنٹ بنانے میں کوئی لاگت نہیں آتی +- لین دین شروع کر سکتا ہے +- بیرونی ملکیت والے اکاؤنٹس کے درمیان لین دین صرف ETH/ٹوکن کی منتقلی ہو سکتی ہے +- کلیدوں کے ایک خفیہ جوڑے پر مشتمل ہے: عوامی اور نجی کلیدیں جو اکاؤنٹ کی سرگرمیوں کو کنٹرول کرتی ہیں + +**کنٹریکٹ** + +- کنٹریکٹ بنانے میں لاگت آتی ہے کیونکہ آپ نیٹ ورک اسٹوریج استعمال کر رہے ہیں +- صرف لین دین موصول ہونے کے جواب میں پیغامات بھیج سکتا ہے +- ایک بیرونی اکاؤنٹ سے کنٹریکٹ اکاؤنٹ میں لین دین کوڈ کو متحرک کر سکتا ہے جو بہت سے مختلف اعمال انجام دے سکتا ہے، جیسے ٹوکن کی منتقلی یا یہاں تک کہ ایک نیا کنٹریکٹ بنانا +- کنٹریکٹ اکاؤنٹس میں نجی کلیدیں نہیں ہوتیں۔ اس کے بجائے، انہیں اسمارٹ کنٹریکٹ کوڈ کی منطق کے ذریعے کنٹرول کیا جاتا ہے + +## ایک اکاؤنٹ کا جائزہ {#an-account-examined} + +Ethereum اکاؤنٹس میں چار فیلڈز ہیں: + +- `nonce` – ایک کاؤنٹر جو بیرونی ملکیت والے اکاؤنٹ سے بھیجے گئے لین دین کی تعداد یا کنٹریکٹ اکاؤنٹ کے ذریعے بنائے گئے کنٹریکٹس کی تعداد کی نشاندہی کرتا ہے۔ ہر اکاؤنٹ کے لیے دیے گئے نانس کے ساتھ صرف ایک لین دین انجام دیا جا سکتا ہے، جو ری پلے حملوں سے بچاتا ہے جہاں دستخط شدہ لین دین کو بار بار نشر کیا جاتا ہے اور دوبارہ انجام دیا جاتا ہے۔ +- `بیلنس` – اس پتے کی ملکیت میں موجود wei کی تعداد۔ Wei, ETH کی ایک اکائی ہے اور فی ETH میں 1e+18 wei ہوتے ہیں۔ +- `codeHash` – یہ ہیش Ethereum ورچوئل مشین (EVM) پر ایک اکاؤنٹ کے _کوڈ_ کا حوالہ دیتا ہے۔ کنٹریکٹ اکاؤنٹس میں کوڈ کے ٹکڑے پروگرام کیے گئے ہیں جو مختلف آپریشن انجام دے سکتے ہیں۔ یہ EVM کوڈ اس وقت عمل میں آتا ہے جب اکاؤنٹ کو میسج کال موصول ہوتی ہے۔ دیگر اکاؤنٹ فیلڈز کے برعکس، اسے تبدیل نہیں کیا جا سکتا۔ ایسے تمام کوڈ کے ٹکڑے بعد میں بازیافت کے لیے ان کے متعلقہ ہیشز کے تحت اسٹیٹ ڈیٹا بیس میں موجود ہیں۔ اس ہیش ویلیو کو codeHash کے نام سے جانا جاتا ہے۔ بیرونی ملکیت والے اکاؤنٹس کے لیے، codeHash فیلڈ ایک خالی اسٹرنگ کا ہیش ہے۔ +- `storageRoot` – کبھی کبھی اسٹوریج ہیش کے طور پر جانا جاتا ہے۔ [مرکل پیٹریشیا ٹرائی](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) کے روٹ نوڈ کا 256 بٹ ہیش جو اکاؤنٹ کے اسٹوریج کے مواد کو انکوڈ کرتا ہے (256 بٹ انٹیجر ویلیوز کے درمیان ایک میپنگ)، جو 256 بٹ انٹیجر کیز کے Keccak 256-bit ہیش سے RLP-انکوڈ شدہ 256-بٹ انٹیجر ویلیوز تک میپنگ کے طور پر ٹرائی میں انکوڈ کیا گیا ہے۔ یہ ٹرائی اس اکاؤنٹ کے اسٹوریج مواد کے ہیش کو انکوڈ کرتا ہے، اور پہلے سے طے شدہ طور پر خالی ہے۔ + +![ایک اکاؤنٹ کی ساخت کو ظاہر کرنے والا ایک خاکہ](./accounts.png) +_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے اخذ کردہ خاکہ_ + +## بیرونی ملکیت والے اکاؤنٹس اور کلیدی جوڑے {#externally-owned-accounts-and-key-pairs} + +ایک اکاؤنٹ خفیہ کاری کلیدوں کے ایک جوڑے سے بنا ہوتا ہے: عوامی اور نجی۔ وہ یہ ثابت کرنے میں مدد کرتے ہیں کہ لین دین پر بھیجنے والے نے واقعی دستخط کیے تھے اور جعلسازی کو روکتے ہیں۔ آپ کی نجی کلید وہ ہے جسے آپ لین دین پر دستخط کرنے کے لیے استعمال کرتے ہیں، لہذا یہ آپ کو آپ کے اکاؤنٹ سے وابستہ فنڈز پر تحویل دیتی ہے۔ آپ واقعی کبھی بھی کرپٹو کرنسی نہیں رکھتے، آپ نجی کلیدیں رکھتے ہیں – فنڈز ہمیشہ Ethereum کے لیجر پر ہوتے ہیں۔ + +یہ بدنیتی پر مبنی اداکاروں کو جعلی لین دین کو نشر کرنے سے روکتا ہے کیونکہ آپ ہمیشہ لین دین کے بھیجنے والے کی تصدیق کر سکتے ہیں۔ + +اگر ایلس اپنے اکاؤنٹ سے باب کے اکاؤنٹ میں ایتھر بھیجنا چاہتی ہے، تو ایلس کو ایک لین دین کی درخواست بنانی ہوگی اور اسے تصدیق کے لیے نیٹ ورک پر بھیجنا ہوگا۔ Ethereum کا پبلک-کی کرپٹوگرافی کا استعمال اس بات کو یقینی بناتا ہے کہ ایلس یہ ثابت کر سکتی ہے کہ اس نے اصل میں لین دین کی درخواست شروع کی تھی۔ خفیہ کاری کے طریقہ کار کے بغیر، ایک بدنیتی پر مبنی مخالف حوا آسانی سے عوامی طور پر ایک ایسی درخواست نشر کر سکتی ہے جو کچھ اس طرح نظر آتی ہے “ایلس کے اکاؤنٹ سے حوا کے اکاؤنٹ میں 5 ETH بھیجیں،” اور کوئی بھی اس بات کی تصدیق نہیں کر سکے گا کہ یہ ایلس کی طرف سے نہیں آئی ہے۔ + +## اکاؤنٹ کی تخلیق {#account-creation} + +جب آپ ایک اکاؤنٹ بنانا چاہتے ہیں، تو زیادہ تر لائبریریاں آپ کے لیے ایک بے ترتیب نجی کلید تیار کریں گی۔ + +ایک نجی کلید 64 ہیکس حروف پر مشتمل ہوتی ہے اور اسے پاس ورڈ سے انکرپٹ کیا جا سکتا ہے۔ + +مثال: + +`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f` + +عوامی کلید نجی کلید سے [ایلیپٹک کرو ڈیجیٹل سگنیچر الگورتھم](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) کا استعمال کرتے ہوئے تیار کی جاتی ہے۔ آپ عوامی کلید کے Keccak-256 ہیش کے آخری 20 بائٹس لے کر اور شروع میں `0x` جوڑ کر اپنے اکاؤنٹ کے لیے ایک عوامی پتہ حاصل کرتے ہیں۔ + +اس کا مطلب ہے کہ ایک بیرونی ملکیت والے اکاؤنٹ (EOA) کا 42-حروف کا پتہ ہوتا ہے (20 بائٹ کا حصہ جو 40 ہیکساڈیسیمل حروف اور `0x` سابقہ پر مشتمل ہے)۔ + +مثال: + +`0x5e97870f263700f46aa00d967821199b9bc5a120` + +مندرجہ ذیل مثال دکھاتی ہے کہ ایک نیا اکاؤنٹ بنانے کے لیے [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) نامی سائننگ ٹول کا استعمال کیسے کریں۔ Clef ایک اکاؤنٹ مینجمنٹ اور سائننگ ٹول ہے جو Ethereum کلائنٹ، [Geth](https://geth.ethereum.org) کے ساتھ بنڈل میں آتا ہے۔ `clef newaccount` کمانڈ ایک نیا کلیدی جوڑا بناتا ہے اور انہیں ایک انکرپٹڈ کی اسٹور میں محفوظ کرتا ہے۔ + +``` +> clef newaccount --keystore + +براہ کرم بنائے جانے والے نئے اکاؤنٹ کے لیے ایک پاس ورڈ درج کریں: +> + +------------ +INFO [10-28|16:19:09.156] آپ کی نئی کلید تیار ہو گئی address=0x5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] براہ کرم اپنی کلیدی فائل کا بیک اپ لیں path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] براہ کرم اپنا پاس ورڈ یاد رکھیں! +تیار کردہ اکاؤنٹ 0x5e97870f263700f46aa00d967821199b9bc5a120 +``` + +[Geth دستاویزات](https://geth.ethereum.org/docs) + +اپنی نجی کلید سے نئی عوامی کلیدیں اخذ کرنا ممکن ہے، لیکن آپ عوامی کلیدوں سے نجی کلید اخذ نہیں کر سکتے۔ اپنی نجی کلیدوں کو محفوظ رکھنا بہت ضروری ہے اور، جیسا کہ نام سے ظاہر ہے، **نجی**۔ + +آپ کو پیغامات اور لین دین پر دستخط کرنے کے لیے ایک نجی کلید کی ضرورت ہے جو ایک دستخط آؤٹ پٹ کرتے ہیں۔ دوسرے پھر آپ کی عوامی کلید اخذ کرنے کے لیے دستخط لے سکتے ہیں، جو پیغام کے مصنف کو ثابت کرتا ہے۔ اپنی ایپلیکیشن میں، آپ نیٹ ورک پر لین دین بھیجنے کے لیے ایک JavaScript لائبریری استعمال کر سکتے ہیں۔ + +## کنٹریکٹ اکاؤنٹس {#contract-accounts} + +کنٹریکٹ اکاؤنٹس کا بھی 42 حروف کا ہیکساڈیسیمل پتہ ہوتا ہے: + +مثال: + +`0x06012c8cf97bead5deae237070f9587f8e7a266d` + +کنٹریکٹ کا پتہ عام طور پر اس وقت دیا جاتا ہے جب کوئی کنٹریکٹ Ethereum بلاک چین پر تعینات کیا جاتا ہے۔ پتہ تخلیق کار کے پتے اور اس پتے سے بھیجے گئے لین دین کی تعداد (“نانس”) سے آتا ہے۔ + +## توثیق کار کی کلیدیں {#validators-keys} + +Ethereum میں ایک اور قسم کی کلید بھی ہے، جو اس وقت متعارف کرائی گئی جب Ethereum نے پروف-آف-ورک سے پروف-آف-اسٹیک پر مبنی اتفاق رائے پر سوئچ کیا۔ یہ 'BLS' کلیدیں ہیں اور ان کا استعمال توثیق کاروں کی شناخت کے لیے کیا جاتا ہے۔ نیٹ ورک کو اتفاق رائے پر آنے کے لیے مطلوبہ بینڈوڈتھ کو کم کرنے کے لیے ان کلیدوں کو مؤثر طریقے سے جمع کیا جا سکتا ہے۔ اس کلیدی جمع کے بغیر ایک توثیق کار کے لیے کم از کم اسٹیک بہت زیادہ ہوگا۔ + +[توثیق کار کی کلیدوں پر مزید](/developers/docs/consensus-mechanisms/pos/keys/)۔ + +## بٹوے پر ایک نوٹ {#a-note-on-wallets} + +ایک اکاؤنٹ بٹوہ نہیں ہے۔ ایک بٹوہ ایک انٹرفیس یا ایپلیکیشن ہے جو آپ کو اپنے Ethereum اکاؤنٹ کے ساتھ تعامل کرنے دیتا ہے، چاہے وہ بیرونی ملکیت والا اکاؤنٹ ہو یا کنٹریکٹ اکاؤنٹ۔ + +## ایک بصری ڈیمو {#a-visual-demo} + +آسٹن کو ہیش فنکشنز اور کلیدی جوڑوں کے بارے میں بتاتے ہوئے دیکھیں۔ + + + + + +## مزید پڑھیں {#further-reading} + +- [Ethereum اکاؤنٹس کو سمجھنا](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) +- [ٹرانزیکشنز](/developers/docs/transactions/) diff --git a/public/content/translations/ur/developers/docs/apis/backend/index.md b/public/content/translations/ur/developers/docs/apis/backend/index.md new file mode 100644 index 00000000000..e2c2ceaa56c --- /dev/null +++ b/public/content/translations/ur/developers/docs/apis/backend/index.md @@ -0,0 +1,211 @@ +--- +title: "بیک اینڈ API لائبریریاں" +description: "Ethereum کلائنٹ APIs کا ایک تعارف جو آپ کو اپنی ایپلیکیشن سے بلاک چین کے ساتھ تعامل کرنے دیتا ہے۔" +lang: ur-in +--- + +Ethereum بلاک چین کے ساتھ تعامل کرنے کے لیے (یعنی، بلاک چین ڈیٹا کو پڑھنا اور/یا نیٹ ورک پر ٹرانزیکشن بھیجنا)، ایک سافٹ ویئر ایپلیکیشن کو Ethereum نوڈ سے جڑنا ہوگا۔ + +اس مقصد کے لیے، ہر Ethereum کلائنٹ [JSON-RPC](/developers/docs/apis/json-rpc/) تفصیلات کو نافذ کرتا ہے، لہذا [طریقوں](/developers/docs/apis/json-rpc/#json-rpc-methods) کا ایک یکساں سیٹ موجود ہے جس پر ایپلیکیشنز بھروسہ کر سکتی ہیں۔ + +اگر آپ ایک Ethereum نوڈ سے جڑنے کے لیے کسی مخصوص پروگرامنگ زبان کا استعمال کرنا چاہتے ہیں، تو ایکو سسٹم کے اندر بہت سی سہولتی لائبریریاں ہیں جو اسے بہت آسان بناتی ہیں۔ ان لائبریریوں کے ساتھ، ڈیولپرز JSON-RPC درخواستوں کو شروع کرنے کے لیے بدیہی، ایک لائن والے طریقے لکھ سکتے ہیں (اندرونی طور پر) جو Ethereum کے ساتھ تعامل کرتی ہیں۔ + +## شرائط {#prerequisites} + +[Ethereum stack](/developers/docs/ethereum-stack/) اور [Ethereum کلائنٹس](/developers/docs/nodes-and-clients/) کو سمجھنا مددگار ثابت ہو سکتا ہے۔ + +## لائبریری کا استعمال کیوں کریں؟ {#why-use-a-library} + +یہ لائبریریاں ایک Ethereum نوڈ کے ساتھ براہ راست تعامل کرنے کی بہت سی پیچیدگیوں کو دور کرتی ہیں۔ وہ یوٹیلیٹی فنکشنز (مثلاً، ETH کو Gwei میں تبدیل کرنا) بھی فراہم کرتی ہیں تاکہ ایک ڈیولپر کے طور پر آپ Ethereum کلائنٹس کی پیچیدگیوں سے نمٹنے میں کم وقت گزار سکیں اور اپنی ایپلیکیشن کی منفرد فعالیت پر زیادہ وقت مرکوز کر سکیں۔ + +## دستیاب لائبریریاں {#available-libraries} + +### انفراسٹرکچر اور نوڈ خدمات {#infrastructure-and-node-services} + +**Alchemy -** **_Ethereum ڈیولپمنٹ پلیٹ فارم۔_** + +- [alchemy.com](https://www.alchemy.com/) +- [دستاویزات](https://www.alchemy.com/docs/) +- [GitHub](https://github.com/alchemyplatform) +- [Discord](https://discord.com/invite/alchemyplatform) + +**All That Node -** **_نوڈ بطور سروس۔_** + +- [All That Node.com](https://www.allthatnode.com/) +- [دستاویزات](https://docs.allthatnode.com) +- [Discord](https://discord.gg/GmcdVEUbJM) + +**Blast by Bware Labs -** **_Ethereum مین نیٹ اور ٹیسٹ نیٹس کے لیے विकेंद्रीकृत APIs۔_** + +- [blastapi.io](https://blastapi.io/) +- [دستاویزات](https://docs.blastapi.io) +- [Discord](https://discord.gg/SaRqmRUjjQ) + +**BlockPi -** **_زیادہ موثر اور تیز RPC خدمات فراہم کریں_** + +- [blockpi.io](https://blockpi.io/) +- [دستاویزات](https://docs.blockpi.io/) +- [GitHub](https://github.com/BlockPILabs) +- [Discord](https://discord.com/invite/xTvGVrGVZv) + +**Cloudflare Ethereum گیٹ وے۔** + +- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/) + +**Etherscan - بلاک ایکسپلورر اور ٹرانزیکشن APIs** + +- [دستاویزات](https://docs.etherscan.io/) + +**Blockscout - اوپن سورس بلاک ایکسپلورر** + +- [دستاویزات](https://docs.blockscout.com/) + +**GetBlock-** **_Web3 ڈیولپمنٹ کے لیے بلاک چین بطور سروس_** + +- [GetBlock.io](https://getblock.io/) +- [دستاویزات](https://docs.getblock.io/) + +**Infura -** **_Ethereum API بطور سروس۔_** + +- [infura.io](https://infura.io) +- [دستاویزات](https://docs.infura.io/api) +- [GitHub](https://github.com/INFURA) + +**Node RPC - _کفایتی EVM JSON-RPC فراہم کنندہ_** + +- [noderpc.xyz](https://www.noderpc.xyz/) +- [دستاویزات](https://docs.noderpc.xyz/node-rpc) + +**NOWNodes - _مکمل نوڈز اور بلاک ایکسپلوررز۔_** + +- [NOWNodes.io](https://nownodes.io/) +- [دستاویزات](https://nownodes.gitbook.io/documentation) + +**QuickNode -** **_بلاک چین انفراسٹرکچر بطور سروس۔_** + +- [quicknode.com](https://quicknode.com) +- [دستاویزات](https://www.quicknode.com/docs/welcome) +- [Discord](https://discord.gg/quicknode) + +**Rivet -** **_اوپن سورس سافٹ ویئر سے چلنے والی Ethereum اور Ethereum Classic APIs بطور سروس۔_** + +- [rivet.cloud](https://rivet.cloud) +- [دستاویزات](https://rivet.cloud/docs/) +- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment) + +**Zmok -** **_JSON-RPC/WebSockets API کے طور پر رفتار پر مبنی Ethereum نوڈز۔_** + +- [zmok.io](https://zmok.io/) +- [GitHub](https://github.com/zmok-io) +- [دستاویزات](https://docs.zmok.io/) +- [Discord](https://discord.gg/fAHeh3ka6s) + +### ڈیولپمنٹ ٹولز {#development-tools} + +**ethers-kt -** **_EVM پر مبنی بلاک چینز کے لیے غیر مطابقت پذیر، اعلی کارکردگی والی Kotlin/Java/Android لائبریری۔_** + +- [GitHub](https://github.com/Kr1ptal/ethers-kt) +- [مثالیں](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [Discord](https://discord.gg/rx35NzQGSb) + +**Nethereum -** **_بلاک چین کے لیے ایک اوپن سورس .NET انٹیگریشن لائبریری۔_** + +- [GitHub](https://github.com/Nethereum/Nethereum) +- [دستاویزات](http://docs.nethereum.com/en/latest/) +- [Discord](https://discord.com/invite/jQPrR58FxX) + +**Python ٹولنگ -** **_پائیتھون کے ذریعے Ethereum کے ساتھ تعامل کے لیے مختلف لائبریریاں۔_** + +- [py.ethereum.org](https://snakecharmers.ethereum.org/) +- [web3.py GitHub](https://github.com/ethereum/web3.py) +- [web3.py چیٹ](https://gitter.im/ethereum/web3.py) + +**Tatum -** **_حتمی بلاک چین ڈیولپمنٹ پلیٹ فارم۔_** + +- [Tatum](https://tatum.io/) +- [GitHub](https://github.com/tatumio/) +- [دستاویزات](https://docs.tatum.io/) +- [Discord](https://discord.gg/EDmW3kjTC9) + +**web3j -** **_Ethereum کے لیے ایک Java/Android/Kotlin/Scala انٹیگریشن لائبریری۔_** + +- [GitHub](https://github.com/web3j/web3j) +- [دستاویزات](https://docs.web3j.io/) +- [Gitter](https://gitter.im/web3j/web3j) + +### بلاک چین خدمات {#blockchain-services} + +**BlockCypher -** **_Ethereum ویب APIs۔_** + +- [blockcypher.com](https://www.blockcypher.com/) +- [دستاویزات](https://www.blockcypher.com/dev/ethereum/) + +**Chainbase -** **_Ethereum کے لیے آل ان ون web3 ڈیٹا انفراسٹرکچر۔_** + +- [chainbase.com](https://chainbase.com/) +- [دستاویزات](https://docs.chainbase.com/) +- [Discord](https://discord.gg/Wx6qpqz4AF) + +**Chainstack -** **_بطور سروس لچکدار اور وقف شدہ Ethereum نوڈز۔_** + +- [chainstack.com](https://chainstack.com) +- [دستاویزات](https://docs.chainstack.com/) +- [Ethereum API حوالہ](https://docs.chainstack.com/reference/ethereum-getting-started) + +**Coinbase کلاؤڈ نوڈ -** **_بلاک چین انفراسٹرکچر API۔_** + +- [Coinbase کلاؤڈ نوڈ](https://www.coinbase.com/developer-platform) +- [دستاویزات](https://docs.cdp.coinbase.com/) + +**DataHub by Figment -** **_Ethereum مین نیٹ اور ٹیسٹ نیٹس کے ساتھ Web3 API خدمات۔_** + +- [DataHub](https://www.figment.io/) +- [دستاویزات](https://docs.figment.io/) + +**Moralis -** **_انٹرپرائز-گریڈ EVM API فراہم کنندہ۔_** + +- [moralis.io](https://moralis.io) +- [دستاویزات](https://docs.moralis.io/) +- [GitHub](https://github.com/MoralisWeb3) +- [Discord](https://moralis.io/joindiscord/) +- [فورم](https://forum.moralis.io/) + +**NFTPort -** **_Ethereum ڈیٹا اور منٹ APIs۔_** + +- [nftport.xyz](https://www.nftport.xyz/) +- [دستاویزات](https://docs.nftport.xyz/) +- [GitHub](https://github.com/nftport/) +- [Discord](https://discord.com/invite/K8nNrEgqhE) + +**Tokenview -** **_جنرل ملٹی-کرپٹو بلاک چین APIs پلیٹ فارم۔_** + +- [services.tokenview.io](https://services.tokenview.io/) +- [دستاویزات](https://services.tokenview.io/docs?type=api) +- [GitHub](https://github.com/Tokenview) + +**Watchdata -** **_Ethereum بلاک چین تک سادہ اور قابل اعتماد API رسائی فراہم کریں۔_** + +- [Watchdata](https://watchdata.io/) +- [دستاویزات](https://docs.watchdata.io/) +- [Discord](https://discord.com/invite/TZRJbZ6bdn) + +**Covalent -** **_200+ چینز کے لیے افزودہ بلاک چین APIs۔_** + +- [covalenthq.com](https://www.covalenthq.com/) +- [دستاویزات](https://www.covalenthq.com/docs/api/) +- [GitHub](https://github.com/covalenthq) +- [Discord](https://www.covalenthq.com/discord/) + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) +- [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [JavaScript میں Ethereum بلاک چین استعمال کرنے کے لیے Web3js سیٹ اپ کریں](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– آپ کے پروجیکٹ میں web3.js سیٹ اپ کرنے کی ہدایات۔_ +- [JavaScript سے ایک اسمارٹ معاہدے کو کال کرنا](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAI ٹوکن کا استعمال کرتے ہوئے، دیکھیں کہ JavaScript کا استعمال کرتے ہوئے معاہدے کے فنکشن کو کیسے کال کیا جائے۔_ diff --git a/public/content/translations/ur/developers/docs/apis/javascript/index.md b/public/content/translations/ur/developers/docs/apis/javascript/index.md new file mode 100644 index 00000000000..99feb763010 --- /dev/null +++ b/public/content/translations/ur/developers/docs/apis/javascript/index.md @@ -0,0 +1,289 @@ +--- +title: "JavaScript API لائبریریاں" +description: "JavaScript کلائنٹ لائبریریوں کا ایک تعارف جو آپ کو اپنی ایپلیکیشن سے بلاک چین کے ساتھ تعامل کرنے کی سہولت فراہم کرتی ہیں۔" +lang: ur-in +--- + +کسی ویب ایپ کو Ethereum بلاک چین کے ساتھ تعامل کرنے کے لیے (یعنی، بلاک چین ڈیٹا پڑھنا اور/یا نیٹ ورک پر لین دین بھیجنا)، اسے ایک Ethereum نوڈ سے جڑنا ضروری ہے۔ + +اس مقصد کے لیے، ہر Ethereum کلائنٹ [JSON-RPC](/developers/docs/apis/json-rpc/) کی تفصیلات کو نافذ کرتا ہے، لہذا [طریقوں](/developers/docs/apis/json-rpc/#json-rpc-methods) کا ایک یکساں سیٹ موجود ہے جس پر ایپلیکیشنز انحصار کر سکتی ہیں۔ + +اگر آپ Ethereum نوڈ سے جڑنے کے لیے JavaScript کا استعمال کرنا چاہتے ہیں، تو وینیلا JavaScript کا استعمال ممکن ہے لیکن ایکوسسٹم کے اندر کئی سہولت بخش لائبریریاں موجود ہیں جو اسے بہت آسان بناتی ہیں۔ ان لائبریریوں کے ساتھ، ڈیولپرز JSON-RPC درخواستوں کو شروع کرنے کے لیے بدیہی، ایک لائن والے طریقے لکھ سکتے ہیں (اندرونی طور پر) جو Ethereum کے ساتھ تعامل کرتی ہیں۔ + +براہ کرم نوٹ کریں کہ [The Merge](/roadmap/merge/) کے بعد سے، Ethereum سافٹ ویئر کے دو جڑے ہوئے ٹکڑے - ایک ایگزیکیوشن کلائنٹ اور ایک کنسینسس کلائنٹ - ایک نوڈ چلانے کے لیے درکار ہیں۔ براہ کرم یقینی بنائیں کہ آپ کے نوڈ میں ایگزیکیوشن اور کنسینسس کلائنٹ دونوں شامل ہیں۔ اگر آپ کا نوڈ آپ کی مقامی مشین پر نہیں ہے (مثال کے طور پر، آپ کا نوڈ AWS انسٹینس پر چل رہا ہے) تو ٹیوٹوریل میں IP پتوں کو اسی کے مطابق اپ ڈیٹ کریں۔ مزید معلومات کے لیے براہ کرم [نوڈ چلانے](/developers/docs/nodes-and-clients/run-a-node/) پر ہمارا صفحہ دیکھیں۔ + +## شرائط {#prerequisites} + +JavaScript کو سمجھنے کے ساتھ ساتھ، [Ethereum اسٹیک](/developers/docs/ethereum-stack/) اور [Ethereum کلائنٹس](/developers/docs/nodes-and-clients/) کو سمجھنا بھی مددگار ثابت ہوسکتا ہے۔ + +## لائبریری کا استعمال کیوں کریں؟ {#why-use-a-library} + +یہ لائبریریاں ایک Ethereum نوڈ کے ساتھ براہ راست تعامل کرنے کی بہت سی پیچیدگیوں کو دور کرتی ہیں۔ وہ یوٹیلیٹی فنکشنز (مثلاً، ETH کو Gwei میں تبدیل کرنا) بھی فراہم کرتی ہیں تاکہ ایک ڈیولپر کے طور پر آپ Ethereum کلائنٹس کی پیچیدگیوں سے نمٹنے میں کم وقت گزار سکیں اور اپنی ایپلیکیشن کی منفرد فعالیت پر زیادہ وقت مرکوز کر سکیں۔ + +## لائبریری کی خصوصیات {#library-features} + +### Ethereum نوڈز سے جڑیں {#connect-to-ethereum-nodes} + +پرووائیڈرس کا استعمال کرتے ہوئے، یہ لائبریریاں آپ کو Ethereum سے جڑنے اور اس کا ڈیٹا پڑھنے کی اجازت دیتی ہیں، چاہے وہ JSON-RPC، INFURA، Etherscan، Alchemy یا MetaMask کے ذریعے ہو۔ + +> **انتباہ:** Web3.js کو 4 مارچ، 2025 کو آرکائیو کر دیا گیا تھا۔ [اعلان پڑھیں](https://blog.chainsafe.io/web3-js-sunset/)۔ نئے پروجیکٹس کے لیے [ethers.js](https://ethers.org) یا [viem](https://viem.sh) جیسی متبادل لائبریریوں کا استعمال کرنے پر غور کریں۔ + +**Ethers کی مثال** + +```js +// ایک BrowserProvider ایک معیاری Web3 پرووائیڈر کو لپیٹتا ہے، جو ہے +// جو MetaMask ہر صفحے میں window.ethereum کے طور پر داخل کرتا ہے +const provider = new ethers.BrowserProvider(window.ethereum) + +// MetaMask پلگ ان لین دین پر دستخط کرنے کی بھی اجازت دیتا ہے +// ایتھر بھیجنے اور بلاک چین کے اندر اسٹیٹ کو تبدیل کرنے کے لیے ادائیگی کرنے کے لیے۔ +// اس کے لیے، ہمیں اکاؤنٹ سائنر کی ضرورت ہے... +const signer = provider.getSigner() +``` + +**Web3js کی مثال** + +```js +var web3 = new Web3("http://localhost:8545") +// یا +var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545")) + +// پرووائیڈر تبدیل کریں +web3.setProvider("ws://localhost:8546") +// یا +web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546")) + +// node.js میں IPC پرووائیڈر کا استعمال +var net = require("net") +var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // میک او ایس پاتھ +// یا +var web3 = new Web3( + new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net) +) // میک او ایس پاتھ +// ونڈوز پر پاتھ ہے: "\\\\.\\pipe\\geth.ipc" +// لینکس پر پاتھ ہے: "/users/myuser/.ethereum/geth.ipc" +``` + +ایک بار سیٹ اپ ہونے کے بعد آپ بلاک چین سے درج ذیل کے لیے استفسار کر سکیں گے: + +- بلاک نمبرز +- گیس کا تخمینہ +- اسمارٹ کنٹریکٹ کے ایونٹس +- نیٹ ورک آئی ڈی +- اور مزید... + +### والٹ کی فعالیت {#wallet-functionality} + +یہ لائبریریاں آپ کو والٹس بنانے، کیز کا انتظام کرنے اور لین دین پر دستخط کرنے کی فعالیت فراہم کرتی ہیں۔ + +یہاں Ethers کی ایک مثال ہے۔ + +```js +// ایک یادداشت سے ایک والٹ انسٹینس بنائیں... +mnemonic = + "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol" +walletMnemonic = Wallet.fromPhrase(mnemonic) + +// ...یا ایک پرائیویٹ کی سے +walletPrivateKey = new Wallet(walletMnemonic.privateKey) + +walletMnemonic.address === walletPrivateKey.address +// درست + +// سائنر API کے مطابق ایک پرومس کے طور پر پتہ +walletMnemonic.getAddress() +// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' } + +// ایک والٹ کا پتہ ہم وقت سازی سے بھی دستیاب ہے +walletMnemonic.address +// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' + +// اندرونی کرپٹوگرافک اجزاء +walletMnemonic.privateKey +// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db' +walletMnemonic.publicKey +// '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64' + +// والٹ کی یادداشت +walletMnemonic.mnemonic +// { +// locale: 'en', +// path: 'm/44\'/60\'/0\'/0/0', +// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol' +// } + +// نوٹ: ایک پرائیویٹ کی سے بنائے گئے والٹ میں +// یادداشت نہیں ہوتی (ڈیریویشن اسے روکتا ہے) +walletPrivateKey.mnemonic +// null + +// ایک پیغام پر دستخط کرنا +walletMnemonic.signMessage("Hello World") +// { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' } + +tx = { + to: "0x8ba1f109551bD432803012645Ac136ddd64DBA72", + value: utils.parseEther("1.0"), +} + +// ایک لین دین پر دستخط کرنا +walletMnemonic.signTransaction(tx) +// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' } + +// کنیکٹ میتھڈ والٹ کا نیا انسٹینس واپس کرتا ہے +// جو ایک پرووائیڈر سے جڑا ہوا ہے +wallet = walletMnemonic.connect(provider) + +// نیٹ ورک سے استفسار کرنا +wallet.getBalance() +// { Promise: { BigNumber: "42" } } +wallet.getTransactionCount() +// { Promise: 0 } + +// ایتھر بھیجنا +wallet.sendTransaction(tx) +``` + +[مکمل دستاویزات پڑھیں](https://docs.ethers.io/v5/api/signer/#Wallet) + +ایک بار سیٹ اپ ہونے کے بعد آپ یہ کر سکیں گے: + +- اکاؤنٹس بنانا +- لین دین بھیجنا +- لین دین پر دستخط کرنا +- اور مزید... + +### اسمارٹ کنٹریکٹ کے فنکشنز کے ساتھ تعامل کریں {#interact-with-smart-contract-functions} + +JavaScript کلائنٹ لائبریریاں آپ کی ایپلیکیشن کو ایک کمپائلڈ کنٹریکٹ کے ایپلیکیشن بائنری انٹرفیس (ABI) کو پڑھ کر اسمارٹ کنٹریکٹ کے فنکشنز کو کال کرنے کی اجازت دیتی ہیں۔ + +ABI بنیادی طور پر کنٹریکٹ کے فنکشنز کی JSON فارمیٹ میں وضاحت کرتا ہے اور آپ کو اسے ایک عام JavaScript آبجیکٹ کی طرح استعمال کرنے کی اجازت دیتا ہے۔ + +تو درج ذیل Solidity کنٹریکٹ: + +```solidity +contract Test { + uint a; + address d = 0x12345678901234567890123456789012; + + constructor(uint testInt) { a = testInt;} + + event Event(uint indexed b, bytes32 c); + + event Event2(uint indexed b, bytes32 c); + + function foo(uint b, bytes32 c) returns(address) { + Event(b, c); + return d; + } +} +``` + +اس کا نتیجہ درج ذیل JSON ہو گا: + +```json +[{ + "type":"constructor", + "payable":false, + "stateMutability":"nonpayable" + "inputs":[{"name":"testInt","type":"uint256"}], + },{ + "type":"function", + "name":"foo", + "constant":false, + "payable":false, + "stateMutability":"nonpayable", + "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}], + "outputs":[{"name":"","type":"address"}] + },{ + "type":"event", + "name":"Event", + "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}], + "anonymous":false + },{ + "type":"event", + "name":"Event2", + "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}], + "anonymous":false +}] +``` + +اس کا مطلب ہے کہ آپ یہ کر سکتے ہیں: + +- اسمارٹ کنٹریکٹ کو ایک لین دین بھیجیں اور اس کے میتھڈ پر عمل درآمد کریں +- EVM میں عمل درآمد ہونے پر ایک میتھڈ ایگزیکیوشن میں لگنے والی گیس کا تخمینہ لگانے کے لیے کال کریں +- ایک کنٹریکٹ تعینات کریں +- اور مزید... + +### یوٹیلیٹی فنکشنز {#utility-functions} + +یوٹیلیٹی فنکشنز آپ کو آسان شارٹ کٹس فراہم کرتے ہیں جو Ethereum کے ساتھ تعمیر کو تھوڑا آسان بنا دیتے ہیں۔ + +ETH کی قدریں ڈیفالٹ طور پر Wei میں ہوتی ہیں۔ 1 ETH = 1,000,000,000,000,000,000 WEI – اس کا مطلب ہے کہ آپ بہت سارے نمبروں سے نمٹ رہے ہیں! `web3.utils.toWei` آپ کے لیے ایتھر کو Wei میں تبدیل کرتا ہے۔ + +اور ethers میں یہ اس طرح لگتا ہے: + +```js +// ایک اکاؤنٹ کا بیلنس حاصل کریں (پتہ یا ENS نام کے ذریعے) +balance = await provider.getBalance("ethers.eth") +// { BigNumber: "2337132817842795605" } + +// اکثر آپ کو صارف کے لیے آؤٹ پٹ کو فارمیٹ کرنے کی ضرورت ہوگی +// جو (wei کے بجائے) ایتھر میں قدریں دیکھنا پسند کرتے ہیں +ethers.utils.formatEther(balance) +// '2.337132817842795605' +``` + +- [Web3js یوٹیلیٹی فنکشنز](https://docs.web3js.org/api/web3-utils) +- [Ethers یوٹیلیٹی فنکشنز](https://docs.ethers.org/v6/api/utils/) + +## دستیاب لائبریریاں {#available-libraries} + +**Web3.js -** **_Ethereum JavaScript API۔_** + +- [دستاویزات](https://docs.web3js.org) +- [GitHub](https://github.com/ethereum/web3.js) + +**Ethers.js -** **_JavaScript اور TypeScript میں مکمل Ethereum والٹ کا نفاذ اور یوٹیلیٹیز۔_** + +- [Ethers.js ہوم](https://ethers.org/) +- [دستاویزات](https://docs.ethers.io) +- [GitHub](https://github.com/ethers-io/ethers.js) + +**The Graph -** **_Ethereum اور IPFS ڈیٹا کو انڈیکس کرنے اور GraphQL کا استعمال کرتے ہوئے اس سے استفسار کرنے کا ایک پروٹوکول۔_** + +- [The Graph](https://thegraph.com) +- [Graph Explorer](https://thegraph.com/explorer) +- [دستاویزات](https://thegraph.com/docs) +- [GitHub](https://github.com/graphprotocol) +- [Discord](https://thegraph.com/discord) + +**Alchemy SDK -** **_Ethers.js کے ارد گرد ایک ریپر جس میں بہتر APIs ہیں۔_** + +- [دستاویزات](https://www.alchemy.com/docs) +- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js) + +**viem -** **_Ethereum کے لیے TypeScript انٹرفیس۔_** + +- [دستاویزات](https://viem.sh) +- [GitHub](https://github.com/wagmi-dev/viem) + +**Drift -** **_بلٹ ان کیشنگ، ہکس، اور ٹیسٹ ماکس کے ساتھ TypeScript میٹا لائبریری۔_** + +- [دستاویزات](https://ryangoree.github.io/drift/) +- [GitHub](https://github.com/ryangoree/drift/) + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) +- [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [JavaScript میں Ethereum بلاک چین استعمال کرنے کے لیے Web3js سیٹ اپ کریں](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– آپ کے پروجیکٹ میں web3.js سیٹ اپ کرنے کی ہدایات۔_ +- [JavaScript سے ایک اسمارٹ معاہدے کو کال کرنا](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAI ٹوکن کا استعمال کرتے ہوئے، دیکھیں کہ JavaScript کا استعمال کرتے ہوئے معاہدے کے فنکشن کو کیسے کال کیا جائے۔_ +- [web3 اور Alchemy کا استعمال کرتے ہوئے لین دین بھیجنا](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– بیک اینڈ سے لین دین بھیجنے کے لیے مرحلہ وار واک تھرو۔_ diff --git a/public/content/translations/ur/developers/docs/apis/json-rpc/index.md b/public/content/translations/ur/developers/docs/apis/json-rpc/index.md new file mode 100644 index 00000000000..c1265e12207 --- /dev/null +++ b/public/content/translations/ur/developers/docs/apis/json-rpc/index.md @@ -0,0 +1,1897 @@ +--- +title: JSON-RPC API +description: "ایتھیریم کلائنٹس کے لیے ایک اسٹیٹ لیس، ہلکا پھلکا ریموٹ پروسیجر کال (RPC) پروٹوکول۔" +lang: ur-in +--- + +کسی سافٹ ویئر ایپلیکیشن کو ایتھیریم بلاک چین کے ساتھ تعامل کرنے کے لیے - یا تو بلاک چین ڈیٹا پڑھ کر یا نیٹ ورک پر ٹرانزیکشنز بھیج کر - اسے ایتھیریم نوڈ سے منسلک ہونا چاہیے۔ + +اس مقصد کے لیے، ہر [ایتھیریم کلائنٹ](/developers/docs/nodes-and-clients/#execution-clients) [JSON-RPC اسپیسیفکیشن](https://github.com/ethereum/execution-apis) کو نافذ کرتا ہے، لہذا طریقوں کا ایک یکساں سیٹ ہے جس پر ایپلیکیشنز مخصوص نوڈ یا کلائنٹ کے نفاذ سے قطع نظر انحصار کر سکتی ہیں۔ + +[JSON-RPC](https://www.jsonrpc.org/specification) ایک اسٹیٹ لیس، ہلکا پھلکا ریموٹ پروسیجر کال (RPC) پروٹوکول ہے۔ یہ کئی ڈیٹا ڈھانچوں اور ان کی پروسیسنگ کے ارد گرد کے اصولوں کی وضاحت کرتا ہے۔ یہ ٹرانسپورٹ ایگنوسٹک ہے اس لحاظ سے کہ تصورات کو اسی عمل کے اندر، ساکٹ پر، HTTP پر، یا بہت سے مختلف پیغام بھیجنے والے ماحول میں استعمال کیا جا سکتا ہے۔ یہ JSON (RFC 4627) کو ڈیٹا فارمیٹ کے طور پر استعمال کرتا ہے۔ + +## کلائنٹ کے نفاذ {#client-implementations} + +JSON-RPC اسپیسیفکیشن کو نافذ کرتے وقت ایتھیریم کلائنٹس ہر ایک مختلف پروگرامنگ زبانوں کا استعمال کر سکتے ہیں۔ مخصوص پروگرامنگ زبانوں سے متعلق مزید تفصیلات کے لیے انفرادی [کلائنٹ کی دستاویزات](/developers/docs/nodes-and-clients/#execution-clients) دیکھیں۔ ہم تازہ ترین API سپورٹ کی معلومات کے لیے ہر کلائنٹ کی دستاویزات کو چیک کرنے کی تجویز کرتے ہیں۔ + +## سہولت کی لائبریریاں {#convenience-libraries} + +جبکہ آپ JSON-RPC API کے ذریعے ایتھیریم کلائنٹس کے ساتھ براہ راست تعامل کا انتخاب کر سکتے ہیں، dapp ڈویلپرز کے لیے اکثر آسان آپشنز ہوتے ہیں۔ JSON-RPC API کے اوپر ریپرز فراہم کرنے کے لیے بہت سی [JavaScript](/developers/docs/apis/javascript/#available-libraries) اور [بیک اینڈ API](/developers/docs/apis/backend/#available-libraries) لائبریریاں موجود ہیں۔ ان لائبریریوں کے ساتھ، ڈویلپرز اپنی پسند کی پروگرامنگ زبان میں JSON-RPC درخواستوں کو شروع کرنے کے لیے بدیہی، یک سطری طریقے لکھ سکتے ہیں (ہڈ کے نیچے) جو ایتھیریم کے ساتھ تعامل کرتی ہیں۔ + +## اتفاق رائے کلائنٹ APIs {#consensus-clients} + +یہ صفحہ بنیادی طور پر ایتھیریم کے ایگزیکیوشن کلائنٹس کے ذریعے استعمال ہونے والے JSON-RPC API سے متعلق ہے۔ تاہم، کنسنسس کلائنٹس کے پاس ایک RPC API بھی ہے جو صارفین کو نوڈ کے بارے میں معلومات کی استفسار کرنے، بیکن بلاکس، بیکن کی حالت، اور دیگر کنسنسس سے متعلق معلومات کو براہ راست نوڈ سے درخواست کرنے کی اجازت دیتا ہے۔ یہ API [بیکن API ویب پیج](https://ethereum.github.io/beacon-APIs/#/) پر دستاویز کی گئی ہے۔ + +ایک اندرونی API بھی ایک نوڈ کے اندر انٹر-کلائنٹ مواصلات کے لیے استعمال ہوتا ہے - یعنی یہ کنسنسس کلائنٹ اور ایگزیکیوشن کلائنٹ کو ڈیٹا کی تبادلہ کرنے کے قابل بناتا ہے۔ اسے 'انجن API' کہا جاتا ہے اور اس کی تفصیلات [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) پر دستیاب ہیں۔ + +## ایگزیکیوشن کلائنٹ کی تفصیلات {#spec} + +[GitHub پر مکمل JSON-RPC API کی تفصیلات پڑھیں](https://github.com/ethereum/execution-apis)۔ یہ API [ایگزیکیوشن API ویب پیج](https://ethereum.github.io/execution-apis/) پر دستاویز کی گئی ہے اور اس میں تمام دستیاب طریقوں کو آزمانے کے لیے ایک انسپکٹر شامل ہے۔ + +## روایات {#conventions} + +### ہیکس ویلیو انکوڈنگ {#hex-encoding} + +JSON پر دو کلیدی ڈیٹا کی اقسام منتقل کی جاتی ہیں: غیر فارمیٹ شدہ بائٹ ارے اور مقداریں۔ دونوں کو ہیکس انکوڈنگ کے ساتھ پاس کیا جاتا ہے لیکن فارمیٹنگ کے لیے مختلف ضروریات کے ساتھ۔ + +#### مقداریں {#quantities-encoding} + +مقداروں (انٹیجرز، نمبرز) کو انکوڈ کرتے وقت: ہیکس کے طور پر انکوڈ کریں، "0x" کے ساتھ پریفکس کریں، سب سے زیادہ کمپیکٹ نمائندگی (معمولی استثناء: صفر کو "0x0" کے طور پر نمائندگی کیا جانا چاہئے)۔ + +یہاں کچھ مثالیں ہیں: + +- 0x41 (اعشاریہ میں 65) +- 0x400 (اعشاریہ میں 1024) +- غلط: 0x (کم از کم ایک ہندسہ ہونا چاہئے - صفر "0x0" ہے) +- غلط: 0x0400 (آگے صفر کی اجازت نہیں ہے) +- غلط: ff (0x سے شروع ہونا چاہئے) + +### غیر فارمیٹ شدہ ڈیٹا {#unformatted-data-encoding} + +غیر فارمیٹ شدہ ڈیٹا (بائٹ ارے، اکاؤنٹ کے پتے، ہیشز، بائٹ کوڈ ارے) کو انکوڈ کرتے وقت: ہیکس کے طور پر انکوڈ کریں، "0x" کے ساتھ پریفکس کریں، فی بائٹ دو ہیکس ہندسے۔ + +یہاں کچھ مثالیں ہیں: + +- 0x41 (سائز 1, "A") +- 0x004200 (سائز 3, "0B0") +- 0x (سائز 0, "") +- غلط: 0xf0f0f (ہندسوں کی تعداد جفت ہونی چاہئے) +- غلط: 004200 (0x سے شروع ہونا چاہئے) + +### بلاک پیرامیٹر {#block-parameter} + +مندرجہ ذیل طریقوں میں ایک بلاک پیرامیٹر ہے: + +- [eth_getBalance](#eth_getbalance) +- [eth_getCode](#eth_getcode) +- [eth_getTransactionCount](#eth_gettransactioncount) +- [eth_getStorageAt](#eth_getstorageat) +- [eth_call](#eth_call) + +جب ایتھیریم کی حالت کی استفسار کرنے والی درخواستیں کی جاتی ہیں، تو فراہم کردہ بلاک پیرامیٹر بلاک کی اونچائی کا تعین کرتا ہے۔ + +بلاک پیرامیٹر کے لیے مندرجہ ذیل آپشنز ممکن ہیں: + +- `HEX String` - ایک انٹیجر بلاک نمبر +- سب سے ابتدائی/جینیسس بلاک کے لیے `String "earliest"` +- `String "latest"` - تازہ ترین مجوزہ بلاک کے لیے +- `String "safe"` - تازہ ترین محفوظ ہیڈ بلاک کے لیے +- `String "finalized"` - تازہ ترین حتمی بلاک کے لیے +- `String "pending"` - زیر التواء حالت/ٹرانزیکشنز کے لیے + +## مثالیں + +اس صفحہ پر ہم کمانڈ لائن ٹول، [curl](https://curl.se) کا استعمال کرتے ہوئے انفرادی JSON_RPC API اینڈ پوائنٹس کو استعمال کرنے کی مثالیں فراہم کرتے ہیں۔ یہ انفرادی اینڈ پوائنٹ مثالیں نیچے [Curl مثالیں](#curl-examples) سیکشن میں ملیں گی۔ صفحے پر مزید نیچے، ہم Geth نوڈ، JSON_RPC API اور curl کا استعمال کرتے ہوئے ایک سمارٹ کنٹریکٹ کو مرتب کرنے اور تعینات کرنے کے لیے ایک [اینڈ ٹو اینڈ مثال](#usage-example) بھی فراہم کرتے ہیں۔ + +## Curl مثالیں {#curl-examples} + +ایتھیریم نوڈ پر [curl](https://curl.se) درخواستیں دے کر JSON_RPC API کا استعمال کرنے کی مثالیں نیچے دی گئی ہیں۔ ہر مثال میں مخصوص اینڈ پوائنٹ کی تفصیل، اس کے پیرامیٹرز، واپسی کی قسم، اور اسے کیسے استعمال کیا جانا چاہئے کی ایک عملی مثال شامل ہے۔ + +curl درخواستیں مواد کی قسم سے متعلق ایک غلطی کا پیغام واپس کر سکتی ہیں۔ ایسا اس لیے ہے کیونکہ `--data` آپشن مواد کی قسم کو `application/x-www-form-urlencoded` پر سیٹ کرتا ہے۔ اگر آپ کا نوڈ اس کے بارے میں شکایت کرتا ہے، تو کال کے آغاز میں `-H "Content-Type: application/json"` رکھ کر ہیڈر کو دستی طور پر سیٹ کریں۔ مثالوں میں URL/IP اور پورٹ کا امتزاج بھی شامل نہیں ہے جو curl کو دیا جانے والا آخری آرگیومنٹ ہونا چاہیے (مثلاً، `127.0.0.1:8545`)۔ ان اضافی ڈیٹا سمیت ایک مکمل curl درخواست مندرجہ ذیل شکل اختیار کرتی ہے: + +```shell +curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545 +``` + +## گپ شپ، حالت، تاریخ {#gossip-state-history} + +چند بنیادی JSON-RPC طریقوں کو ایتھیریم نیٹ ورک سے ڈیٹا کی ضرورت ہوتی ہے، اور یہ صاف طور پر تین اہم زمروں میں آتے ہیں: _گپ شپ، حالت، اور تاریخ_۔ ہر طریقے پر جانے کے لیے ان سیکشنز میں لنکس کا استعمال کریں، یا طریقوں کی پوری فہرست کو دریافت کرنے کے لیے مندرجات کا جدول استعمال کریں۔ + +### گپ شپ کے طریقے {#gossip-methods} + +> یہ طریقے زنجیر کے سر کو ٹریک کرتے ہیں۔ یہ ہے کہ کس طرح ٹرانزیکشنز نیٹ ورک کے گرد اپنا راستہ بناتی ہیں، بلاکس میں اپنا راستہ تلاش کرتی ہیں، اور کلائنٹس نئے بلاکس کے بارے میں کیسے جانتے ہیں۔ + +- [eth_blockNumber](#eth_blocknumber) +- [eth_sendRawTransaction](#eth_sendrawtransaction) + +### اسٹیٹ کے طریقے {#state_methods} + +> وہ طریقے جو ذخیرہ شدہ تمام ڈیٹا کی موجودہ حالت کی اطلاع دیتے ہیں۔ "حالت" RAM کے ایک بڑے مشترکہ ٹکڑے کی طرح ہے، اور اس میں اکاؤنٹ بیلنس، کنٹریکٹ ڈیٹا، اور گیس کا تخمینہ شامل ہے۔ + +- [eth_getBalance](#eth_getbalance) +- [eth_getStorageAt](#eth_getstorageat) +- [eth_getTransactionCount](#eth_gettransactioncount) +- [eth_getCode](#eth_getcode) +- [eth_call](#eth_call) +- [eth_estimateGas](#eth_estimategas) + +### تاریخ کے طریقے {#history_methods} + +> جینیسس تک ہر بلاک کے تاریخی ریکارڈز کو حاصل کرتا ہے۔ یہ ایک بڑی صرف شامل کرنے والی فائل کی طرح ہے، اور اس میں تمام بلاک ہیڈرز، بلاک باڈیز، انکل بلاکس، اور ٹرانزیکشن کی رسیدیں شامل ہیں۔ + +- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash) +- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber) +- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash) +- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber) +- [eth_getBlockByHash](#eth_getblockbyhash) +- [eth_getBlockByNumber](#eth_getblockbynumber) +- [eth_getTransactionByHash](#eth_gettransactionbyhash) +- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex) +- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex) +- [eth_getTransactionReceipt](#eth_gettransactionreceipt) +- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex) +- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex) + +## JSON-RPC API پلے گراؤنڈ + +آپ API طریقوں کو دریافت کرنے اور آزمانے کے لیے [پلے گراؤنڈ ٹول](https://ethereum-json-rpc.com) کا استعمال کر سکتے ہیں۔ یہ آپ کو یہ بھی دکھاتا ہے کہ کون سے طریقے اور نیٹ ورکس مختلف نوڈ فراہم کنندگان کے ذریعہ معاونت یافتہ ہیں۔ + +## JSON-RPC API کے طریقے {#json-rpc-methods} + +### web3_clientVersion {#web3_clientversion} + +موجودہ کلائنٹ ورژن واپس کرتا ہے۔ + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`String` - موجودہ کلائنٹ ورژن + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' +// نتیجہ +{ + "id":67, + "jsonrpc":"2.0", + "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1" +} +``` + +### web3_sha3 {#web3_sha3} + +دیئے گئے ڈیٹا کا Keccak-256 (_نہ کہ_ معیاری SHA3-256) واپس کرتا ہے۔ + +**پیرامیٹرز** + +1. `DATA` - SHA3 ہیش میں تبدیل کرنے کے لیے ڈیٹا + +```js +params: ["0x68656c6c6f20776f726c64"] +``` + +**واپسی** + +`DATA` - دیئے گئے سٹرنگ کا SHA3 نتیجہ۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' +// نتیجہ +{ + "id":64, + "jsonrpc": "2.0", + "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad" +} +``` + +### net_version {#net_version} + +موجودہ نیٹ ورک آئی ڈی واپس کرتا ہے۔ + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`String` - موجودہ نیٹ ورک آئی ڈی۔ + +موجودہ نیٹ ورک IDs کی مکمل فہرست [chainlist.org](https://chainlist.org) پر دستیاب ہے۔ کچھ عام یہ ہیں: + +- `1`: ایتھیریم مین نیٹ +- `11155111`: Sepolia ٹیسٹ نیٹ +- `560048` : Hoodi ٹیسٹ نیٹ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' +// نتیجہ +{ + "id":67, + "jsonrpc": "2.0", + "result": "3" +} +``` + +### net_listening {#net_listening} + +اگر کلائنٹ فعال طور پر نیٹ ورک کنکشنز کے لیے سن رہا ہے تو `true` واپس کرتا ہے۔ + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`Boolean` - سنتے وقت `true`، ورنہ `false`۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' +// نتیجہ +{ + "id":67, + "jsonrpc":"2.0", + "result":true +} +``` + +### net_peerCount {#net_peercount} + +اس وقت کلائنٹ سے منسلک پیئرز کی تعداد واپس کرتا ہے۔ + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`QUANTITY` - منسلک پیئرز کی تعداد کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' +// نتیجہ +{ + "id":74, + "jsonrpc": "2.0", + "result": "0x2" // 2 +} +``` + +### eth_protocolVersion {#eth_protocolversion} + +موجودہ ایتھیریم پروٹوکول ورژن واپس کرتا ہے۔ نوٹ کریں کہ یہ طریقہ [Geth میں دستیاب نہیں ہے](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)۔ + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`String` - موجودہ ایتھیریم پروٹوکول ورژن + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}' +// نتیجہ +{ + "id":67, + "jsonrpc": "2.0", + "result": "54" +} +``` + +### eth_syncing {#eth_syncing} + +سنک کی حیثیت کے بارے میں ڈیٹا کے ساتھ ایک آبجیکٹ یا `false` واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +درست واپسی کا ڈیٹا کلائنٹ کے نفاذ کے درمیان مختلف ہوتا ہے۔ جب نوڈ سنک نہیں ہو رہا ہوتا ہے تو تمام کلائنٹس `False` واپس کرتے ہیں، اور تمام کلائنٹس مندرجہ ذیل فیلڈز واپس کرتے ہیں۔ + +`Object|Boolean`، سنک اسٹیٹس ڈیٹا کے ساتھ ایک آبجیکٹ یا `FALSE`، جب سنک نہ ہو رہا ہو: + +- `startingBlock`: `QUANTITY` - وہ بلاک جس پر امپورٹ شروع ہوا (صرف ری سیٹ کیا جائے گا، جب سنک اس کے ہیڈ تک پہنچ جائے) +- `currentBlock`: `QUANTITY` - موجودہ بلاک، eth_blockNumber کی طرح +- `highestBlock`: `QUANTITY` - تخمینہ شدہ سب سے اونچا بلاک + +تاہم، انفرادی کلائنٹس اضافی ڈیٹا بھی فراہم کر سکتے ہیں۔ مثال کے طور پر Geth مندرجہ ذیل واپس کرتا ہے: + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "currentBlock": "0x3cf522", + "healedBytecodeBytes": "0x0", + "healedBytecodes": "0x0", + "healedTrienodes": "0x0", + "healingBytecode": "0x0", + "healingTrienodes": "0x0", + "highestBlock": "0x3e0e41", + "startingBlock": "0x3cbed5", + "syncedAccountBytes": "0x0", + "syncedAccounts": "0x0", + "syncedBytecodeBytes": "0x0", + "syncedBytecodes": "0x0", + "syncedStorage": "0x0", + "syncedStorageBytes": "0x0" + } +} +``` + +جبکہ Besu واپس کرتا ہے: + +```json +{ + "jsonrpc": "2.0", + "id": 51, + "result": { + "startingBlock": "0x0", + "currentBlock": "0x1518", + "highestBlock": "0x9567a3", + "pulledStates": "0x203ca", + "knownStates": "0x200636" + } +} +``` + +مزید تفصیلات کے لیے اپنے مخصوص کلائنٹ کی دستاویزات سے رجوع کریں۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": { + startingBlock: '0x384', + currentBlock: '0x386', + highestBlock: '0x454' + } +} +// یا جب سنک نہ ہو رہا ہو +{ + "id":1, + "jsonrpc": "2.0", + "result": false +} +``` + +### eth_coinbase {#eth_coinbase} + +کلائنٹ کوائن بیس ایڈریس واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +> **نوٹ:** یہ طریقہ **v1.14.0** سے متروک ہو گیا ہے اور اب اس کی حمایت نہیں کی جاتی ہے۔ اس طریقے کو استعمال کرنے کی کوشش کے نتیجے میں "طریقہ معاونت یافتہ نہیں" کی خرابی ہوگی۔ + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`DATA`، 20 بائٹس - موجودہ کوائن بیس ایڈریس۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}' +// نتیجہ +{ + "id":64, + "jsonrpc": "2.0", + "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1" +} +``` + +### eth_chainId {#eth_chainId} + +ری پلے سے محفوظ ٹرانزیکشنز پر دستخط کرنے کے لیے استعمال ہونے والی چین آئی ڈی واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`chainId`، ایک سٹرنگ کے طور پر ہیکساڈیسیمل ویلیو جو موجودہ چین آئی ڈی کے انٹیجر کی نمائندگی کرتی ہے۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}' +// نتیجہ +{ + "id":67, + "jsonrpc": "2.0", + "result": "0x1" +} +``` + +### eth_mining {#eth_mining} + +اگر کلائنٹ فعال طور پر نئے بلاکس کی مائننگ کر رہا ہے تو `true` واپس کرتا ہے۔ یہ صرف پروف-آف-ورک نیٹ ورکس کے لیے `true` واپس کر سکتا ہے اور [The Merge](/roadmap/merge/) کے بعد سے کچھ کلائنٹس میں دستیاب نہیں ہو سکتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`Boolean` - اگر کلائنٹ مائننگ کر رہا ہے تو `true` واپس کرتا ہے، ورنہ `false`۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}' +// +{ + "id":71, + "jsonrpc": "2.0", + "result": true +} +``` + +### eth_hashrate {#eth_hashrate} + +نوڈ فی سیکنڈ جتنے ہیشز کے ساتھ مائننگ کر رہا ہے ان کی تعداد واپس کرتا ہے۔ یہ صرف پروف-آف-ورک نیٹ ورکس کے لیے `true` واپس کر سکتا ہے اور [The Merge](/roadmap/merge/) کے بعد سے کچھ کلائنٹس میں دستیاب نہیں ہو سکتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`QUANTITY` - فی سیکنڈ ہیشز کی تعداد۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}' +// نتیجہ +{ + "id":71, + "jsonrpc": "2.0", + "result": "0x38a" +} +``` + +### eth_gasPrice {#eth_gasprice} + +wei میں فی گیس کی موجودہ قیمت کا تخمینہ واپس کرتا ہے۔ مثال کے طور پر، Besu کلائنٹ آخری 100 بلاکس کا معائنہ کرتا ہے اور بطور ڈیفالٹ میڈین گیس یونٹ کی قیمت واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`QUANTITY` - wei میں موجودہ گیس کی قیمت کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' +// نتیجہ +{ + "id":73, + "jsonrpc": "2.0", + "result": "0x1dfd14000" // 8049999872 Wei +} +``` + +### eth_accounts {#eth_accounts} + +کلائنٹ کی ملکیت والے پتوں کی فہرست واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`DATA کا ارے`، 20 بائٹس - کلائنٹ کی ملکیت والے پتے۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"] +} +``` + +### eth_blockNumber {#eth_blocknumber} + +سب سے حالیہ بلاک کا نمبر واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +کوئی نہیں + +**واپسی** + +`QUANTITY` - موجودہ بلاک نمبر کا انٹیجر جس پر کلائنٹ ہے۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' +// نتیجہ +{ + "id":83, + "jsonrpc": "2.0", + "result": "0x4b7" // 1207 +} +``` + +### eth_getBalance {#eth_getbalance} + +دیے گئے ایڈریس پر اکاؤنٹ کا بیلنس واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 20 بائٹس - بیلنس چیک کرنے کے لیے پتہ۔ +2. `QUANTITY|TAG` - انٹیجر بلاک نمبر، یا سٹرنگ `"latest"`، `"earliest"`، `"pending"`، `"safe"`، یا `"finalized"`، [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) دیکھیں۔ + +```js +params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] +``` + +**واپسی** + +`QUANTITY` - wei میں موجودہ بیلنس کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x0234c8a3397aab58" // 158972490234375000 +} +``` + +### eth_getStorageAt {#eth_getstorageat} + +ایک دیئے گئے پتے پر اسٹوریج کی پوزیشن سے ویلیو واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 20 بائٹس - اسٹوریج کا پتہ۔ +2. `QUANTITY` - اسٹوریج میں پوزیشن کا انٹیجر۔ +3. `QUANTITY|TAG` - انٹیجر بلاک نمبر، یا سٹرنگ `"latest"`، `"earliest"`، `"pending"`، `"safe"`، `"finalized"`، [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) دیکھیں۔ + +**واپسی** + +`DATA` - اس اسٹوریج پوزیشن پر ویلیو۔ + +**مثال** +صحیح پوزیشن کا حساب لگانا بازیافت کرنے کے لیے اسٹوریج پر منحصر ہے۔ ایڈریس `0x391694e7e0b0cce554cb130d723a9d27458f9298` کے ذریعے `0x295a70b2de5e3953354a6a8344e616ed314d7251` پر تعینات مندرجہ ذیل کنٹریکٹ پر غور کریں۔ + +``` +contract Storage { + uint pos0; + mapping(address => uint) pos1; + constructor() { + pos0 = 1234; + pos1[msg.sender] = 5678; + } +} +``` + +pos0 کی قدر بازیافت کرنا سیدھا ہے: + +```js +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} +``` + +نقشے کے ایک عنصر کو بازیافت کرنا زیادہ مشکل ہے۔ نقشے میں ایک عنصر کی پوزیشن کا حساب اس کے ساتھ کیا جاتا ہے: + +```js +keccak(LeftPad32(key, 0), LeftPad32(map position, 0)) +``` + +اس کا مطلب ہے کہ pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] پر اسٹوریج کو بازیافت کرنے کے لیے ہمیں پوزیشن کا حساب اس کے ساتھ کرنا ہوگا: + +```js +keccak( + decodeHex( + "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + + "0000000000000000000000000000000000000000000000000000000000000001" + ) +) +``` + +web3 لائبریری کے ساتھ آنے والا geth کنسول حساب کتاب کرنے کے لیے استعمال کیا جا سکتا ہے: + +```js +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +اب اسٹوریج کو حاصل کرنے کے لیے: + +```js +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +### eth_getTransactionCount {#eth_gettransactioncount} + +ایک پتے سے _بھیجی گئی_ ٹرانزیکشنز کی تعداد واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 20 بائٹس - پتہ۔ +2. `QUANTITY|TAG` - انٹیجر بلاک نمبر، یا سٹرنگ `"latest"`، `"earliest"`، `"pending"`، `"safe"` یا `"finalized"`، [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) دیکھیں۔ + +```js +params: [ + "0x407d73d8a49eeb85d32cf465507dd71d507100c1", + "latest", // تازہ ترین بلاک پر حالت +] +``` + +**واپسی** + +`QUANTITY` - اس ایڈریس سے بھیجے گئے ٹرانزیکشنز کی تعداد کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash} + +دیئے گئے بلاک ہیش سے مماثل بلاک سے ایک بلاک میں ٹرانزیکشنز کی تعداد واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک بلاک کا ہیش + +```js +params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] +``` + +**واپسی** + +`QUANTITY` - اس بلاک میں ٹرانزیکشنز کی تعداد کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x8b" // 139 +} +``` + +### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber} + +دیئے گئے بلاک نمبر سے مماثل بلاک میں ٹرانزیکشنز کی تعداد واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `QUANTITY|TAG` - ایک بلاک نمبر کا انٹیجر، یا سٹرنگ `"earliest"`، `"latest"`، `"pending"`، `"safe"` یا `"finalized"`، جیسا کہ [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) میں ہے۔ + +```js +params: [ + "0x13738ca", // 20396234 +] +``` + +**واپسی** + +`QUANTITY` - اس بلاک میں ٹرانزیکشنز کی تعداد کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x8b" // 139 +} +``` + +### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash} + +دیئے گئے بلاک ہیش سے مماثل بلاک سے ایک بلاک میں انکلز کی تعداد واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک بلاک کا ہیش + +```js +params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] +``` + +**واپسی** + +`QUANTITY` - اس بلاک میں انکلز کی تعداد کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber} + +دیئے گئے بلاک نمبر سے مماثل بلاک سے ایک بلاک میں انکلز کی تعداد واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `QUANTITY|TAG` - ایک بلاک نمبر کا انٹیجر، یا سٹرنگ `"latest"`، `"earliest"`، `"pending"`، `"safe"` یا `"finalized"`، [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) دیکھیں۔ + +```js +params: [ + "0xe8", // 232 +] +``` + +**واپسی** + +`QUANTITY` - اس بلاک میں انکلز کی تعداد کا انٹیجر۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x0" // 0 +} +``` + +### eth_getCode {#eth_getcode} + +ایک دیئے گئے پتے پر کوڈ واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 20 بائٹس - پتہ +2. `QUANTITY|TAG` - انٹیجر بلاک نمبر، یا سٹرنگ `"latest"`، `"earliest"`، `"pending"`، `"safe"` یا `"finalized"`، [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) دیکھیں۔ + +```js +params: [ + "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", + "0x5daf3b", // 6139707 +] +``` + +**واپسی** + +`DATA` - دیئے گئے پتے سے کوڈ۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029" +} +``` + +### eth_sign {#eth_sign} + +سائن کا طریقہ ایک ایتھیریم مخصوص دستخط کا حساب لگاتا ہے: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`۔ + +پیغام میں ایک پریفکس شامل کرنے سے حساب کردہ دستخط کو ایک ایتھیریم مخصوص دستخط کے طور پر پہچانا جا سکتا ہے۔ یہ غلط استعمال کو روکتا ہے جہاں ایک نقصان دہ dapp صوابدیدی ڈیٹا (مثلاً، ٹرانزیکشن) پر دستخط کر سکتا ہے اور دستخط کا استعمال شکار کی نقالی کرنے کے لیے کر سکتا ہے۔ + +نوٹ: دستخط کرنے کے لیے پتہ غیر مقفل ہونا چاہیے۔ + +**پیرامیٹرز** + +1. `DATA`، 20 بائٹس - پتہ +2. `DATA`، N بائٹس - دستخط کرنے کے لیے پیغام + +**واپسی** + +`DATA`: دستخط + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" +} +``` + +### eth_signTransaction {#eth_signtransaction} + +ایک ٹرانزیکشن پر دستخط کرتا ہے جسے بعد میں [eth_sendRawTransaction](#eth_sendrawtransaction) کے ساتھ نیٹ ورک پر جمع کیا جا سکتا ہے۔ + +**پیرامیٹرز** + +1. `Object` - ٹرانزیکشن آبجیکٹ + +- `type`: +- `from`: `DATA`، 20 بائٹس - وہ پتہ جہاں سے ٹرانزیکشن بھیجی جاتی ہے۔ +- `to`: `DATA`، 20 بائٹس - (اختیاری جب نیا کنٹریکٹ بنایا جائے) وہ پتہ جہاں ٹرانزیکشن بھیجی جاتی ہے۔ +- `gas`: `QUANTITY` - (اختیاری، ڈیفالٹ: 90000) ٹرانزیکشن کے نفاذ کے لیے فراہم کردہ گیس کا انٹیجر۔ یہ غیر استعمال شدہ گیس واپس کرے گا۔ +- `gasPrice`: `QUANTITY` - (اختیاری، ڈیفالٹ: طے کیا جائے گا) ہر ادا شدہ گیس کے لیے استعمال ہونے والی گیس کی قیمت کا انٹیجر، Wei میں۔ +- `value`: `QUANTITY` - (اختیاری) اس ٹرانزیکشن کے ساتھ بھیجی گئی قیمت کا انٹیجر، Wei میں۔ +- `data`: `DATA` - ایک کنٹریکٹ کا مرتب کردہ کوڈ یا طلب کردہ طریقہ دستخط کا ہیش اور انکوڈڈ پیرامیٹرز۔ +- `nonce`: `QUANTITY` - (اختیاری) نونس کا انٹیجر۔ یہ آپ کو اپنی زیر التواء ٹرانزیکشنز کو اوور رائٹ کرنے کی اجازت دیتا ہے جو اسی نونس کا استعمال کرتی ہیں۔ + +**واپسی** + +`DATA`، مخصوص اکاؤنٹ کے ذریعے دستخط شدہ RLP-انکوڈڈ ٹرانزیکشن آبجیکٹ۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}' +// نتیجہ +{ + "id": 1, + "jsonrpc": "2.0", + "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" +} +``` + +### eth_sendTransaction {#eth_sendtransaction} + +نیا پیغام کال ٹرانزیکشن یا کنٹریکٹ تخلیق کرتا ہے، اگر ڈیٹا فیلڈ میں کوڈ ہو، اور اسے `from` میں مخصوص اکاؤنٹ کا استعمال کرتے ہوئے دستخط کرتا ہے۔ + +**پیرامیٹرز** + +1. `Object` - ٹرانزیکشن آبجیکٹ + +- `from`: `DATA`، 20 بائٹس - وہ پتہ جہاں سے ٹرانزیکشن بھیجی جاتی ہے۔ +- `to`: `DATA`، 20 بائٹس - (اختیاری جب نیا کنٹریکٹ بنایا جائے) وہ پتہ جہاں ٹرانزیکشن بھیجی جاتی ہے۔ +- `gas`: `QUANTITY` - (اختیاری، ڈیفالٹ: 90000) ٹرانزیکشن کے نفاذ کے لیے فراہم کردہ گیس کا انٹیجر۔ یہ غیر استعمال شدہ گیس واپس کرے گا۔ +- `gasPrice`: `QUANTITY` - (اختیاری، ڈیفالٹ: طے کیا جائے گا) ہر ادا شدہ گیس کے لیے استعمال ہونے والی گیس کی قیمت کا انٹیجر۔ +- `value`: `QUANTITY` - (اختیاری) اس ٹرانزیکشن کے ساتھ بھیجی گئی قیمت کا انٹیجر۔ +- `input`: `DATA` - ایک کنٹریکٹ کا مرتب کردہ کوڈ یا طلب کردہ طریقہ دستخط کا ہیش اور انکوڈڈ پیرامیٹرز۔ +- `nonce`: `QUANTITY` - (اختیاری) نونس کا انٹیجر۔ یہ آپ کو اپنی زیر التواء ٹرانزیکشنز کو اوور رائٹ کرنے کی اجازت دیتا ہے جو اسی نونس کا استعمال کرتی ہیں۔ + +```js +params: [ + { + from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155", + to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567", + gas: "0x76c0", // 30400 + gasPrice: "0x9184e72a000", // 10000000000000 + value: "0x9184e72a", // 2441406250 + input: + "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", + }, +] +``` + +**واپسی** + +`DATA`، 32 بائٹس - ٹرانزیکشن ہیش، یا صفر ہیش اگر ٹرانزیکشن ابھی تک دستیاب نہیں ہے۔ + +[eth_getTransactionReceipt](#eth_gettransactionreceipt) کا استعمال کریں تاکہ کنٹریکٹ کا پتہ حاصل کیا جا سکے، جب ٹرانزیکشن ایک بلاک میں تجویز کی گئی ہو، جب آپ نے ایک کنٹریکٹ بنایا ہو۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" +} +``` + +### eth_sendRawTransaction {#eth_sendrawtransaction} + +دستخط شدہ ٹرانزیکشنز کے لیے نیا پیغام کال ٹرانزیکشن یا کنٹریکٹ تخلیق کرتا ہے۔ + +**پیرامیٹرز** + +1. `DATA`، دستخط شدہ ٹرانزیکشن ڈیٹا۔ + +```js +params: [ + "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", +] +``` + +**واپسی** + +`DATA`، 32 بائٹس - ٹرانزیکشن ہیش، یا صفر ہیش اگر ٹرانزیکشن ابھی تک دستیاب نہیں ہے۔ + +[eth_getTransactionReceipt](#eth_gettransactionreceipt) کا استعمال کریں تاکہ کنٹریکٹ کا پتہ حاصل کیا جا سکے، جب ٹرانزیکشن ایک بلاک میں تجویز کی گئی ہو، جب آپ نے ایک کنٹریکٹ بنایا ہو۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" +} +``` + +### eth_call {#eth_call} + +بلاک چین پر ٹرانزیکشن بنائے بغیر فوری طور پر ایک نیا پیغام کال نافذ کرتا ہے۔ اکثر صرف پڑھنے کے قابل سمارٹ کنٹریکٹ فنکشنز کو نافذ کرنے کے لیے استعمال کیا جاتا ہے، مثال کے طور پر ERC-20 کنٹریکٹ کے لیے `balanceOf`۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `Object` - ٹرانزیکشن کال آبجیکٹ + +- `from`: `DATA`، 20 بائٹس - (اختیاری) وہ پتہ جہاں سے ٹرانزیکشن بھیجی جاتی ہے۔ +- `to`: `DATA`، 20 بائٹس - وہ پتہ جہاں ٹرانزیکشن بھیجی جاتی ہے۔ +- `gas`: `QUANTITY` - (اختیاری) ٹرانزیکشن کے نفاذ کے لیے فراہم کردہ گیس کا انٹیجر۔ eth_call صفر گیس استعمال کرتا ہے، لیکن کچھ نفاذ کے لیے اس پیرامیٹر کی ضرورت ہو سکتی ہے۔ +- `gasPrice`: `QUANTITY` - (اختیاری) ہر ادا شدہ گیس کے لیے استعمال ہونے والی گیس کی قیمت کا انٹیجر +- `value`: `QUANTITY` - (اختیاری) اس ٹرانزیکشن کے ساتھ بھیجی گئی قیمت کا انٹیجر +- `input`: `DATA` - (اختیاری) طریقہ دستخط کا ہیش اور انکوڈڈ پیرامیٹرز۔ تفصیلات کے لیے [سولیڈیٹی دستاویزات میں ایتھیریم کنٹریکٹ ABI](https://docs.soliditylang.org/en/latest/abi-spec.html) دیکھیں۔ + +2. `QUANTITY|TAG` - انٹیجر بلاک نمبر، یا سٹرنگ `"latest"`، `"earliest"`، `"pending"`، `"safe"` یا `"finalized"`، [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) دیکھیں۔ + +**واپسی** + +`DATA` - نافذ کردہ کنٹریکٹ کی واپسی کی قیمت۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x" +} +``` + +### eth_estimateGas {#eth_estimategas} + +ٹرانزیکشن کو مکمل کرنے کی اجازت دینے کے لیے کتنی گیس ضروری ہے اس کا تخمینہ تیار کرتا ہے اور واپس کرتا ہے۔ ٹرانزیکشن بلاک چین میں شامل نہیں کی جائے گی۔ نوٹ کریں کہ تخمینہ ٹرانزیکشن کے ذریعہ اصل میں استعمال ہونے والی گیس کی مقدار سے نمایاں طور پر زیادہ ہو سکتا ہے، جس کی مختلف وجوہات ہیں جن میں EVM میکانکس اور نوڈ کی کارکردگی شامل ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +[eth_call](#eth_call) پیرامیٹرز دیکھیں، سوائے اس کے کہ تمام خصوصیات اختیاری ہیں۔ اگر کوئی گیس کی حد متعین نہیں ہے تو geth زیر التواء بلاک سے بلاک گیس کی حد کو اوپری حد کے طور پر استعمال کرتا ہے۔ نتیجے کے طور پر، واپس کیا گیا تخمینہ کال/ٹرانزیکشن کو ایگزیکیوٹ کرنے کے لیے کافی نہیں ہو سکتا جب گیس کی مقدار پینڈنگ بلاک گیس کی حد سے زیادہ ہو۔ + +**واپسی** + +`QUANTITY` - استعمال شدہ گیس کی مقدار۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x5208" // 21000 +} +``` + +### eth_getBlockByHash {#eth_getblockbyhash} + +ہیش کے ذریعے ایک بلاک کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک بلاک کا ہیش۔ +2. `Boolean` - اگر `true` ہے تو یہ مکمل ٹرانزیکشن آبجیکٹ واپس کرتا ہے، اگر `false` ہے تو صرف ٹرانزیکشنز کے ہیش۔ + +```js +params: [ + "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", + false, +] +``` + +**واپسی** + +`Object` - ایک بلاک آبجیکٹ، یا `null` جب کوئی بلاک نہیں ملا: + +- `number`: `QUANTITY` - بلاک نمبر۔ جب یہ زیر التواء بلاک ہو تو `null`۔ +- `hash`: `DATA`، 32 بائٹس - بلاک کا ہیش۔ جب یہ زیر التواء بلاک ہو تو `null`۔ +- `parentHash`: `DATA`، 32 بائٹس - پیرنٹ بلاک کا ہیش۔ +- `nonce`: `DATA`، 8 بائٹس - پیدا کردہ پروف-آف-ورک کا ہیش۔ جب یہ زیر التواء بلاک ہو تو `null`، پروف-آف-اسٹیک بلاکس کے لیے `0x0` (The Merge کے بعد سے) +- `sha3Uncles`: `DATA`، 32 بائٹس - بلاک میں انکل ڈیٹا کا SHA3۔ +- `logsBloom`: `DATA`، 256 بائٹس - بلاک کے لاگز کے لیے بلوم فلٹر۔ جب یہ زیر التواء بلاک ہو تو `null`۔ +- `transactionsRoot`: `DATA`، 32 بائٹس - بلاک کے ٹرانزیکشن ٹرائی کی جڑ۔ +- `stateRoot`: `DATA`، 32 بائٹس - بلاک کے حتمی اسٹیٹ ٹرائی کی جڑ۔ +- `receiptsRoot`: `DATA`، 32 بائٹس - بلاک کے رسید ٹرائی کی جڑ۔ +- `miner`: `DATA`، 20 بائٹس - مستفید ہونے والے کا پتہ جسے بلاک کے انعامات دیئے گئے تھے۔ +- `difficulty`: `QUANTITY` - اس بلاک کے لیے مشکل کا انٹیجر۔ +- `totalDifficulty`: `QUANTITY` - اس بلاک تک زنجیر کی کل مشکل کا انٹیجر۔ +- `extraData`: `DATA` - اس بلاک کا "اضافی ڈیٹا" فیلڈ۔ +- `size`: `QUANTITY` - اس بلاک کا سائز بائٹس میں انٹیجر۔ +- `gasLimit`: `QUANTITY` - اس بلاک میں اجازت دی گئی زیادہ سے زیادہ گیس۔ +- `gasUsed`: `QUANTITY` - اس بلاک میں تمام ٹرانزیکشنز کے ذریعہ استعمال ہونے والی کل گیس۔ +- `timestamp`: `QUANTITY` - جب بلاک کو جمع کیا گیا تھا اس کا یونکس ٹائم اسٹیمپ۔ +- `transactions`: `Array` - ٹرانزیکشن آبجیکٹ کا ارے، یا 32 بائٹس ٹرانزیکشن ہیش جو آخری دیئے گئے پیرامیٹر پر منحصر ہے۔ +- `uncles`: `Array` - انکل ہیشز کا ارے۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' +// نتیجہ +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "difficulty": "0x4ea3f27bc", + "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", + "gasLimit": "0x1388", + "gasUsed": "0x0", + "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171", + "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843", + "nonce": "0x689056015818adbe", + "number": "0x1b4", + "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54", + "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", + "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", + "size": "0x220", + "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d", + "timestamp": "0x55ba467c", + "totalDifficulty": "0x78ed983323d", + "transactions": [ + ], + "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", + "uncles": [ + ] + } +} +``` + +### eth_getBlockByNumber {#eth_getblockbynumber} + +بلاک نمبر کے ذریعے ایک بلاک کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `QUANTITY|TAG` - ایک بلاک نمبر کا انٹیجر، یا سٹرنگ `"earliest"`، `"latest"`، `"pending"`، `"safe"` یا `"finalized"`، جیسا کہ [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) میں ہے۔ +2. `Boolean` - اگر `true` ہے تو یہ مکمل ٹرانزیکشن آبجیکٹ واپس کرتا ہے، اگر `false` ہے تو صرف ٹرانزیکشنز کے ہیش۔ + +```js +params: [ + "0x1b4", // 436 + true, +] +``` + +**واپسی** +[eth_getBlockByHash](#eth_getblockbyhash) دیکھیں + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' +``` + +نتیجہ [eth_getBlockByHash](#eth_getblockbyhash) دیکھیں + +### eth_getTransactionByHash {#eth_gettransactionbyhash} + +ٹرانزیکشن ہیش کے ذریعے درخواست کردہ ٹرانزیکشن کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک ٹرانزیکشن کا ہیش + +```js +params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] +``` + +**واپسی** + +`Object` - ایک ٹرانزیکشن آبجیکٹ، یا `null` جب کوئی ٹرانزیکشن نہیں ملا: + +- `blockHash`: `DATA`، 32 بائٹس - اس بلاک کا ہیش جہاں یہ ٹرانزیکشن تھی۔ جب یہ زیر التواء ہو تو `null`۔ +- `blockNumber`: `QUANTITY` - بلاک نمبر جہاں یہ ٹرانزیکشن تھی۔ جب یہ زیر التواء ہو تو `null`۔ +- `from`: `DATA`، 20 بائٹس - بھیجنے والے کا پتہ۔ +- `gas`: `QUANTITY` - بھیجنے والے کے ذریعہ فراہم کردہ گیس۔ +- `gasPrice`: `QUANTITY` - بھیجنے والے کے ذریعہ فراہم کردہ گیس کی قیمت Wei میں۔ +- `hash`: `DATA`، 32 بائٹس - ٹرانزیکشن کا ہیش۔ +- `input`: `DATA` - ٹرانزیکشن کے ساتھ بھیجا گیا ڈیٹا۔ +- `nonce`: `QUANTITY` - بھیجنے والے کے ذریعہ اس سے پہلے کی گئی ٹرانزیکشنز کی تعداد۔ +- `to`: `DATA`، 20 بائٹس - وصول کنندہ کا پتہ۔ جب یہ ایک کنٹریکٹ تخلیق ٹرانزیکشن ہو تو `null`۔ +- `transactionIndex`: `QUANTITY` - بلاک میں ٹرانزیکشنز انڈیکس پوزیشن کا انٹیجر۔ جب یہ زیر التواء ہو تو `null`۔ +- `value`: `QUANTITY` - Wei میں منتقل کی گئی قیمت۔ +- `v`: `QUANTITY` - ECDSA ریکوری آئی ڈی +- `r`: `QUANTITY` - ECDSA دستخط r +- `s`: `QUANTITY` - ECDSA دستخط s + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}' +// نتیجہ +{ + "jsonrpc":"2.0", + "id":1, + "result":{ + "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", + "blockNumber":"0x5daf3b", // 6139707 + "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", + "gas":"0xc350", // 50000 + "gasPrice":"0x4a817c800", // 20000000000 + "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", + "input":"0x68656c6c6f21", + "nonce":"0x15", // 21 + "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", + "transactionIndex":"0x41", // 65 + "value":"0xf3dbb76162000", // 4290000000000000 + "v":"0x25", // 37 + "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", + "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c" + } +} +``` + +### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex} + +بلاک ہیش اور ٹرانزیکشن انڈیکس پوزیشن کے ذریعے ایک ٹرانزیکشن کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک بلاک کا ہیش۔ +2. `QUANTITY` - ٹرانزیکشن انڈیکس پوزیشن کا انٹیجر۔ + +```js +params: [ + "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", + "0x0", // 0 +] +``` + +**واپسی** +[eth_getTransactionByHash](#eth_gettransactionbyhash) دیکھیں + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' +``` + +نتیجہ [eth_getTransactionByHash](#eth_gettransactionbyhash) دیکھیں + +### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex} + +بلاک نمبر اور ٹرانزیکشن انڈیکس پوزیشن کے ذریعے ایک ٹرانزیکشن کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `QUANTITY|TAG` - ایک بلاک نمبر، یا سٹرنگ `"earliest"`، `"latest"`، `"pending"`، `"safe"` یا `"finalized"`، جیسا کہ [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) میں ہے۔ +2. `QUANTITY` - ٹرانزیکشن انڈیکس پوزیشن۔ + +```js +params: [ + "0x9c47cf", // 10241999 + "0x24", // 36 +] +``` + +**واپسی** +[eth_getTransactionByHash](#eth_gettransactionbyhash) دیکھیں + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' +``` + +نتیجہ [eth_getTransactionByHash](#eth_gettransactionbyhash) دیکھیں + +### eth_getTransactionReceipt {#eth_gettransactionreceipt} + +ٹرانزیکشن ہیش کے ذریعے ٹرانزیکشن کی رسید واپس کرتا ہے۔ + +**نوٹ** یہ کہ رسید زیر التواء ٹرانزیکشنز کے لیے دستیاب نہیں ہے۔ + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک ٹرانزیکشن کا ہیش + +```js +params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] +``` + +**واپسی** +`Object` - ایک ٹرانزیکشن رسید آبجیکٹ، یا `null` جب کوئی رسید نہیں ملی: + +- `transactionHash `: `DATA`، 32 بائٹس - ٹرانزیکشن کا ہیش۔ +- `transactionIndex`: `QUANTITY` - بلاک میں ٹرانزیکشنز انڈیکس پوزیشن کا انٹیجر۔ +- `blockHash`: `DATA`، 32 بائٹس - اس بلاک کا ہیش جہاں یہ ٹرانزیکشن تھی۔ +- `blockNumber`: `QUANTITY` - بلاک نمبر جہاں یہ ٹرانزیکشن تھی۔ +- `from`: `DATA`، 20 بائٹس - بھیجنے والے کا پتہ۔ +- `to`: `DATA`، 20 بائٹس - وصول کنندہ کا پتہ۔ جب یہ ایک کنٹریکٹ تخلیق ٹرانزیکشن ہو تو null۔ +- `cumulativeGasUsed` : `QUANTITY ` - جب یہ ٹرانزیکشن بلاک میں نافذ کی گئی تھی تو استعمال ہونے والی گیس کی کل مقدار۔ +- `effectiveGasPrice` : `QUANTITY` - بنیادی فیس اور فی یونٹ گیس ادا کی گئی ٹپ کا مجموعہ۔ +- `gasUsed `: `QUANTITY ` - صرف اس مخصوص ٹرانزیکشن کے ذریعہ استعمال ہونے والی گیس کی مقدار۔ +- `contractAddress `: `DATA`، 20 بائٹس - تخلیق کردہ کنٹریکٹ کا پتہ، اگر ٹرانزیکشن کنٹریکٹ تخلیق تھی، ورنہ `null`۔ +- `logs`: `Array` - لاگ آبجیکٹ کا ارے، جو اس ٹرانزیکشن نے پیدا کیا۔ +- `logsBloom`: `DATA`، 256 بائٹس - ہلکے کلائنٹس کے لیے متعلقہ لاگز کو تیزی سے بازیافت کرنے کے لیے بلوم فلٹر۔ +- `type`: `QUANTITY` - ٹرانزیکشن کی قسم کا انٹیجر، میراثی ٹرانزیکشنز کے لیے `0x0`، رسائی فہرست کی اقسام کے لیے `0x1`، متحرک فیس کے لیے `0x2`۔ + +یہ _یا تو_ بھی واپس کرتا ہے: + +- `root` : `DATA` پوسٹ ٹرانزیکشن اسٹیٹ روٹ کے 32 بائٹس (pre Byzantium) +- `status`: `QUANTITY` یا تو `1` (کامیابی) یا `0` (ناکامی) + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}' +// نتیجہ +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "blockHash": + "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3", + "blockNumber": "0xeff35f", + "contractAddress": null, // اگر اسے بنایا گیا تھا تو پتے کا سٹرنگ + "cumulativeGasUsed": "0xa12515", + "effectiveGasPrice": "0x5a9c688d4", + "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7", + "gasUsed": "0xb4c8", + "logs": [{ + // getFilterLogs، وغیرہ کے ذریعہ واپس کیے گئے لاگز۔ + }], + "logsBloom": "0x00...0", // 256 بائٹ بلوم فلٹر + "status": "0x1", + "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", + "transactionHash": + "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5", + "transactionIndex": "0x66", + "type": "0x2" + } +} +``` + +### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex} + +ہیش اور انکل انڈیکس پوزیشن کے ذریعے بلاک کے انکل کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `DATA`، 32 بائٹس - ایک بلاک کا ہیش۔ +2. `QUANTITY` - انکل کی انڈیکس پوزیشن۔ + +```js +params: [ + "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", + "0x0", // 0 +] +``` + +**واپسی** +[eth_getBlockByHash](#eth_getblockbyhash) دیکھیں + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' +``` + +نتیجہ [eth_getBlockByHash](#eth_getblockbyhash) دیکھیں + +**نوٹ**: ایک انکل میں انفرادی ٹرانزیکشنز نہیں ہوتیں۔ + +### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex} + +نمبر اور انکل انڈیکس پوزیشن کے ذریعے بلاک کے انکل کے بارے میں معلومات واپس کرتا ہے۔ + + + پلے گراؤنڈ میں اینڈ پوائنٹ آزمائیں + + +**پیرامیٹرز** + +1. `QUANTITY|TAG` - ایک بلاک نمبر، یا سٹرنگ `"earliest"`، `"latest"`، `"pending"`، `"safe"`، `"finalized"`، جیسا کہ [بلاک پیرامیٹر](/developers/docs/apis/json-rpc/#block-parameter) میں ہے۔ +2. `QUANTITY` - انکل کی انڈیکس پوزیشن۔ + +```js +params: [ + "0x29c", // 668 + "0x0", // 0 +] +``` + +**واپسی** +[eth_getBlockByHash](#eth_getblockbyhash) دیکھیں + +**نوٹ**: ایک انکل میں انفرادی ٹرانزیکشنز نہیں ہوتیں۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' +``` + +نتیجہ [eth_getBlockByHash](#eth_getblockbyhash) دیکھیں + +### eth_newFilter {#eth_newfilter} + +فلٹر آپشنز کی بنیاد پر ایک فلٹر آبجیکٹ بناتا ہے، تاکہ حالت (لاگز) تبدیل ہونے پر مطلع کیا جا سکے۔ +یہ چیک کرنے کے لیے کہ آیا حالت تبدیل ہوئی ہے، [eth_getFilterChanges](#eth_getfilterchanges) کو کال کریں۔ + +**ٹاپک فلٹرز کی وضاحت پر ایک نوٹ:** +ٹاپکس آرڈر پر منحصر ہیں۔ ٹاپکس [A, B] کے ساتھ ایک لاگ کے ساتھ ایک ٹرانزیکشن مندرجہ ذیل ٹاپک فلٹرز سے مماثل ہوگی: + +- `[]` "کچھ بھی" +- `[A]` "پہلی پوزیشن میں A (اور اس کے بعد کچھ بھی)" +- `[null, B]` "پہلی پوزیشن میں کچھ بھی اور دوسری پوزیشن میں B (اور اس کے بعد کچھ بھی)" +- `[A, B]` "پہلی پوزیشن میں A اور دوسری پوزیشن میں B (اور اس کے بعد کچھ بھی)" +- `[[A, B], [A, B]]` "پہلی پوزیشن میں (A یا B) اور دوسری پوزیشن میں (A یا B) (اور اس کے بعد کچھ بھی)" +- **پیرامیٹرز** + +1. `Object` - فلٹر آپشنز: + +- `fromBlock`: `QUANTITY|TAG` - (اختیاری، ڈیفالٹ: `"latest"`) انٹیجر بلاک نمبر، یا آخری مجوزہ بلاک کے لیے `"latest"`، تازہ ترین محفوظ بلاک کے لیے `"safe"`، تازہ ترین حتمی بلاک کے لیے `"finalized"`، یا `"pending"`، ان ٹرانزیکشنز کے لیے `"earliest"` جو ابھی تک بلاک میں نہیں ہیں۔ +- `toBlock`: `QUANTITY|TAG` - (اختیاری، ڈیفالٹ: `"latest"`) انٹیجر بلاک نمبر، یا آخری مجوزہ بلاک کے لیے `"latest"`، تازہ ترین محفوظ بلاک کے لیے `"safe"`، تازہ ترین حتمی بلاک کے لیے `"finalized"`، یا `"pending"`، ان ٹرانزیکشنز کے لیے `"earliest"` جو ابھی تک بلاک میں نہیں ہیں۔ +- `address`: `DATA|Array`، 20 بائٹس - (اختیاری) کنٹریکٹ کا پتہ یا پتوں کی فہرست جہاں سے لاگز شروع ہونے چاہئیں۔ +- `topics`: `Array of DATA`، - (اختیاری) 32 بائٹس `DATA` ٹاپکس کا ارے۔ ٹاپکس آرڈر پر منحصر ہیں۔ ہر ٹاپک "یا" آپشنز کے ساتھ DATA کا ایک ارے بھی ہو سکتا ہے۔ + +```js +params: [ + { + fromBlock: "0x1", + toBlock: "0x2", + address: "0x8888f1f195afa192cfee860698584c030f4c9db1", + topics: [ + "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", + null, + [ + "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", + "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc", + ], + ], + }, +] +``` + +**واپسی** +`QUANTITY` - ایک فلٹر آئی ڈی۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_newBlockFilter {#eth_newblockfilter} + +نوڈ میں ایک فلٹر بناتا ہے، تاکہ نیا بلاک آنے پر مطلع کیا جا سکے۔ +یہ چیک کرنے کے لیے کہ آیا حالت تبدیل ہوئی ہے، [eth_getFilterChanges](#eth_getfilterchanges) کو کال کریں۔ + +**پیرامیٹرز** +کوئی نہیں + +**واپسی** +`QUANTITY` - ایک فلٹر آئی ڈی۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter} + +نوڈ میں ایک فلٹر بناتا ہے، تاکہ نئی زیر التواء ٹرانزیکشنز آنے پر مطلع کیا جا سکے۔ +یہ چیک کرنے کے لیے کہ آیا حالت تبدیل ہوئی ہے، [eth_getFilterChanges](#eth_getfilterchanges) کو کال کریں۔ + +**پیرامیٹرز** +کوئی نہیں + +**واپسی** +`QUANTITY` - ایک فلٹر آئی ڈی۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_uninstallFilter {#eth_uninstallfilter} + +دی گئی آئی ڈی کے ساتھ ایک فلٹر کو ان انسٹال کرتا ہے۔ جب واچ کی مزید ضرورت نہ ہو تو ہمیشہ کال کرنا چاہیے۔ +اس کے علاوہ فلٹرز اس وقت ٹائم آؤٹ ہو جاتے ہیں جب انہیں کچھ وقت کے لیے [eth_getFilterChanges](#eth_getfilterchanges) کے ساتھ درخواست نہیں کی جاتی۔ + +**پیرامیٹرز** + +1. `QUANTITY` - فلٹر آئی ڈی۔ + +```js +params: [ + "0xb", // 11 +] +``` + +**واپسی** +`Boolean` - `true` اگر فلٹر کامیابی سے ان انسٹال ہو گیا، ورنہ `false`۔ + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}' +// نتیجہ +{ + "id":1, + "jsonrpc": "2.0", + "result": true +} +``` + +### eth_getFilterChanges {#eth_getfilterchanges} + +ایک فلٹر کے لیے پولنگ کا طریقہ، جو آخری پول کے بعد سے ہونے والے لاگز کا ایک ارے واپس کرتا ہے۔ + +**پیرامیٹرز** + +1. `QUANTITY` - فلٹر آئی ڈی۔ + +```js +params: [ + "0x16", // 22 +] +``` + +**واپسی** +`Array` - لاگ آبجیکٹ کا ارے، یا ایک خالی ارے اگر آخری پول کے بعد سے کچھ بھی تبدیل نہیں ہوا ہے۔ + +- `eth_newBlockFilter` کے ساتھ بنائے گئے فلٹرز کے لیے، واپسی بلاک ہیشز (`DATA`، 32 بائٹس) ہیں، مثلاً، `["0x3454645634534..."]`۔ + +- `eth_newPendingTransactionFilter` کے ساتھ بنائے گئے فلٹرز کے لیے، واپسی ٹرانزیکشن ہیشز (`DATA`، 32 بائٹس) ہیں، مثلاً، `["0x6345343454645..."]`۔ + +- `eth_newFilter` کے ساتھ بنائے گئے فلٹرز کے لیے لاگز مندرجہ ذیل پیرامیٹرز کے ساتھ آبجیکٹ ہیں: + - `removed`: `TAG` - `true` جب لاگ ہٹا دیا گیا تھا، ایک زنجیر کی تنظیم نو کی وجہ سے۔ `false` اگر یہ ایک درست لاگ ہے۔ + - `logIndex`: `QUANTITY` - بلاک میں لاگ انڈیکس پوزیشن کا انٹیجر۔ جب یہ زیر التواء لاگ ہو تو `null`۔ + - `transactionIndex`: `QUANTITY` - ٹرانزیکشنز انڈیکس پوزیشن کا انٹیجر جس سے لاگ بنایا گیا تھا۔ جب یہ زیر التواء لاگ ہو تو `null`۔ + - `transactionHash`: `DATA`، 32 بائٹس - ان ٹرانزیکشنز کا ہیش جن سے یہ لاگ بنایا گیا تھا۔ جب یہ زیر التواء لاگ ہو تو `null`۔ + - `blockHash`: `DATA`، 32 بائٹس - اس بلاک کا ہیش جہاں یہ لاگ تھا۔ جب یہ زیر التواء ہو تو `null`۔ جب یہ زیر التواء لاگ ہو تو `null`۔ + - `blockNumber`: `QUANTITY` - وہ بلاک نمبر جہاں یہ لاگ تھا۔ جب یہ زیر التواء ہو تو `null`۔ جب یہ زیر التواء لاگ ہو تو `null`۔ + - `address`: `DATA`، 20 بائٹس - وہ پتہ جہاں سے یہ لاگ شروع ہوا۔ + - `data`: `DATA` - متغیر لمبائی والا غیر انڈیکس شدہ لاگ ڈیٹا۔ (_solidity_ میں: صفر یا زیادہ 32 بائٹس کے غیر انڈیکس شدہ لاگ آرگیومنٹس۔) + - `topics`: `Array of DATA` - 0 سے 4 32 بائٹس `DATA` کے انڈیکس شدہ لاگ آرگیومنٹس کا ارے۔ (_solidity_ میں: پہلا ٹاپک ایونٹ کے دستخط کا _hash_ ہے (مثلاً، `Deposit(address,bytes32,uint256)`), سوائے اس کے کہ آپ نے `anonymous` اسپیسیفائر کے ساتھ ایونٹ کا اعلان کیا ہو۔) + +- **مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}' +// نتیجہ +{ + "id":1, + "jsonrpc":"2.0", + "result": [{ + "logIndex": "0x1", // 1 + "blockNumber":"0x1b4", // 436 + "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", + "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", + "transactionIndex": "0x0", // 0 + "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", + "data":"0x0000000000000000000000000000000000000000000000000000000000000000", + "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"] + },{ + ... + }] +} +``` + +### eth_getFilterLogs {#eth_getfilterlogs} + +دی گئی آئی ڈی کے ساتھ فلٹر سے مماثل تمام لاگز کا ایک ارے واپس کرتا ہے۔ + +**پیرامیٹرز** + +1. `QUANTITY` - فلٹر آئی ڈی۔ + +```js +params: [ + "0x16", // 22 +] +``` + +**واپسی** +[eth_getFilterChanges](#eth_getfilterchanges) دیکھیں + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}' +``` + +نتیجہ [eth_getFilterChanges](#eth_getfilterchanges) دیکھیں + +### eth_getLogs {#eth_getlogs} + +ایک دیئے گئے فلٹر آبجیکٹ سے مماثل تمام لاگز کا ایک ارے واپس کرتا ہے۔ + +**پیرامیٹرز** + +1. `Object` - فلٹر آپشنز: + +- `fromBlock`: `QUANTITY|TAG` - (اختیاری، ڈیفالٹ: `"latest"`) انٹیجر بلاک نمبر، یا آخری مجوزہ بلاک کے لیے `"latest"`، تازہ ترین محفوظ بلاک کے لیے `"safe"`، تازہ ترین حتمی بلاک کے لیے `"finalized"`، یا `"pending"`، ان ٹرانزیکشنز کے لیے `"earliest"` جو ابھی تک بلاک میں نہیں ہیں۔ +- `toBlock`: `QUANTITY|TAG` - (اختیاری، ڈیفالٹ: `"latest"`) انٹیجر بلاک نمبر، یا آخری مجوزہ بلاک کے لیے `"latest"`، تازہ ترین محفوظ بلاک کے لیے `"safe"`، تازہ ترین حتمی بلاک کے لیے `"finalized"`، یا `"pending"`، ان ٹرانزیکشنز کے لیے `"earliest"` جو ابھی تک بلاک میں نہیں ہیں۔ +- `address`: `DATA|Array`، 20 بائٹس - (اختیاری) کنٹریکٹ کا پتہ یا پتوں کی فہرست جہاں سے لاگز شروع ہونے چاہئیں۔ +- `topics`: `Array of DATA`، - (اختیاری) 32 بائٹس `DATA` ٹاپکس کا ارے۔ ٹاپکس آرڈر پر منحصر ہیں۔ ہر ٹاپک "یا" آپشنز کے ساتھ DATA کا ایک ارے بھی ہو سکتا ہے۔ +- `blockHash`: `DATA`, 32 Bytes - (اختیاری، **مستقبل میں**) EIP-234 کے اضافے کے ساتھ، `blockHash` ایک نیا فلٹر آپشن ہوگا جو واپس کیے گئے لاگز کو 32-بائٹ ہیش `blockHash` کے ساتھ واحد بلاک تک محدود کر دے گا۔ `blockHash` کا استعمال `fromBlock` = `toBlock` = `blockHash` ہیش والے بلاک نمبر کے برابر ہے۔ اگر فلٹر کے معیار میں `blockHash` موجود ہے، تو نہ `fromBlock` اور نہ ہی `toBlock` کی اجازت ہے۔ + +```js +params: [ + { + topics: [ + "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", + ], + }, +] +``` + +**واپسی** +[eth_getFilterChanges](#eth_getfilterchanges) دیکھیں + +**مثال** + +```js +// درخواست +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}' +``` + +نتیجہ [eth_getFilterChanges](#eth_getfilterchanges) دیکھیں + +## استعمال کی مثال {#usage-example} + +### JSON_RPC کا استعمال کرتے ہوئے کانٹریکٹ کو ڈیپلائے کرنا {#deploying-contract} + +اس سیکشن میں یہ دکھایا گیا ہے کہ صرف RPC انٹرفیس کا استعمال کرتے ہوئے کانٹریکٹ کو کیسے ڈیپلائے کیا جائے۔ کانٹریکٹس کو ڈیپلائے کرنے کے متبادل راستے بھی ہیں جہاں اس پیچیدگی کو دور کر دیا جاتا ہے—مثال کے طور پر، RPC انٹرفیس کے اوپر بنی لائبریریوں کا استعمال کرتے ہوئے جیسے [web3.js](https://web3js.readthedocs.io/) اور [web3.py](https://github.com/ethereum/web3.py)۔ یہ ایبسٹریکشنز عام طور پر سمجھنے میں آسان اور کم غلطی کے امکان والی ہوتی ہیں، لیکن یہ سمجھنا اب بھی مددگار ہے کہ پس پردہ کیا ہو رہا ہے۔ + +درج ذیل ایک سیدھا سادا اسمارٹ کانٹریکٹ ہے جسے `Multiply7` کہا جاتا ہے جسے JSON-RPC انٹرفیس کا استعمال کرتے ہوئے ایک Ethereum نوڈ پر ڈیپلائے کیا جائے گا۔ یہ ٹیوٹوریل یہ فرض کرتا ہے کہ پڑھنے والا پہلے سے ہی Geth نوڈ چلا رہا ہے۔ نوڈز اور کلائنٹس کے بارے میں مزید معلومات [یہاں](/developers/docs/nodes-and-clients/run-a-node) دستیاب ہیں۔ براہ کرم غیر-Geth کلائنٹس کے لیے HTTP JSON-RPC شروع کرنے کا طریقہ دیکھنے کے لیے انفرادی [کلائنٹ](/developers/docs/nodes-and-clients/) کی دستاویزات دیکھیں۔ زیادہ تر کلائنٹس `localhost:8545` پر سروس فراہم کرنے کے لیے ڈیفالٹ ہوتے ہیں۔ + +```javascript +contract Multiply7 { + event Print(uint); + function multiply(uint input) returns (uint) { + Print(input * 7); + return input * 7; + } +} +``` + +سب سے پہلا کام یہ یقینی بنانا ہے کہ HTTP RPC انٹرفیس فعال ہے۔ اس کا مطلب ہے کہ ہم Geth کو اسٹارٹ اپ پر `--http` فلیگ فراہم کرتے ہیں۔ اس مثال میں ہم ایک پرائیویٹ ڈیولپمنٹ چین پر Geth نوڈ کا استعمال کرتے ہیں۔ اس طریقے کا استعمال کرتے ہوئے ہمیں حقیقی نیٹ ورک پر ایتھر کی ضرورت نہیں ہے۔ + +```bash +geth --http --dev console 2>>geth.log +``` + +یہ HTTP RPC انٹرفیس کو `http://localhost:8545` پر شروع کر دے گا۔ + +ہم اس بات کی تصدیق کر سکتے ہیں کہ انٹرفیس چل رہا ہے، اس کے لیے ہم کوئن بیس ایڈریس (اکاؤنٹس کی صف سے پہلا ایڈریس حاصل کر کے) اور [curl](https://curl.se) کا استعمال کرتے ہوئے بیلنس حاصل کریں گے۔ براہ کرم نوٹ کریں کہ ان مثالوں میں ڈیٹا آپ کے مقامی نوڈ پر مختلف ہوگا۔ اگر آپ ان کمانڈز کو آزمانا چاہتے ہیں، تو دوسری curl درخواست میں موجود درخواست کے پیرامیٹرز کو پہلی سے واپس آنے والے نتیجے سے بدل دیں۔ + +```bash +curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545 +{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]} + +curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545 +{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"} +``` + +چونکہ نمبرز ہیکس انکوڈڈ ہوتے ہیں، اس لیے بیلنس کو wei میں ہیکس اسٹرنگ کے طور پر واپس کیا جاتا ہے۔ اگر ہم بیلنس کو ایتھر میں ایک نمبر کے طور پر چاہتے ہیں تو ہم Geth کنسول سے web3 استعمال کر سکتے ہیں۔ + +```javascript +web3.fromWei("0x1639e49bba16280000", "ether") +// "410" +``` + +اب جب کہ ہماری پرائیویٹ ڈیولپمنٹ چین پر کچھ ایتھر موجود ہے، ہم کانٹریکٹ کو ڈیپلائے کر سکتے ہیں۔ پہلا قدم Multiply7 کانٹریکٹ کو بائٹ کوڈ میں کمپائل کرنا ہے جسے EVM کو بھیجا جا سکتا ہے۔ solc، Solidity کمپائلر کو انسٹال کرنے کے لیے، [Solidity کی دستاویزات](https://docs.soliditylang.org/en/latest/installing-solidity.html) پر عمل کریں۔ (ہو سکتا ہے آپ [ہماری مثال کے لیے استعمال ہونے والے کمپائلر کے ورژن](https://github.com/ethereum/solidity/releases/tag/v0.4.20) سے مطابقت کے لیے ایک پرانا `solc` ریلیز استعمال کرنا چاہیں۔) + +اگلا قدم Multiply7 کنٹریکٹ کو بائٹ کوڈ میں کمپائل کرنا ہے جسے EVM کو بھیجا جا سکتا ہے۔ + +```bash +echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin + +======= :Multiply7 ======= +Binary: +6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029 +``` + +اب جب کہ ہمارے پاس کمپائل شدہ کوڈ ہے، ہمیں یہ تعین کرنے کی ضرورت ہے کہ اسے ڈیپلائے کرنے میں کتنی گیس لگے گی۔ RPC انٹرفیس میں ایک `eth_estimateGas` طریقہ ہے جو ہمیں ایک تخمینہ دے گا۔ + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545 +{"jsonrpc":"2.0","id":5,"result":"0x1c31e"} +``` + +اور آخر میں کانٹریکٹ کو ڈیپلائے کریں۔ + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545 +{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"} +``` + +ٹرانزیکشن کو نوڈ کے ذریعے قبول کر لیا جاتا ہے اور ایک ٹرانزیکشن ہیش واپس کر دیا جاتا ہے۔ اس ہیش کا استعمال ٹرانزیکشن کو ٹریک کرنے کے لیے کیا جا سکتا ہے۔ اگلا قدم اس ایڈریس کا تعین کرنا ہے جہاں ہمارا کنٹریکٹ ڈیپلائے کیا گیا ہے۔ ہر ایگزیکیوٹڈ ٹرانزیکشن ایک رسید بنائے گا۔ اس رسید میں ٹرانزیکشن کے بارے میں مختلف معلومات ہوتی ہیں جیسے کہ ٹرانزیکشن کس بلاک میں شامل تھا اور EVM نے کتنی گیس استعمال کی۔ اگر کوئی ٹرانزیکشن +ایک کنٹریکٹ بناتا ہے تو اس میں کنٹریکٹ کا ایڈریس بھی شامل ہوگا۔ ہم `eth_getTransactionReceipt` RPC میتھڈ سے رسید بازیافت کر سکتے ہیں۔ + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 +{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}} +``` + +ہمارا کنٹریکٹ `0x4d03d617d700cf81935d7f797f4e2ae719648262` پر بنایا گیا تھا۔ رسید کے بجائے ایک null نتیجہ کا مطلب ہے کہ ٹرانزیکشن کو ابھی تک کسی بلاک میں شامل نہیں کیا گیا ہے۔ ایک لمحہ انتظار کریں اور چیک کریں کہ آیا آپ کا consensus client چل رہا ہے اور اسے دوبارہ آزمائیں۔ + +#### اسمارٹ کنٹریکٹس کے ساتھ انٹریکٹ کرنا {#interacting-with-smart-contract} + +اس مثال میں ہم کنٹریکٹ کے `multiply` میتھڈ کو `eth_sendTransaction` کا استعمال کرتے ہوئے ایک ٹرانزیکشن بھیجیں گے۔ + +`eth_sendTransaction` کو کئی آرگیومنٹس کی ضرورت ہوتی ہے، خاص طور پر `from`، `to` اور `data`۔ `From` ہمارے اکاؤنٹ کا پبلک ایڈریس ہے، اور `to` کنٹریکٹ کا ایڈریس ہے۔ `data` آرگیومنٹ میں ایک پے لوڈ ہوتا ہے جو یہ بتاتا ہے کہ کس میتھڈ کو کال کرنا ہے اور کن آرگیومنٹس کے ساتھ۔ یہ وہ جگہ ہے جہاں [ABI (ایپلی کیشن بائنری انٹرفیس)](https://docs.soliditylang.org/en/latest/abi-spec.html) کام میں آتا ہے۔ ABI ایک JSON فائل ہے جو EVM کے لیے ڈیٹا کی تعریف اور انکوڈ کرنے کا طریقہ بتاتی ہے۔ + +پے لوڈ کے بائٹس یہ بتاتے ہیں کہ کنٹریکٹ میں کس میتھڈ کو کال کیا گیا ہے۔ یہ فنکشن کے نام اور اس کے آرگیومنٹ کی اقسام پر Keccak ہیش سے پہلے 4 بائٹس ہیں، جو ہیکس انکوڈڈ ہیں۔ ملٹی پلائی فنکشن ایک uint کو قبول کرتا ہے جو uint256 کے لیے ایک الیاس ہے۔ اس سے ہمارے پاس بچتا ہے: + +```javascript +web3.sha3("multiply(uint256)").substring(0, 10) +// "0xc6888fa1" +``` + +اگلا قدم آرگیومنٹس کو انکوڈ کرنا ہے۔ صرف ایک uint256 ہے، مثال کے طور پر، قدر 6۔ ABI میں ایک سیکشن ہے جو یہ بتاتا ہے کہ uint256 کی اقسام کو کیسے انکوڈ کیا جائے۔ + +`int: enc(X)` X کی big-endian two’s complement انکوڈنگ ہے، جسے منفی X کے لیے ہائی آرڈر (بائیں) طرف 0xff کے ساتھ اور مثبت X کے لیے صفر > بائٹس کے ساتھ پیڈ کیا گیا ہے تاکہ لمبائی 32 بائٹس کا ضرب ہو۔ + +یہ `0000000000000000000000000000000000000000000000000000000000000006` میں انکوڈ ہوتا ہے۔ + +فنکشن سلیکٹر اور انکوڈڈ آرگیومنٹ کو ملا کر ہمارا ڈیٹا `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006` ہوگا۔ + +اسے اب نوڈ کو بھیجا جا سکتا ہے: + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545 +{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"} +``` + +چونکہ ایک ٹرانزیکشن بھیجا گیا تھا، ایک ٹرانزیکشن ہیش واپس کیا گیا تھا۔ رسید بازیافت کرنے پر ملتا ہے: + +```javascript +{ + blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", + blockNumber: 268, + contractAddress: null, + cumulativeGasUsed: 22631, + gasUsed: 22631, + logs: [{ + address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", + blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", + blockNumber: 268, + data: "0x000000000000000000000000000000000000000000000000000000000000002a", + logIndex: 0, + topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"], + transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", + transactionIndex: 0 + }], + transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", + transactionIndex: 0 +} +``` + +رسید میں ایک لاگ ہوتا ہے۔ یہ لاگ EVM کے ذریعے ٹرانزیکشن کے ایگزیکیوشن پر بنایا گیا تھا اور رسید میں شامل کیا گیا تھا۔ `multiply` فنکشن دکھاتا ہے کہ `Print` ایونٹ ان پٹ کے 7 گنا کے ساتھ ریز کیا گیا تھا۔ چونکہ `Print` ایونٹ کے لیے آرگیومنٹ ایک uint256 تھا، ہم اسے ABI کے اصولوں کے مطابق ڈی کوڈ کر سکتے ہیں جو ہمیں متوقع ڈیسیمل 42 کے ساتھ چھوڑ دے گا۔ ڈیٹا کے علاوہ یہ بات قابل غور ہے کہ ٹاپکس کا استعمال یہ تعین کرنے کے لیے کیا جا سکتا ہے کہ کس ایونٹ نے لاگ بنایا: + +```javascript +web3.sha3("Print(uint256)") +// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da" +``` + +یہ کچھ سب سے عام کاموں کا ایک مختصر تعارف تھا، جو JSON-RPC کے براہ راست استعمال کو ظاہر کرتا ہے۔ + +## متعلقہ موضوعات {#related-topics} + +- [JSON-RPC کی تفصیلات](http://www.jsonrpc.org/specification) +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) +- [JavaScript APIs](/developers/docs/apis/javascript/) +- [بیک اینڈ APIs](/developers/docs/apis/backend/) +- [ایگزیکیوشن کلائنٹس](/developers/docs/nodes-and-clients/#execution-clients) diff --git a/public/content/translations/ur/developers/docs/blocks/index.md b/public/content/translations/ur/developers/docs/blocks/index.md new file mode 100644 index 00000000000..531595a2e1f --- /dev/null +++ b/public/content/translations/ur/developers/docs/blocks/index.md @@ -0,0 +1,153 @@ +--- +title: "بلاک" +description: "ایتھیریم بلاک چین میں بلاکس کا ایک جائزہ - ان کا ڈیٹا ڈھانچہ، ان کی ضرورت کیوں ہے، اور وہ کیسے بنائے جاتے ہیں۔" +lang: ur-in +--- + +بلاک ٹرانزیکشنز کے بیچ ہوتے ہیں جن میں چین میں پچھلے بلاک کا ہیش ہوتا ہے۔ یہ بلاکس کو ایک ساتھ (ایک چین میں) جوڑتا ہے کیونکہ ہیشز کو بلاک ڈیٹا سے کرپٹوگرافک طور پر اخذ کیا جاتا ہے۔ یہ دھوکہ دہی کو روکتا ہے، کیونکہ تاریخ کے کسی بھی بلاک میں ایک تبدیلی تمام مندرجہ ذیل بلاکس کو باطل کر دے گی کیونکہ اس کے بعد کے تمام ہیشز بدل جائیں گے اور بلاک چین چلانے والے ہر شخص کو اس کا علم ہو جائے گا۔ + +## شرائط {#prerequisites} + +بلاک ایک بہت ہی ابتدائی-دوست موضوع ہے۔ لیکن اس صفحہ کو بہتر طور پر سمجھنے میں آپ کی مدد کرنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [اکاؤنٹس](/developers/docs/accounts/)، [ٹرانزیکشنز](/developers/docs/transactions/)، اور ہمارا [ایتھیریم کا تعارف](/developers/docs/intro-to-ethereum/) پڑھیں۔ + +## بلاک کیوں؟ {#why-blocks} + +اس بات کو یقینی بنانے کے لیے کہ ایتھیریم نیٹ ورک پر تمام شرکاء ایک مطابقت پذیر اسٹیٹ کو برقرار رکھیں اور ٹرانزیکشنز کی درست تاریخ پر متفق ہوں، ہم ٹرانزیکشنز کو بلاکس میں بیچ کرتے ہیں۔ اس کا مطلب ہے کہ درجنوں (یا سینکڑوں) ٹرانزیکشنز کو ایک ہی وقت میں کمٹ کیا جاتا ہے، ان پر اتفاق کیا جاتا ہے، اور مطابقت پذیر کیا جاتا ہے۔ + +![ایک خاکہ جو بلاک میں ٹرانزیکشن کو اسٹیٹ میں تبدیلیوں کا سبب بنتے ہوئے دکھا رہا ہے](./tx-block.png) +_خاکہ [ایتھیریم EVM کی تصویری وضاحت](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے اخذ کیا گیا ہے_ + +کمٹس کے درمیان وقفہ دے کر، ہم تمام نیٹ ورک شرکاء کو اتفاق رائے پر آنے کے لیے کافی وقت دیتے ہیں: اگرچہ ٹرانزیکشن کی درخواستیں فی سیکنڈ درجنوں بار ہوتی ہیں، لیکن ایتھیریم پر بلاکس ہر بارہ سیکنڈ میں صرف ایک بار بنائے اور کمٹ کیے جاتے ہیں۔ + +## بلاک کیسے کام کرتے ہیں {#how-blocks-work} + +ٹرانزیکشن کی تاریخ کو محفوظ رکھنے کے لیے، بلاکس کو سختی سے ترتیب دیا جاتا ہے (ہر نئے بنائے گئے بلاک میں اس کے پیرنٹ بلاک کا حوالہ ہوتا ہے)، اور بلاکس کے اندر ٹرانزیکشنز کو بھی سختی سے ترتیب دیا جاتا ہے۔ نایاب معاملات کو چھوڑ کر، کسی بھی وقت، نیٹ ورک پر تمام شرکاء بلاکس کی صحیح تعداد اور تاریخ پر متفق ہوتے ہیں، اور موجودہ لائیو ٹرانزیکشن کی درخواستوں کو اگلے بلاک میں بیچ کرنے کے لیے کام کر رہے ہیں۔ + +ایک بار جب نیٹ ورک پر تصادفی طور پر منتخب کردہ ویلیڈیٹر کے ذریعہ ایک بلاک کو اکٹھا کیا جاتا ہے، تو اسے باقی نیٹ ورک میں پھیلایا جاتا ہے؛ تمام نوڈز اس بلاک کو اپنے بلاک چین کے آخر میں شامل کرتے ہیں، اور اگلا بلاک بنانے کے لیے ایک نیا ویلیڈیٹر منتخب کیا جاتا ہے۔ بلاک اسمبلی کا عین عمل اور کمٹمنٹ/اتفاق رائے کا عمل فی الحال ایتھیریم کے "پروف-آف-اسٹیک" پروٹوکول کے ذریعہ مخصوص ہے۔ + +## پروف-آف-اسٹیک پروٹوکول {#proof-of-stake-protocol} + +پروف-آف-اسٹیک کا مطلب مندرجہ ذیل ہے: + +- ویلیڈیٹنگ نوڈز کو خراب رویے کے خلاف کولیٹرل کے طور پر ایک ڈپازٹ کنٹریکٹ میں 32 ETH اسٹیک کرنا پڑتا ہے۔ اس سے نیٹ ورک کی حفاظت میں مدد ملتی ہے کیونکہ قابل ثبوت بے ایمانی کی سرگرمی اس اسٹیک میں سے کچھ یا سبھی کو تباہ کرنے کا باعث بنتی ہے۔ +- ہر سلاٹ میں (بارہ سیکنڈ کے وقفے سے) ایک ویلیڈیٹر کو تصادفی طور پر بلاک پروپوزر کے طور پر منتخب کیا جاتا ہے۔ وہ ٹرانزیکشنز کو ایک ساتھ بنڈل کرتے ہیں، انہیں انجام دیتے ہیں اور ایک نیا 'اسٹیٹ' طے کرتے ہیں۔ وہ اس معلومات کو ایک بلاک میں لپیٹتے ہیں اور اسے دوسرے ویلیڈیٹرز کو دیتے ہیں۔ +- دوسرے ویلیڈیٹرز جو نئے بلاک کے بارے میں سنتے ہیں وہ ٹرانزیکشنز کو دوبارہ انجام دیتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ وہ عالمی اسٹیٹ میں مجوزہ تبدیلی سے متفق ہیں۔ یہ فرض کرتے ہوئے کہ بلاک درست ہے، وہ اسے اپنے ڈیٹا بیس میں شامل کرتے ہیں۔ +- اگر کوئی ویلیڈیٹر ایک ہی سلاٹ کے لیے دو متضاد بلاکس کے بارے میں سنتا ہے تو وہ اپنے فورک-چوائس الگورتھم کا استعمال کرکے اس کا انتخاب کرتا ہے جس کی حمایت سب سے زیادہ اسٹیک شدہ ETH نے کی ہو۔ + +[پروف-آف-اسٹیک پر مزید](/developers/docs/consensus-mechanisms/pos) + +## بلاک میں کیا ہوتا ہے؟ {#block-anatomy} + +ایک بلاک کے اندر بہت سی معلومات موجود ہوتی ہیں۔ اعلیٰ ترین سطح پر ایک بلاک میں مندرجہ ذیل فیلڈز ہوتے ہیں: + +| فیلڈ | تفصیل | +| :--------------- | :--------------------------------------------------------------- | +| `slot` | وہ سلاٹ جس سے بلاک تعلق رکھتا ہے | +| `proposer_index` | بلاک کی تجویز دینے والے ویلیڈیٹر کی ID | +| `parent_root` | پچھلے بلاک کا ہیش | +| `state_root` | اسٹیٹ آبجیکٹ کا روٹ ہیش | +| `body` | ایک آبجیکٹ جس میں کئی فیلڈز ہیں، جیسا کہ ذیل میں بیان کیا گیا ہے | + +بلاک `body` میں اپنے کئی فیلڈز ہوتے ہیں: + +| فیلڈ | تفصیل | +| :------------------- | :---------------------------------------------------------------------------- | +| `randao_reveal` | اگلے بلاک پروپوزر کو منتخب کرنے کے لیے استعمال ہونے والی ایک قدر | +| `eth1_data` | ڈپازٹ کنٹریکٹ کے بارے میں معلومات | +| `graffiti` | بلاکس کو ٹیگ کرنے کے لیے استعمال ہونے والا صوابدیدی ڈیٹا | +| `proposer_slashings` | سلیش کیے جانے والے ویلیڈیٹرز کی فہرست | +| `attester_slashings` | سلیش کیے جانے والے تصدیق کنندگان کی فہرست | +| `attestations` | پچھلے سلاٹس کے خلاف کی گئی تصدیقات کی فہرست | +| `deposits` | ڈپازٹ کنٹریکٹ میں نئے ڈپازٹس کی فہرست | +| `voluntary_exits` | نیٹ ورک سے باہر نکلنے والے ویلیڈیٹرز کی فہرست | +| `sync_aggregate` | لائٹ کلائنٹس کو خدمات فراہم کرنے کے لیے استعمال ہونے والے ویلیڈیٹرز کا سب سیٹ | +| `execution_payload` | ایگزیکیوشن کلائنٹ سے بھیجی گئی ٹرانزیکشنز | + +`attestations` فیلڈ میں بلاک میں موجود تمام تصدیقات کی فہرست ہوتی ہے۔ تصدیقات کا اپنا ڈیٹا ٹائپ ہوتا ہے جس میں ڈیٹا کے کئی حصے ہوتے ہیں۔ ہر تصدیق میں شامل ہیں: + +| فیلڈ | تفصیل | +| :----------------- | :------------------------------------------------------ | +| `aggregation_bits` | ان ویلیڈیٹرز کی فہرست جنہوں نے اس تصدیق میں حصہ لیا | +| `data` | متعدد سب فیلڈز والا ایک کنٹینر | +| `signature` | `data` حصے کے خلاف ویلیڈیٹرز کے ایک سیٹ کا مجموعی دستخط | + +`attestation` میں `data` فیلڈ میں مندرجہ ذیل چیزیں شامل ہیں: + +| فیلڈ | تفصیل | +| :------------------ | :------------------------------------------------ | +| `slot` | وہ سلاٹ جس سے تصدیق کا تعلق ہے | +| `index` | تصدیق کرنے والے ویلیڈیٹرز کے لیے انڈیکس | +| `beacon_block_root` | بیکن بلاک کا روٹ ہیش جسے چین کا ہیڈ سمجھا جاتا ہے | +| `ذریعہ` | آخری جائز چیک پوائنٹ | +| `target` | تازہ ترین ایپک باؤنڈری بلاک | + +`execution_payload` میں ٹرانزیکشنز کو انجام دینا عالمی اسٹیٹ کو اپ ڈیٹ کرتا ہے۔ تمام کلائنٹس `execution_payload` میں ٹرانزیکشنز کو دوبارہ انجام دیتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ نیا اسٹیٹ نئے بلاک `state_root` فیلڈ میں موجود اسٹیٹ سے میل کھاتا ہے۔ اس طرح کلائنٹس بتا سکتے ہیں کہ نیا بلاک درست ہے اور اسے اپنے بلاک چین میں شامل کرنا محفوظ ہے۔ `execution payload` خود ایک آبجیکٹ ہے جس میں کئی فیلڈز ہیں۔ ایک `execution_payload_header` بھی ہے جس میں ایگزیکیوشن ڈیٹا کے بارے میں اہم خلاصہ معلومات ہوتی ہیں۔ یہ ڈیٹا ڈھانچے مندرجہ ذیل طور پر منظم ہیں: + +`execution_payload_header` میں مندرجہ ذیل فیلڈز ہوتے ہیں: + +| فیلڈ | تفصیل | +| :------------------ | :--------------------------------------------------------------- | +| `parent_hash` | پیرنٹ بلاک کا ہیش | +| `fee_recipient` | ٹرانزیکشن فیس ادا کرنے کے لیے اکاؤنٹ کا ایڈریس | +| `state_root` | اس بلاک میں تبدیلیاں لاگو کرنے کے بعد عالمی اسٹیٹ کے لیے روٹ ہیش | +| `receipts_root` | ٹرانزیکشن رسیدوں کی ٹرائی کا ہیش | +| `logs_bloom` | ایونٹ لاگز پر مشتمل ڈیٹا ڈھانچہ | +| `prev_randao` | تصادفی ویلیڈیٹر کے انتخاب میں استعمال ہونے والی قدر | +| `block_number` | موجودہ بلاک کا نمبر | +| `gas_limit` | اس بلاک میں اجازت یافتہ زیادہ سے زیادہ گیس | +| `gas_used` | اس بلاک میں استعمال ہونے والی گیس کی اصل مقدار | +| `timestamp` | بلاک کا وقت | +| `extra_data` | خام بائٹس کے طور پر صوابدیدی اضافی ڈیٹا | +| `base_fee_per_gas` | بیس فیس کی قدر | +| `block_hash` | ایگزیکیوشن بلاک کا ہیش | +| `transactions_root` | پے لوڈ میں ٹرانزیکشنز کا روٹ ہیش | +| `withdrawal_root` | پے لوڈ میں وِد ڈراولز کا روٹ ہیش | + +`execution_payload` میں خود مندرجہ ذیل چیزیں شامل ہیں (غور کریں کہ یہ ہیڈر سے مماثل ہے سوائے اس کے کہ ٹرانزیکشنز کے روٹ ہیش کے بجائے اس میں ٹرانزیکشنز کی اصل فہرست اور وِد ڈراول کی معلومات شامل ہیں): + +| فیلڈ | تفصیل | +| :----------------- | :--------------------------------------------------------------- | +| `parent_hash` | پیرنٹ بلاک کا ہیش | +| `fee_recipient` | ٹرانزیکشن فیس ادا کرنے کے لیے اکاؤنٹ کا ایڈریس | +| `state_root` | اس بلاک میں تبدیلیاں لاگو کرنے کے بعد عالمی اسٹیٹ کے لیے روٹ ہیش | +| `receipts_root` | ٹرانزیکشن رسیدوں کی ٹرائی کا ہیش | +| `logs_bloom` | ایونٹ لاگز پر مشتمل ڈیٹا ڈھانچہ | +| `prev_randao` | تصادفی ویلیڈیٹر کے انتخاب میں استعمال ہونے والی قدر | +| `block_number` | موجودہ بلاک کا نمبر | +| `gas_limit` | اس بلاک میں اجازت یافتہ زیادہ سے زیادہ گیس | +| `gas_used` | اس بلاک میں استعمال ہونے والی گیس کی اصل مقدار | +| `timestamp` | بلاک کا وقت | +| `extra_data` | خام بائٹس کے طور پر صوابدیدی اضافی ڈیٹا | +| `base_fee_per_gas` | بیس فیس کی قدر | +| `block_hash` | ایگزیکیوشن بلاک کا ہیش | +| `transactions` | انجام دی جانے والی ٹرانزیکشنز کی فہرست | +| `withdrawals` | وِد ڈراول آبجیکٹس کی فہرست | + +`withdrawals` کی فہرست میں `withdrawal` آبجیکٹس شامل ہیں جو مندرجہ ذیل طریقے سے تشکیل دیے گئے ہیں: + +| فیلڈ | تفصیل | +| :--------------- | :------------------------------------ | +| `address` | اکاؤنٹ کا ایڈریس جس نے وِد ڈرا کیا ہے | +| `amount` | وِد ڈراول کی رقم | +| `index` | وِد ڈراول انڈیکس کی قدر | +| `validatorIndex` | ویلیڈیٹر انڈیکس کی قدر | + +## بلاک کا وقت {#block-time} + +بلاک کا وقت بلاکس کو الگ کرنے والے وقت سے مراد ہے۔ ایتھیریم میں، وقت کو بارہ سیکنڈ کی اکائیوں میں تقسیم کیا جاتا ہے جسے 'سلاٹس' کہتے ہیں۔ ہر سلاٹ میں ایک بلاک کی تجویز دینے کے لیے ایک واحد ویلیڈیٹر کو منتخب کیا جاتا ہے۔ یہ فرض کرتے ہوئے کہ تمام ویلیڈیٹرز آن لائن اور مکمل طور پر فعال ہیں، ہر سلاٹ میں ایک بلاک ہوگا، جس کا مطلب ہے کہ بلاک کا وقت 12 سیکنڈ ہے۔ تاہم، کبھی کبھار جب بلاک کی تجویز دینے کے لیے بلایا جاتا ہے تو ویلیڈیٹرز آف لائن ہو سکتے ہیں، جس کا مطلب ہے کہ سلاٹ کبھی کبھی خالی جا سکتے ہیں۔ + +یہ نفاذ پروف-آف-ورک پر مبنی سسٹمز سے مختلف ہے جہاں بلاک کا وقت امکانی ہوتا ہے اور پروٹوکول کی ٹارگٹ مائننگ ڈفیکلٹی کے ذریعے ٹیون کیا جاتا ہے۔ ایتھیریم کا [اوسط بلاک ٹائم](https://etherscan.io/chart/blocktime) اس کی ایک بہترین مثال ہے جس کے تحت پروف-آف-ورک سے پروف-آف-اسٹیک میں منتقلی کا اندازہ نئے 12 سیکنڈ کے بلاک ٹائم کے استحکام کی بنیاد پر واضح طور پر لگایا جا سکتا ہے۔ + +## بلاک کا سائز {#block-size} + +ایک آخری اہم نوٹ یہ ہے کہ بلاکس خود سائز میں محدود ہوتے ہیں۔ ہر بلاک کا ٹارگٹ سائز 30 ملین گیس ہے لیکن بلاکس کا سائز نیٹ ورک کی طلب کے مطابق بڑھے گا یا کم ہوگا، 60 ملین گیس کی بلاک حد تک (2x ٹارگٹ بلاک سائز)۔ بلاک گیس کی حد کو پچھلے بلاک کی گیس کی حد سے 1/1024 کے فیکٹر سے اوپر یا نیچے ایڈجسٹ کیا جا سکتا ہے۔ نتیجے کے طور پر، ویلیڈیٹرز اتفاق رائے کے ذریعے بلاک گیس کی حد کو تبدیل کر سکتے ہیں۔ بلاک میں تمام ٹرانزیکشنز کے ذریعے خرچ کی گئی گیس کی کل مقدار بلاک گیس کی حد سے کم ہونی چاہیے۔ یہ اہم ہے کیونکہ یہ یقینی بناتا ہے کہ بلاکس صوابدیدی طور پر بڑے نہیں ہو سکتے۔ اگر بلاکس صوابدیدی طور پر بڑے ہو سکتے ہیں، تو کم کارکردگی والے مکمل نوڈز آہستہ آہستہ جگہ اور رفتار کی ضروریات کی وجہ سے نیٹ ورک کے ساتھ رفتار برقرار رکھنے کے قابل نہیں رہیں گے۔ بلاک جتنا بڑا ہوگا، اگلے سلاٹ کے لیے وقت پر ان پر کارروائی کرنے کے لیے اتنی ہی زیادہ کمپیوٹنگ پاور درکار ہوگی۔ یہ ایک مرکزیت کی قوت ہے، جس کی مزاحمت بلاک سائز پر حد لگا کر کی جاتی ہے۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ٹرانزیکشنز](/developers/docs/transactions/) +- [گیس](/developers/docs/gas/) +- [پروف-آف-اسٹیک](/developers/docs/consensus-mechanisms/pos) diff --git a/public/content/translations/ur/developers/docs/bridges/index.md b/public/content/translations/ur/developers/docs/bridges/index.md new file mode 100644 index 00000000000..dc7e5b5fdc0 --- /dev/null +++ b/public/content/translations/ur/developers/docs/bridges/index.md @@ -0,0 +1,138 @@ +--- +title: "برجز" +description: "ڈیولپرز کے لیے برجنگ کا ایک جائزہ" +lang: ur-in +--- + +L1 بلاک چینز اور L2 [اسکیلنگ](/developers/docs/scaling/) سلوشنز کے پھیلاؤ کے ساتھ، اور کراس چین جانے والی ڈی سینٹرلائزڈ ایپلی کیشنز کی بڑھتی ہوئی تعداد کے ساتھ، چینز کے درمیان کمیونیکیشن اور اثاثوں کی منتقلی کی ضرورت نیٹ ورک کے بنیادی ڈھانچے کا ایک لازمی حصہ بن گئی ہے۔ اسے ممکن بنانے میں مدد کے لیے مختلف قسم کے برجز موجود ہیں۔ + +## برجز کی ضرورت {#need-for-bridges} + +برجز بلاک چین نیٹ ورکس کو جوڑنے کے لیے موجود ہیں۔ یہ بلاک چینز کے درمیان کنیکٹیویٹی اور انٹرآپریبلٹی کو ممکن بناتے ہیں۔ + +بلاک چینز سائل شدہ ماحول میں موجود ہیں، جس کا مطلب ہے کہ بلاک چینز کے لیے قدرتی طور پر دوسری بلاک چینز کے ساتھ تجارت اور بات چیت کرنے کا کوئی طریقہ نہیں ہے۔ نتیجے کے طور پر، جب کہ ایک ایکو سسٹم کے اندر اہم سرگرمی اور اختراع ہو سکتی ہے، یہ دوسرے ایکو سسٹمز کے ساتھ کنیکٹیویٹی اور انٹرآپریبلٹی کی کمی کی وجہ سے محدود ہے۔ + +برجز الگ تھلگ بلاک چین ماحول کو ایک دوسرے سے جڑنے کا ایک طریقہ پیش کرتے ہیں۔ یہ بلاک چینز کے درمیان ایک ٹرانسپورٹیشن روٹ قائم کرتے ہیں جہاں ٹوکنز، پیغامات، صوابدیدی ڈیٹا، اور یہاں تک کہ [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) کالز کو ایک چین سے دوسری چین میں منتقل کیا جا سکتا ہے۔ + +## برجز کے فوائد {#benefits-of-bridges} + +سیدھے الفاظ میں، برجز بلاک چین نیٹ ورکس کو ڈیٹا کا تبادلہ کرنے اور ان کے درمیان اثاثوں کو منتقل کرنے کی اجازت دے کر متعدد استعمال کے معاملات کو کھولتے ہیں۔ + +بلاک چینز کی اپنی منفرد طاقتیں، کمزوریاں، اور ایپلی کیشنز بنانے کے طریقے ہیں (جیسے رفتار، تھرو پٹ، لاگت، وغیرہ)۔ برجز بلاک چینز کو ایک دوسرے کی اختراعات سے فائدہ اٹھانے کے قابل بنا کر مجموعی کرپٹو ایکو سسٹم کی ترقی میں مدد کرتے ہیں۔ + +ڈیولپرز کے لیے، برجز درج ذیل کو ممکن بناتے ہیں: + +- کسی بھی ڈیٹا، معلومات اور اثاثوں کا چینز کے درمیان منتقلی۔ +- پروٹوکولز کے لیے نئی خصوصیات اور استعمال کے معاملات کو کھولنا کیونکہ برجز اس ڈیزائن کی جگہ کو بڑھاتے ہیں جو پروٹوکول پیش کر سکتے ہیں۔ مثال کے طور پر، ییلڈ فارمنگ کے لیے ایک پروٹوکول جو اصل میں Ethereum Mainnet پر تعینات کیا گیا تھا، تمام EVM-مطابقت رکھنے والی چینز پر لیکویڈیٹی پولز پیش کر سکتا ہے۔ +- مختلف بلاک چینز کی طاقتوں سے فائدہ اٹھانے کا موقع۔ مثال کے طور پر، ڈیولپرز رول اپس اور سائڈ چینز پر اپنے dapps کو تعینات کرکے مختلف L2 حلوں کی طرف سے پیش کردہ کم فیسوں سے فائدہ اٹھا سکتے ہیں اور صارفین ان کے درمیان برج کرسکتے ہیں۔ +- نئی مصنوعات بنانے کے لیے مختلف بلاک چین ایکو سسٹمز کے ڈیولپرز کے درمیان تعاون۔ +- مختلف ایکو سسٹمز سے صارفین اور کمیونٹیز کو ان کے dapps کی طرف راغب کرنا۔ + +## برجز کیسے کام کرتے ہیں؟ {#how-do-bridges-work} + +اگرچہ بہت سے [برج ڈیزائن کی اقسام](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) ہیں، اثاثوں کی کراس-چین منتقلی کو آسان بنانے کے تین طریقے نمایاں ہیں: + +- **لاک اور منٹ –** سورس چین پر اثاثوں کو لاک کریں اور ڈیسٹنیشن چین پر اثاثوں کو منٹ کریں۔ +- **برن اور منٹ –** سورس چین پر اثاثوں کو برن کریں اور ڈیسٹنیشن چین پر اثاثوں کو منٹ کریں۔ +- **ایٹامک سواپس –** سورس چین پر موجود اثاثوں کو کسی دوسری پارٹی کے ساتھ ڈیسٹنیشن چین پر موجود اثاثوں کے لیے سواپ کریں۔ + +## برج کی اقسام {#bridge-types} + +برجز کو عام طور پر درج ذیل میں سے کسی ایک زمرے میں تقسیم کیا جا سکتا ہے: + +- **نیٹیو برجز –** یہ برجز عام طور پر کسی خاص بلاک چین پر لیکویڈیٹی کو بوٹ اسٹریپ کرنے کے لیے بنائے جاتے ہیں، جس سے صارفین کے لیے ایکو سسٹم میں فنڈز منتقل کرنا آسان ہو جاتا ہے۔ مثال کے طور پر، [Arbitrum Bridge](https://bridge.arbitrum.io/) کو صارفین کے لیے Ethereum Mainnet سے Arbitrum تک برجنگ کو آسان بنانے کے لیے بنایا گیا ہے۔ دیگر ایسے برجز میں Polygon PoS Bridge, [Optimism Gateway](https://app.optimism.io/bridge) وغیرہ شامل ہیں۔ +- **ویلیڈیٹر یا اوریکل پر مبنی برجز –** یہ برجز کراس-چین منتقلی کی توثیق کے لیے ایک بیرونی ویلیڈیٹر سیٹ یا اوریکلز پر انحصار کرتے ہیں۔ مثالیں: Multichain اور Across. +- **عمومی پیغام رسانی والے برجز –** یہ برجز اثاثوں کے ساتھ ساتھ پیغامات اور صوابدیدی ڈیٹا کو چینز کے درمیان منتقل کر سکتے ہیں۔ مثالیں: Axelar, LayerZero, اور Nomad. +- **لیکویڈیٹی نیٹ ورکس –** یہ برجز بنیادی طور پر ایٹامک سواپس کے ذریعے ایک چین سے دوسری چین میں اثاثوں کی منتقلی پر توجہ مرکوز کرتے ہیں۔ عام طور پر، یہ کراس-چین پیغام رسانی کو سپورٹ نہیں کرتے ہیں۔ مثالیں: Connext اور Hop. + +## غور کرنے کے لیے ٹریڈ-آفس {#trade-offs} + +برجز کے ساتھ، کوئی بھی حل کامل نہیں ہے۔ بلکہ، کسی مقصد کو پورا کرنے کے لیے صرف ٹریڈ-آفس کیے جاتے ہیں۔ ڈیولپرز اور صارفین درج ذیل عوامل کی بنیاد پر برجز کا جائزہ لے سکتے ہیں: + +- **سیکیورٹی –** سسٹم کی تصدیق کون کرتا ہے؟ بیرونی ویلیڈیٹرز کے ذریعے محفوظ کیے گئے برجز عام طور پر ان برجز کے مقابلے میں کم محفوظ ہوتے ہیں جو مقامی طور پر یا مقامی طور پر بلاک چین کے ویلیڈیٹرز کے ذریعے محفوظ ہوتے ہیں۔ +- **سہولت –** ایک ٹرانزیکشن مکمل کرنے میں کتنا وقت لگتا ہے، اور ایک صارف کو کتنی ٹرانزیکشنز پر دستخط کرنے کی ضرورت ہوتی ہے؟ ایک ڈیولپر کے لیے، ایک برج کو انٹیگریٹ کرنے میں کتنا وقت لگتا ہے، اور یہ عمل کتنا پیچیدہ ہے؟ +- **کنیکٹیویٹی –** ایک برج کن مختلف ڈیسٹنیشن چینز کو جوڑ سکتا ہے (یعنی، رول اپس، سائڈ چینز، دیگر لیئر 1 بلاک چینز، وغیرہ)، اور ایک نئی بلاک چین کو انٹیگریٹ کرنا کتنا مشکل ہے؟ +- **زیادہ پیچیدہ ڈیٹا منتقل کرنے کی صلاحیت –** کیا کوئی برج چینز کے درمیان پیغامات اور زیادہ پیچیدہ صوابدیدی ڈیٹا کی منتقلی کو فعال کر سکتا ہے، یا یہ صرف کراس-چین اثاثوں کی منتقلی کو سپورٹ کرتا ہے؟ +- **لاگت کی تاثیر –** ایک برج کے ذریعے چینز میں اثاثے منتقل کرنے پر کتنی لاگت آتی ہے؟ عام طور پر، برجز گیس کی لاگت اور مخصوص راستوں کی لیکویڈیٹی کے لحاظ سے ایک مقررہ یا متغیر فیس لیتے ہیں۔ اس کی سیکیورٹی کو یقینی بنانے کے لیے درکار سرمائے کی بنیاد پر کسی برج کی لاگت کی تاثیر کا جائزہ لینا بھی اہم ہے۔ + +اعلیٰ سطح پر، برجز کو قابل اعتماد (trusted) اور بے اعتماد (trustless) کے طور پر درجہ بندی کیا جا سکتا ہے۔ + +- **قابل اعتماد –** قابل اعتماد برجز کی بیرونی طور پر تصدیق کی جاتی ہے۔ وہ چینز کے درمیان ڈیٹا بھیجنے کے لیے تصدیق کاروں کا ایک بیرونی سیٹ (ملٹی-سِگ کے ساتھ فیڈریشنز، ملٹی پارٹی کمپیوٹیشن سسٹمز، اوریکل نیٹ ورک) استعمال کرتے ہیں۔ نتیجے کے طور پر، وہ بہترین کنیکٹیویٹی پیش کر سکتے ہیں اور چینز میں مکمل طور پر عمومی پیغام رسانی کو فعال کر سکتے ہیں۔ وہ رفتار اور لاگت کی تاثیر کے ساتھ بھی اچھی کارکردگی کا مظاہرہ کرتے ہیں۔ یہ سیکیورٹی کی قیمت پر آتا ہے، کیونکہ صارفین کو برج کی سیکیورٹی پر بھروسہ کرنا پڑتا ہے۔ +- **بے اعتماد –** یہ برجز پیغامات اور ٹوکنز کی منتقلی کے لیے ان بلاک چینز اور ان کے ویلیڈیٹرز پر انحصار کرتے ہیں جن سے وہ جڑ رہے ہیں۔ وہ 'بے اعتماد' ہیں کیونکہ وہ (بلاک چینز کے علاوہ) کوئی نیا اعتماد مفروضہ شامل نہیں کرتے ہیں۔ نتیجے کے طور پر، بے اعتماد برجز کو قابل اعتماد برجز سے زیادہ محفوظ سمجھا جاتا ہے۔ + +دیگر عوامل کی بنیاد پر بے اعتماد برجز کا جائزہ لینے کے لیے، ہمیں انہیں عمومی پیغام رسانی والے برجز اور لیکویڈیٹی نیٹ ورکس میں تقسیم کرنا چاہیے۔ + +- **عمومی پیغام رسانی والے برجز –** یہ برجز سیکیورٹی اور چینز میں زیادہ پیچیدہ ڈیٹا منتقل کرنے کی صلاحیت کے ساتھ بہترین ہیں۔ عام طور پر، وہ لاگت کی تاثیر کے ساتھ بھی اچھے ہیں۔ تاہم، یہ طاقتیں عام طور پر لائٹ کلائنٹ برجز (مثلاً: IBC) کے لیے کنیکٹیویٹی کی قیمت پر آتی ہیں اور آپٹیمسٹک برجز (مثلاً: Nomad) کے لیے رفتار کی کمیوں پر جو فراڈ پروفس کا استعمال کرتے ہیں۔ +- **لیکویڈیٹی نیٹ ورکس –** یہ برجز اثاثوں کی منتقلی کے لیے ایٹامک سواپس کا استعمال کرتے ہیں اور مقامی طور پر تصدیق شدہ سسٹمز ہیں (یعنی، وہ ٹرانزیکشنز کی تصدیق کے لیے بنیادی بلاک چینز کے ویلیڈیٹرز کا استعمال کرتے ہیں)۔ نتیجے کے طور پر، وہ سیکیورٹی اور رفتار میں بہترین ہیں۔ مزید برآں، انہیں نسبتاً لاگت کے لحاظ سے موثر سمجھا جاتا ہے اور اچھی کنیکٹیویٹی پیش کرتے ہیں۔ تاہم، سب سے بڑا ٹریڈ آف زیادہ پیچیدہ ڈیٹا کو منتقل کرنے میں ان کی نااہلی ہے – کیونکہ وہ کراس-چین پیغام رسانی کی حمایت نہیں کرتے ہیں۔ + +## برجز کے ساتھ خطرہ {#risk-with-bridges} + +برجز [DeFi میں سرفہرست تین سب سے بڑے ہیکس](https://rekt.news/leaderboard/) کا حصہ ہیں اور اب بھی ترقی کے ابتدائی مراحل میں ہیں۔ کسی بھی برج کا استعمال درج ذیل خطرات رکھتا ہے: + +- **اسمارٹ کنٹریکٹ کا خطرہ –** جب کہ بہت سے برجز نے کامیابی سے آڈٹ پاس کر لیے ہیں، اثاثوں کو ہیکس کے سامنے لانے کے لیے اسمارٹ کنٹریکٹ میں صرف ایک خامی کی ضرورت ہے (مثال: [Solana’s Wormhole Bridge](https://rekt.news/wormhole-rekt/))۔ +- **سسٹمک مالیاتی خطرات** – بہت سے برجز ایک نئی چین پر اصل اثاثے کے کینونیکل ورژنز کو منٹ کرنے کے لیے ریپڈ اثاثوں کا استعمال کرتے ہیں۔ یہ ایکو سسٹم کو سسٹمک خطرے سے دوچار کرتا ہے، جیسا کہ ہم نے ٹوکنز کے ریپڈ ورژنز کا استحصال ہوتے دیکھا ہے۔ +- **کاؤنٹر پارٹی کا خطرہ –** کچھ برجز ایک قابل اعتماد ڈیزائن کا استعمال کرتے ہیں جس کے لیے صارفین کو اس مفروضے پر بھروسہ کرنے کی ضرورت ہوتی ہے کہ ویلیڈیٹرز صارفین کے فنڈز چرانے کے لیے ملی بھگت نہیں کریں گے۔ صارفین کو ان تھرڈ پارٹی اداکاروں پر بھروسہ کرنے کی ضرورت انہیں رگ پلز، سنسرشپ، اور دیگر بدنیتی پر مبنی سرگرمیوں جیسے خطرات سے دوچار کرتی ہے۔ +- کھلے مسائل – یہ دیکھتے ہوئے کہ برجز ترقی کے ابتدائی مراحل میں ہیں، اس سے متعلق بہت سے سوالات کے جوابات نہیں ملے ہیں کہ برجز مختلف مارکیٹ کے حالات میں کیسی کارکردگی کا مظاہرہ کریں گے، جیسے نیٹ ورک کی بھیڑ کے اوقات اور نیٹ ورک کی سطح کے حملوں یا اسٹیٹ رول بیکس جیسے غیر متوقع واقعات کے دوران۔ یہ غیر یقینی صورتحال کچھ خطرات پیدا کرتی ہے، جن کی ڈگری ابھی تک نامعلوم ہے۔ + +## dapps برجز کا استعمال کیسے کر سکتے ہیں؟ {#how-can-dapps-use-bridges} + +یہاں کچھ عملی ایپلی کیشنز ہیں جن پر ڈیولپرز برجز اور اپنے dapp کو کراس چین لے جانے کے بارے میں غور کر سکتے ہیں: + +### برجز کو انٹیگریٹ کرنا {#integrating-bridges} + +ڈیولپرز کے لیے، برجز کے لیے سپورٹ شامل کرنے کے بہت سے طریقے ہیں: + +1. **اپنا برج بنانا –** ایک محفوظ اور قابل اعتماد برج بنانا آسان نہیں ہے، خاص طور پر اگر آپ زیادہ سے زیادہ اعتماد کو کم کرنے والا راستہ اختیار کرتے ہیں۔ مزید برآں، اس کے لیے اسکیل ایبلٹی اور انٹرآپریبلٹی کے مطالعے سے متعلق برسوں کا تجربہ اور تکنیکی مہارت درکار ہوتی ہے۔ مزید برآں، اس کے لیے ایک برج کو برقرار رکھنے اور اسے قابل عمل بنانے کے لیے کافی لیکویڈیٹی کو راغب کرنے کے لیے ایک ہینڈ آن ٹیم کی ضرورت ہوگی۔ + +2. **صارفین کو برج کے متعدد اختیارات دکھانا –** بہت سے [dapps](/developers/docs/dapps/) کو صارفین کے ساتھ بات چیت کرنے کے لیے ان کے مقامی ٹوکن کی ضرورت ہوتی ہے۔ صارفین کو اپنے ٹوکنز تک رسائی کے قابل بنانے کے لیے، وہ اپنی ویب سائٹ پر برج کے مختلف اختیارات پیش کرتے ہیں۔ تاہم، یہ طریقہ اس مسئلے کا ایک فوری حل ہے کیونکہ یہ صارف کو dapp انٹرفیس سے دور لے جاتا ہے اور پھر بھی ان سے دوسرے dapps اور برجز کے ساتھ بات چیت کرنے کی ضرورت ہوتی ہے۔ یہ غلطیاں کرنے کے بڑھتے ہوئے دائرہ کار کے ساتھ ایک بوجھل آن بورڈنگ تجربہ ہے۔ + +3. **ایک برج کو انٹیگریٹ کرنا –** اس حل میں dapp کو صارفین کو بیرونی برج اور DEX انٹرفیس پر بھیجنے کی ضرورت نہیں ہے۔ یہ dapps کو صارف کے آن بورڈنگ کے تجربے کو بہتر بنانے کی اجازت دیتا ہے۔ تاہم، اس نقطہ نظر کی اپنی حدود ہیں: + + - برجز کا جائزہ اور دیکھ بھال مشکل اور وقت طلب ہے۔ + - ایک برج کا انتخاب ناکامی اور انحصار کا ایک واحد نقطہ بناتا ہے۔ + - dapp برج کی صلاحیتوں سے محدود ہے۔ + - صرف برجز کافی نہیں ہو سکتے۔ Dapps کو مزید فعالیت پیش کرنے کے لیے DEXs کی ضرورت ہو سکتی ہے جیسے کراس چین سواپس۔ + +4. **متعدد برجز کو انٹیگریٹ کرنا –** یہ حل ایک ہی برج کو انٹیگریٹ کرنے سے وابستہ بہت سے مسائل کو حل کرتا ہے۔ تاہم، اس کی بھی حدود ہیں، کیونکہ متعدد برجز کو انٹیگریٹ کرنا وسائل طلب ہے اور ڈیولپرز کے لیے تکنیکی اور مواصلاتی اوور ہیڈز پیدا کرتا ہے — جو کرپٹو میں سب سے نایاب وسیلہ ہے۔ + +5. **برج ایگریگیٹر کو انٹیگریٹ کرنا –** dapps کے لیے ایک اور آپشن برج ایگریگیشن حل کو انٹیگریٹ کرنا ہے جو انہیں متعدد برجز تک رسائی فراہم کرتا ہے۔ برج ایگریگیٹرز تمام برجز کی طاقتوں کو وراثت میں پاتے ہیں اور اس طرح کسی ایک برج کی صلاحیتوں سے محدود نہیں ہوتے ہیں۔ خاص طور پر، برج ایگریگیٹرز عام طور پر برج انٹیگریشنز کو برقرار رکھتے ہیں، جو dapp کو برج انٹیگریشن کے تکنیکی اور آپریشنل پہلوؤں پر نظر رکھنے کی پریشانی سے بچاتا ہے۔ + +اس کے باوجود، برج ایگریگیٹرز کی بھی اپنی حدود ہیں۔ مثال کے طور پر، جب کہ وہ برج کے مزید اختیارات پیش کر سکتے ہیں، ایگریگیٹر کے پلیٹ فارم پر پیش کیے جانے والے اختیارات کے علاوہ مارکیٹ میں عام طور پر بہت سے اور برجز دستیاب ہوتے ہیں۔ مزید برآں، بالکل برجز کی طرح، برج ایگریگیٹرز بھی اسمارٹ کنٹریکٹ اور ٹیکنالوجی کے خطرات سے دوچار ہوتے ہیں (زیادہ اسمارٹ کنٹریکٹس = زیادہ خطرات)۔ + +اگر کوئی dapp کسی برج یا ایگریگیٹر کو انٹیگریٹ کرنے کے راستے پر جاتا ہے، تو اس بنیاد پر مختلف آپشنز ہوتے ہیں کہ انٹیگریشن کتنی گہری ہونی ہے۔ مثال کے طور پر، اگر یہ صرف صارف کے آن بورڈنگ کے تجربے کو بہتر بنانے کے لیے ایک فرنٹ-اینڈ انٹیگریشن ہے، تو ایک dapp ویجیٹ کو انٹیگریٹ کرے گا۔ تاہم، اگر انٹیگریشن کا مقصد اسٹیکنگ، ییلڈ فارمنگ، وغیرہ جیسی گہری کراس چین حکمت عملیوں کو تلاش کرنا ہے، تو dapp SDK یا API کو انٹیگریٹ کرتا ہے۔ + +### متعدد چینز پر dapp تعینات کرنا {#deploying-a-dapp-on-multiple-chains} + +متعدد چینز پر dapp تعینات کرنے کے لیے، ڈیولپرز [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) وغیرہ جیسے ڈیولپمنٹ پلیٹ فارمز کا استعمال کر سکتے ہیں۔ عام طور پر، یہ پلیٹ فارمز کمپوز ایبل پلگ انز کے ساتھ آتے ہیں جو dapps کو کراس چین جانے کے قابل بنا سکتے ہیں۔ مثال کے طور پر، ڈیولپرز [hardhat-deploy plugin](https://github.com/wighawag/hardhat-deploy) کی طرف سے پیش کردہ ڈیٹرمنسٹک ڈیپلائمنٹ پراکسی کا استعمال کر سکتے ہیں۔ + +#### مثالیں: + +- [کراس چین dapps کیسے بنائیں](https://moralis.io/how-to-build-cross-chain-dapps/) +- [ایک کراس چین NFT مارکیٹ پلیس بنانا](https://youtu.be/WZWCzsB1xUE) +- [Moralis: کراس چین NFT dapps بنانا](https://www.youtube.com/watch?v=ehv70kE1QYo) + +### چینز میں کنٹریکٹ کی سرگرمی کی نگرانی کرنا {#monitoring-contract-activity-across-chains} + +چینز میں کنٹریکٹ کی سرگرمی کی نگرانی کے لیے، ڈیولپرز اسمارٹ کنٹریکٹس کو ریئل ٹائم میں دیکھنے کے لیے سب گراف اور Tenderly جیسے ڈیولپر پلیٹ فارمز کا استعمال کر سکتے ہیں۔ اس طرح کے پلیٹ فارمز میں ایسے ٹولز بھی ہوتے ہیں جو کراس چین سرگرمیوں کے لیے ڈیٹا کی نگرانی کی زیادہ فعالیت پیش کرتے ہیں، جیسے کہ [کنٹریکٹس کے ذریعے خارج ہونے والے واقعات](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) کی جانچ کرنا، وغیرہ۔ + +#### ٹولز + +- [The Graph](https://thegraph.com/en/) +- [Tenderly](https://tenderly.co/) + +## مزید پڑھیں {#further-reading} + +- [بلاک چین برجز](/bridges/) – ethereum.org +- [L2Beat Bridge Risk Framework](https://l2beat.com/bridges/summary) +- [بلاک چین برجز: کرپٹو نیٹ ورکس کے نیٹ ورکس بنانا](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 8 ستمبر، 2021 – Dmitriy Berenzon +- [انٹرآپریبلٹی ٹرائیلیما](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 1 اکتوبر، 2021 – Arjun Bhuptani +- [کلسٹرز: کس طرح قابل اعتماد اور اعتماد کو کم کرنے والے برجز ملٹی چین لینڈ اسکیپ کو شکل دیتے ہیں](https://blog.celestia.org/clusters/) - 4 اکتوبر، 2021 – Mustafa Al-Bassam +- [LI.FI: برجز کے ساتھ، اعتماد ایک اسپیکٹرم ہے](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 28 اپریل، 2022 – Arjun Chand +- [رول اپ انٹرآپریبلٹی سلوشنز کی حالت](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 20 جون، 2024 – Alex Hook +- [محفوظ کراس چین انٹرآپریبلٹی کے لیے مشترکہ سیکیورٹی کا استعمال: Lagrange اسٹیٹ کمیٹیاں اور اس سے آگے](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 12 جون، 2024 – Emmanuel Awosika + +مزید برآں، یہاں [James Prestwich](https://twitter.com/_prestwich) کی کچھ بصیرت انگیز پیشکشیں ہیں جو برجز کی گہری تفہیم پیدا کرنے میں مدد کر سکتی ہیں: + +- [برجز بنانا، دیواروں والے باغات نہیں](https://youtu.be/ZQJWMiX4hT0) +- [برجز کو توڑنا](https://youtu.be/b0mC-ZqN8Oo) +- [برجز کیوں جل رہے ہیں](https://youtu.be/c7cm2kd20j8) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/index.md new file mode 100644 index 00000000000..87bb2d68677 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/index.md @@ -0,0 +1,92 @@ +--- +title: "اتفاق رائے کے میکانزم" +description: "تقسیم شدہ نظاموں میں اتفاق رائے کے پروٹوکول کی وضاحت اور ایتھیریم میں ان کا کردار۔" +lang: ur-in +--- + +اصطلاح 'اتفاق رائے کا میکانزم' اکثر بول چال میں 'ثبوتِ حصص' (proof-of-stake)، 'ثبوتِ کار' (proof-of-work) یا 'ثبوتِ اختیار' (proof-of-authority) پروٹوکولز کے لیے استعمال ہوتی ہے۔ تاہم، یہ اتفاق رائے کے میکانزم میں محض اجزاء ہیں جو [سائبل حملوں](/glossary/#sybil-attack) سے بچاتے ہیں۔ اتفاق رائے کے میکانزم، خیالات، پروٹوکولز اور ترغیبات کا مکمل مجموعہ ہیں جو نوڈز کے ایک تقسیم شدہ سیٹ کو بلاک چین کی حالت پر متفق ہونے کے قابل بناتے ہیں۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے ہمارا [ایتھیریم کا تعارف](/developers/docs/intro-to-ethereum/) پڑھیں۔ + +## اتفاق رائے کیا ہے؟ {#what-is-consensus} + +اتفاق رائے سے ہماری مراد یہ ہے کہ ایک عمومی معاہدہ طے پا گیا ہے۔ سینما جانے والے لوگوں کے ایک گروپ پر غور کریں۔ اگر فلم کے مجوزہ انتخاب پر کوئی اختلاف نہیں ہے، تو اتفاق رائے حاصل ہو جاتا ہے۔ اگر اختلاف ہے تو گروپ کے پاس یہ فیصلہ کرنے کا ذریعہ ہونا چاہیے کہ کون سی فلم دیکھنی ہے۔ انتہائی صورتوں میں، گروپ بالآخر تقسیم ہو جائے گا۔ + +ایتھیریم بلاک چین کے سلسلے میں، یہ عمل باقاعدہ ہے، اور اتفاق رائے تک پہنچنے کا مطلب ہے کہ نیٹ ورک پر کم از کم 66% نوڈز نیٹ ورک کی عالمی حالت پر متفق ہوں۔ + +## اتفاق رائے کا میکانزم کیا ہے؟ {#what-is-a-consensus-mechanism} + +اصطلاح اتفاق رائے کا میکانزم پروٹوکولز، ترغیبات اور خیالات کے پورے مجموعے سے مراد ہے جو نوڈز کے نیٹ ورک کو بلاک چین کی حالت پر متفق ہونے کی اجازت دیتا ہے۔ + +ایتھیریم ثبوتِ حصص (proof-of-stake) پر مبنی اتفاق رائے کا میکانزم استعمال کرتا ہے جو اپنی کرپٹو-اقتصادی سیکیورٹی اسٹیکرز (stakers) کے ذریعے لاک کیے گئے سرمائے پر لاگو انعامات اور جرمانوں کے ایک سیٹ سے حاصل کرتا ہے۔ یہ ترغیبی ڈھانچہ انفرادی اسٹیکرز کو ایماندار توثیق کار (validators) چلانے کی ترغیب دیتا ہے، جو ایسا نہیں کرتے انہیں سزا دیتا ہے، اور نیٹ ورک پر حملہ کرنے کے لیے ایک انتہائی زیادہ لاگت پیدا کرتا ہے۔ + +پھر، ایک ایسا پروٹوکول ہے جو اس بات پر حکمرانی کرتا ہے کہ بلاکس کی تجویز یا توثیق کرنے، ٹرانزیکشنز پر کارروائی کرنے، اور چین کے ہیڈ کے بارے میں اپنے نظریے کے لیے ووٹ دینے کے لیے ایماندار توثیق کاروں کو کیسے منتخب کیا جاتا ہے۔ ایسی نادر صورتوں میں جہاں چین کے ہیڈ کے قریب ایک ہی پوزیشن پر متعدد بلاکس ہوتے ہیں، وہاں ایک فورک-چوائس میکانزم ہوتا ہے جو ان بلاکس کو منتخب کرتا ہے جو 'سب سے بھاری' چین بناتے ہیں، جس کی پیمائش بلاکس کے لیے ووٹ دینے والے توثیق کاروں کی تعداد سے کی جاتی ہے جو ان کے اسٹیک شدہ ایتھر بیلنس کے حساب سے وزن کیے جاتے ہیں۔ + +کچھ تصورات اتفاق رائے کے لیے اہم ہیں جو کوڈ میں واضح طور پر بیان نہیں کیے گئے ہیں، جیسے کہ نیٹ ورک پر حملوں کے خلاف دفاع کی آخری لائن کے طور پر ممکنہ آؤٹ-آف-بینڈ سماجی ہم آہنگی کے ذریعے پیش کردہ اضافی سیکیورٹی۔ + +یہ اجزاء مل کر اتفاق رائے کا میکانزم بناتے ہیں۔ + +## اتفاق رائے کے میکانزم کی اقسام {#types-of-consensus-mechanisms} + +### ثبوتِ کار (Proof-of-work) پر مبنی {#proof-of-work} + +بٹ کوائن کی طرح، ایتھیریم بھی کبھی **ثبوتِ کار (PoW)** پر مبنی اتفاق رائے کا پروٹوکول استعمال کرتا تھا۔ + +#### بلاک کی تخلیق {#pow-block-creation} + +کان کن (Miners) نئے بلاکس بنانے کے لیے مقابلہ کرتے ہیں جو پروسیس شدہ ٹرانزیکشنز سے بھرے ہوتے ہیں۔ فاتح نئے بلاک کو باقی نیٹ ورک کے ساتھ شیئر کرتا ہے اور کچھ نئے بنائے گئے ETH کماتا ہے۔ یہ دوڑ وہ کمپیوٹر جیتتا ہے جو ریاضی کی ایک پہیلی کو سب سے تیزی سے حل کرنے کے قابل ہوتا ہے۔ یہ موجودہ بلاک اور اس سے پہلے والے بلاک کے درمیان کرپٹوگرافک لنک پیدا کرتا ہے۔ اس پہیلی کو حل کرنا ہی \"proof-of-work\" میں موجود 'کام' ہے۔ اس کے بعد کینونیکل چین کا تعین ایک فورک-چوائس اصول کے ذریعے کیا جاتا ہے جو بلاکس کے اس سیٹ کو منتخب کرتا ہے جن کو مائن کرنے کے لیے سب سے زیادہ کام کیا گیا ہو۔ + +#### سیکیورٹی {#pow-security} + +نیٹ ورک اس حقیقت سے محفوظ رہتا ہے کہ چین کے ساتھ دھوکہ دہی کے لیے آپ کو نیٹ ورک کی 51% کمپیوٹنگ پاور کی ضرورت ہوگی۔ اس کے لیے آلات اور توانائی میں بہت بڑی سرمایہ کاری کی ضرورت ہوگی؛ امکان ہے کہ آپ جتنا حاصل کریں گے اس سے زیادہ خرچ کر دیں گے۔ + +[ثبوتِ کار (proof-of-work)](/developers/docs/consensus-mechanisms/pow/) پر مزید + +### ثبوتِ حصص (Proof-of-stake) پر مبنی {#proof-of-stake} + +ایتھیریم اب **ثبوتِ حصص (PoS)** پر مبنی اتفاق رائے کا پروٹوکول استعمال کرتا ہے۔ + +#### بلاک کی تخلیق {#pos-block-creation} + +توثیق کار (Validators) بلاکس بناتے ہیں۔ ہر سلاٹ میں ایک توثیق کار کو تصادفی طور پر بلاک تجویز کرنے والا (block proposer) بننے کے لیے منتخب کیا جاتا ہے۔ ان کا اتفاق رائے کلائنٹ (consensus client) اپنے جوڑے ہوئے ایگزیکیوشن کلائنٹ سے ٹرانزیکشنز کے ایک بنڈل کی بطور 'ایگزیکیوشن پے لوڈ' درخواست کرتا ہے۔ وہ اسے اتفاق رائے کے ڈیٹا میں لپیٹ کر ایک بلاک بناتے ہیں، جسے وہ ایتھیریم نیٹ ورک پر دوسرے نوڈز کو بھیجتے ہیں۔ اس بلاک کی پروڈکشن کا انعام ETH میں دیا جاتا ہے۔ ایسی نادر صورتوں میں جب ایک ہی سلاٹ کے لیے متعدد ممکنہ بلاکس موجود ہوں، یا نوڈز مختلف اوقات میں بلاکس کے بارے میں سنتے ہیں، تو فورک چوائس الگورتھم اس بلاک کو چنتا ہے جو تصدیقوں (attestations) کے سب سے زیادہ وزن والی چین بناتا ہے (جہاں وزن ان توثیق کاروں کی تعداد ہے جو ان کے ETH بیلنس کے حساب سے اسکیل کیے گئے ہیں)۔ + +#### سیکیورٹی {#pos-security} + +ایک ثبوتِ حصص (proof-of-stake) سسٹم کرپٹو-اقتصادی طور پر محفوظ ہے کیونکہ چین پر کنٹرول حاصل کرنے کی کوشش کرنے والے حملہ آور کو ETH کی ایک بڑی مقدار کو تباہ کرنا پڑے گا۔ انعامات کا ایک نظام انفرادی اسٹیکرز کو ایمانداری سے برتاؤ کرنے کی ترغیب دیتا ہے، اور جرمانے اسٹیکرز کو بدنیتی سے کام کرنے سے روکتے ہیں۔ + +[ثبوتِ حصص (proof-of-stake)](/developers/docs/consensus-mechanisms/pos/) پر مزید + +### ایک بصری گائیڈ {#types-of-consensus-video} + +ایتھیریم پر استعمال ہونے والے مختلف قسم کے اتفاق رائے کے میکانزم کے بارے میں مزید دیکھیں: + + + +### سائبل مزاحمت اور چین کا انتخاب {#sybil-chain} + +ثبوتِ کار (Proof-of-work) اور ثبوتِ حصص (proof-of-stake) بذات خود اتفاق رائے کے پروٹوکول نہیں ہیں، لیکن سادگی کی خاطر انہیں اکثر ایسا کہا جاتا ہے۔ وہ دراصل سائبل مزاحمتی میکانزم اور بلاک کے مصنف کے انتخاب کنندہ ہیں؛ وہ یہ فیصلہ کرنے کا ایک طریقہ ہیں کہ تازہ ترین بلاک کا مصنف کون ہے۔ ایک اور اہم جزو چین سلیکشن (عرف فورک چوائس) الگورتھم ہے جو نوڈز کو ایسے منظرناموں میں جہاں ایک ہی پوزیشن پر متعدد بلاکس موجود ہوں، چین کے ہیڈ پر ایک واحد صحیح بلاک منتخب کرنے کے قابل بناتا ہے۔ + +**سائبل مزاحمت** اس بات کی پیمائش کرتی ہے کہ ایک پروٹوکول سائبل حملے کے خلاف کیسا کام کرتا ہے۔ اس قسم کے حملے کے خلاف مزاحمت ایک غیر مرکزی بلاک چین کے لیے ضروری ہے اور یہ کان کنوں (miners) اور توثیق کاروں (validators) کو لگائے گئے وسائل کی بنیاد پر مساوی طور پر انعام پانے کے قابل بناتی ہے۔ ثبوتِ کار (Proof-of-work) اور ثبوتِ حصص (proof-of-stake) صارفین سے بہت زیادہ توانائی خرچ کروا کر یا بہت زیادہ کولیٹرل رکھوا کر اس سے بچاتے ہیں۔ یہ تحفظات سائبل حملوں کے لیے ایک اقتصادی رکاوٹ ہیں۔ + +**چین کے انتخاب کا اصول** یہ فیصلہ کرنے کے لیے استعمال کیا جاتا ہے کہ کون سی چین \"درست\" چین ہے۔ بٹ کوائن \"سب سے لمبی چین\" کا اصول استعمال کرتا ہے، جس کا مطلب ہے کہ جو بھی بلاک چین سب سے لمبی ہوگی وہی وہ ہوگی جسے باقی نوڈز درست تسلیم کریں گے اور اس کے ساتھ کام کریں گے۔ ثبوتِ کار (proof-of-work) چینز کے لیے، سب سے لمبی چین کا تعین چین کی کل مجموعی ثبوتِ کار (proof-of-work) کی مشکل (difficulty) سے کیا جاتا ہے۔ ایتھیریم بھی سب سے لمبی چین کا اصول استعمال کرتا تھا؛ تاہم، اب جب کہ ایتھیریم ثبوتِ حصص (proof-of-stake) پر چلتا ہے، اس نے ایک اپڈیٹ شدہ فورک-چوائس الگورتھم اپنایا ہے جو چین کے 'وزن' کی پیمائش کرتا ہے۔ یہ وزن توثیق کاروں کے ووٹوں کا جمع شدہ مجموعہ ہے، جس کا وزن توثیق کار کے اسٹیک شدہ ایتھر بیلنس کے مطابق کیا جاتا ہے۔ + +ایتھیریم [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) کے نام سے جانا جانے والا ایک اتفاق رائے کا میکانزم استعمال کرتا ہے جو [Casper FFG proof-of-stake](https://arxiv.org/abs/1710.09437) کو [GHOST fork-choice rule](https://arxiv.org/abs/2003.03052) کے ساتھ ملاتا ہے۔ + +## مزید پڑھیں {#further-reading} + +- [بلاک چین اتفاق رائے الگورتھم کیا ہے؟](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) +- [ناکاموتو اتفاق رائے کیا ہے؟ مبتدیوں کے لیے مکمل گائیڈ](https://blockonomi.com/nakamoto-consensus/) +- [کیسپر کیسے کام کرتا ہے؟](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) +- [ثبوتِ کار (Proof of Work) بلاک چینز کی سیکیورٹی اور کارکردگی پر](https://eprint.iacr.org/2016/555.pdf) +- [بائزنٹائن فالٹ](https://en.wikipedia.org/wiki/Byzantine_fault) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ثبوتِ کار (Proof-of-work)](/developers/docs/consensus-mechanisms/pow/) +- [مائننگ](/developers/docs/consensus-mechanisms/pow/mining/) +- [ثبوتِ حصص (Proof-of-stake)](/developers/docs/consensus-mechanisms/pos/) +- [ثبوتِ اختیار (Proof-of-authority)](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/poa/index.md new file mode 100644 index 00000000000..39fd4cdccf2 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/poa/index.md @@ -0,0 +1,80 @@ +--- +title: "اختیار کا ثبوت (PoA)" +description: "اختیار کا ثبوت اتفاق رائے پروٹوکول اور بلاک چین ایکو سسٹم میں اس کے کردار کی وضاحت۔" +lang: ur-in +--- + +**اختیار کا ثبوت (PoA)** ایک ساکھ پر مبنی اتفاق رائے کا الگورتھم ہے جو [اسٹیک کے ثبوت](/developers/docs/consensus-mechanisms/pos/) کا ایک ترمیم شدہ ورژن ہے۔ یہ زیادہ تر پرائیویٹ چینز، ٹیسٹ نیٹس، اور لوکل ڈیولپمنٹ نیٹ ورکس کے ذریعے استعمال کیا جاتا ہے۔ PoA ایک ساکھ پر مبنی اتفاق رائے کا الگورتھم ہے جس میں PoS میں اسٹیک پر مبنی میکانزم کے بجائے، بلاکس تیار کرنے کے لیے مجاز دستخط کنندگان کے ایک سیٹ پر بھروسہ کرنے کی ضرورت ہوتی ہے۔ + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ٹرانزیکشنز](/developers/docs/transactions/)، [بلاکس](/developers/docs/blocks/)، اور [اتفاق رائے کے طریقہ کار](/developers/docs/consensus-mechanisms/) کے بارے میں پڑھیں۔ + +## اختیار کا ثبوت (PoA) کیا ہے؟ {#what-is-poa} + +اختیار کا ثبوت **[اسٹیک کے ثبوت](/developers/docs/consensus-mechanisms/pos/) (PoS)** کا ایک ترمیم شدہ ورژن ہے جو PoS میں اسٹیک پر مبنی میکانزم کے بجائے ایک ساکھ پر مبنی اتفاق رائے کا الگورتھم ہے۔ یہ اصطلاح پہلی بار 2017 میں گیون ووڈ نے متعارف کرائی تھی، اور یہ اتفاق رائے کا الگورتھم زیادہ تر پرائیویٹ چینز، ٹیسٹ نیٹس اور لوکل ڈیولپمنٹ نیٹ ورکس کے ذریعے استعمال کیا جاتا رہا ہے، کیونکہ یہ اعلیٰ معیار کے وسائل کی ضرورت پر قابو پاتا ہے جیسا کہ PoW کرتا ہے، اور بلاک چین کو اسٹور کرنے اور بلاکس تیار کرنے والے نوڈس کا ایک چھوٹا سب سیٹ رکھ کر PoS کے ساتھ اسکیلیبلٹی کے مسائل پر قابو پاتا ہے۔ + +اختیار کا ثبوت مجاز دستخط کنندگان کے ایک سیٹ پر بھروسہ کرنے کا تقاضا کرتا ہے جو [جینیسس بلاک](/glossary/#genesis-block) میں سیٹ کیے گئے ہیں۔ زیادہ تر موجودہ نفاذ میں، تمام مجاز دستخط کنندگان چین کے اتفاق رائے کا تعین کرتے وقت مساوی طاقت اور مراعات برقرار رکھتے ہیں۔ ساکھ کی اسٹیکنگ کے پیچھے خیال یہ ہے کہ ہر مجاز توثیق کار ہر کسی کو اپنے گاہک کو جانیں (KYC) جیسی چیزوں کے ذریعے جانا جاتا ہے، یا واحد توثیق کار ہونے والی ایک معروف تنظیم کا ہونا — اس طرح اگر کوئی توثیق کار کچھ غلط کرتا ہے، تو اس کی شناخت معلوم ہوتی ہے۔ + +PoA کے متعدد نفاذ ہیں، لیکن معیاری ایتھریم نفاذ **clique** ہے، جو [EIP-225](https://eips.ethereum.org/EIPS/eip-225) کو نافذ کرتا ہے۔ Clique ڈیولپر کے لیے دوستانہ اور نافذ کرنے میں آسان معیار ہے، جو تمام کلائنٹ سنکنگ کی اقسام کو سپورٹ کرتا ہے۔ دیگر نفاذ میں [IBFT 2.0](https://besu.hyperledger.org/private-networks/concepts/poa) اور [Aura](https://openethereum.github.io/Chain-specification) شامل ہیں۔ + +## یہ کیسے کام کرتا ہے {#how-it-works} + +PoA میں، نئے بلاکس بنانے کے لیے مجاز دستخط کنندگان کا ایک سیٹ منتخب کیا جاتا ہے۔ دستخط کنندگان کا انتخاب ان کی ساکھ کی بنیاد پر کیا جاتا ہے، اور وہی صرف نئے بلاکس بنانے کے مجاز ہیں۔ دستخط کنندگان کا انتخاب راؤنڈ رابن طریقے سے کیا جاتا ہے، اور ہر دستخط کنندہ کو ایک مخصوص وقت کے فریم میں ایک بلاک بنانے کی اجازت ہوتی ہے۔ بلاک بنانے کا وقت طے ہے، اور دستخط کنندگان کو اس وقت کے فریم کے اندر ایک بلاک بنانا ضروری ہے۔ + +اس تناظر میں ساکھ کوئی مقداری چیز نہیں ہے بلکہ یہ Microsoft اور Google جیسی معروف کارپوریشنوں کی ساکھ ہے، لہذا قابل اعتماد دستخط کنندگان کو منتخب کرنے کا طریقہ الگورتھمک نہیں ہے بلکہ یہ _اعتماد_ کا عام انسانی عمل ہے جہاں ایک ادارہ، مثال کے طور پر Microsoft، سینکڑوں یا ہزاروں اسٹارٹ اپس کے درمیان ایک PoA پرائیویٹ نیٹ ورک بناتا ہے اور خود کو واحد قابل اعتماد دستخط کنندہ کے طور پر پیش کرتا ہے، جس میں مستقبل میں Google جیسے دیگر معروف دستخط کنندگان کو شامل کرنے کا امکان ہوتا ہے۔ اسٹارٹ اپس، بلاشبہ، Microsoft پر ہر وقت ایمانداری سے کام کرنے اور نیٹ ورک کا استعمال کرنے کے لیے بھروسہ کریں گے۔ یہ مختلف چھوٹے/پرائیویٹ نیٹ ورکس میں اسٹیک کرنے کی ضرورت کو حل کرتا ہے جو انہیں غیر مرکزی اور فعال رکھنے کے لیے مختلف مقاصد کے لیے بنائے گئے تھے، اس کے ساتھ ساتھ کان کنوں کی ضرورت بھی، جو بہت زیادہ بجلی اور وسائل استعمال کرتے ہیں۔ کچھ پرائیویٹ نیٹ ورکس PoA معیار کا استعمال کرتے ہیں جیسا کہ VeChain، اور کچھ اس میں ترمیم کرتے ہیں جیسے Binance جو [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) کا استعمال کرتا ہے جو PoA اور PoS کا ایک کسٹم ترمیم شدہ ورژن ہے۔ + +ووٹنگ کا عمل خود دستخط کنندگان کے ذریعے کیا جاتا ہے۔ ہر دستخط کنندہ اپنے بلاک میں ایک دستخط کنندہ کے اضافے یا ہٹانے کے لیے ووٹ دیتا ہے جب وہ ایک نیا بلاک بناتے ہیں۔ ووٹوں کی گنتی نوڈس کے ذریعے کی جاتی ہے، اور دستخط کنندگان کو ایک خاص حد `SIGNER_LIMIT` تک پہنچنے والے ووٹوں کی بنیاد پر شامل یا ہٹا دیا جاتا ہے۔ + +ایسی صورت حال ہو سکتی ہے جہاں چھوٹے فورکس ہوتے ہیں، بلاک کی مشکل اس بات پر منحصر ہے کہ آیا بلاک پر باری کے مطابق دستخط کیے گئے تھے یا باری کے بغیر۔ ”باری کے مطابق“ بلاکس کی مشکل 2 ہوتی ہے، اور ”باری کے بغیر“ بلاکس کی مشکل 1 ہوتی ہے۔ چھوٹے فورکس کی صورت میں، وہ چین جس میں زیادہ تر دستخط کنندگان بلاکس کو ”باری کے مطابق“ سیل کرتے ہیں، سب سے زیادہ مشکل جمع کرے گی اور جیت جائے گی۔ + +## حملے کے ویکٹرز {#attack-vectors} + +### بدنیتی پر مبنی دستخط کنندگان {#malicious-signers} + +ایک بدنیتی پر مبنی صارف کو دستخط کنندگان کی فہرست میں شامل کیا جا سکتا ہے، یا دستخط کرنے والی کلید/مشین سے سمجھوتہ کیا جا سکتا ہے۔ ایسے منظر نامے میں پروٹوکول کو تنظیم نو اور اسپیمنگ کے خلاف اپنا دفاع کرنے کے قابل ہونے کی ضرورت ہے۔ مجوزہ حل یہ ہے کہ N مجاز دستخط کنندگان کی دی گئی فہرست میں، کوئی بھی دستخط کنندہ ہر K میں سے صرف 1 بلاک منٹ کر سکتا ہے۔ یہ یقینی بناتا ہے کہ نقصان محدود ہے، اور باقی توثیق کار بدنیتی پر مبنی صارف کو ووٹ دے کر باہر کر سکتے ہیں۔ + +### سنسرشپ {#censorship-attack} + +ایک اور دلچسپ حملہ ویکٹر یہ ہے کہ اگر کوئی دستخط کنندہ (یا دستخط کنندگان کا گروپ) ان بلاکس کو سنسر کرنے کی کوشش کرتا ہے جو انہیں اجازت کی فہرست سے ہٹانے پر ووٹ دیتے ہیں۔ اس سے بچنے کے لیے، دستخط کنندگان کی اجازت شدہ منٹنگ فریکوئنسی N/2 میں سے 1 تک محدود ہے۔ یہ یقینی بناتا ہے کہ بدنیتی پر مبنی دستخط کنندگان کو کم از کم 51% دستخطی کھاتوں کو کنٹرول کرنے کی ضرورت ہے، جس مقام پر وہ مؤثر طریقے سے چین کے لیے سچائی کا نیا ذریعہ بن جائیں گے۔ + +### اسپیم {#spam-attack} + +ایک اور چھوٹا حملہ ویکٹر بدنیتی پر مبنی دستخط کنندگان ہیں جو ہر اس بلاک کے اندر نئی ووٹ تجاویز داخل کرتے ہیں جو وہ منٹ کرتے ہیں۔ چونکہ نوڈس کو مجاز دستخط کنندگان کی اصل فہرست بنانے کے لیے تمام ووٹوں کی گنتی کرنے کی ضرورت ہے، اس لیے انہیں وقت کے ساتھ تمام ووٹوں کو ریکارڈ کرنا ہوگا۔ ووٹ ونڈو پر حد لگائے بغیر، یہ آہستہ آہستہ، پھر بھی لامحدود طور پر بڑھ سکتا ہے۔ حل یہ ہے کہ W بلاکس کی ایک _حرکت پذیر_ ونڈو رکھی جائے جس کے بعد ووٹوں کو باسی سمجھا جاتا ہے۔ _ایک معقول ونڈو 1-2 ایپوکس ہو سکتی ہے۔_ + +### ہم آہنگ بلاکس {#concurrent-blocks} + +ایک PoA نیٹ ورک میں، جب N مجاز دستخط کنندگان ہوتے ہیں، تو ہر دستخط کنندہ کو K میں سے 1 بلاک منٹ کرنے کی اجازت ہوتی ہے، جس کا مطلب ہے کہ N-K+1 توثیق کاروں کو کسی بھی وقت منٹ کرنے کی اجازت ہے۔ ان توثیق کاروں کو بلاکس کے لیے دوڑنے سے روکنے کے لیے، ہر دستخط کنندہ کو ایک نیا بلاک جاری کرنے کے وقت میں ایک چھوٹا بے ترتیب "آفسیٹ" شامل کرنا چاہیے۔ اگرچہ یہ عمل یقینی بناتا ہے کہ چھوٹے فورکس نایاب ہیں، کبھی کبھار فورکس اب بھی ہو سکتے ہیں، بالکل مین نیٹ کی طرح۔ اگر کوئی دستخط کنندہ اپنی طاقت کا غلط استعمال کرتا اور افراتفری کا باعث بنتا پایا جاتا ہے، تو دوسرے دستخط کنندگان اسے ووٹ دے کر باہر کر سکتے ہیں۔ + +مثال کے طور پر اگر 10 مجاز دستخط کنندگان ہیں اور ہر دستخط کنندہ کو 20 میں سے 1 بلاک بنانے کی اجازت ہے، تو کسی بھی وقت، 11 توثیق کار بلاکس بنا سکتے ہیں۔ انہیں بلاکس بنانے کی دوڑ سے روکنے کے لیے، ہر دستخط کنندہ اپنے نئے بلاک کو جاری کرنے کے وقت میں ایک چھوٹا بے ترتیب "آفسیٹ" شامل کرتا ہے۔ یہ چھوٹے فورکس کے واقعات کو کم کرتا ہے لیکن پھر بھی کبھی کبھار فورکس کی اجازت دیتا ہے، جیسا کہ ایتھریم مین نیٹ پر دیکھا گیا ہے۔ اگر کوئی دستخط کنندہ اپنے اختیار کا غلط استعمال کرتا ہے اور خلل پیدا کرتا ہے، تو اسے نیٹ ورک سے ووٹ دے کر باہر کیا جا سکتا ہے۔ + +## فائدے اور نقصانات {#pros-and-cons} + +| فوائد | نقصانات | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | +| PoS اور PoW جیسے دیگر مقبول میکانزم سے زیادہ اسکیل ایبل، کیونکہ یہ بلاک دستخط کنندگان کی ایک محدود تعداد پر مبنی ہے۔ | PoA نیٹ ورکس میں عام طور پر توثیق کرنے والے نوڈس کی نسبتاً کم تعداد ہوتی ہے۔ یہ ایک PoA نیٹ ورک کو زیادہ مرکزی بناتا ہے۔ | +| PoA بلاک چینز چلانے اور برقرار رکھنے میں ناقابل یقین حد تک سستے ہیں۔ | ایک مجاز دستخط کنندہ بننا عام طور پر ایک عام شخص کی پہنچ سے باہر ہے، کیونکہ بلاک چین کو قائم شدہ ساکھ والی اداروں کی ضرورت ہوتی ہے۔ | +| لین دین کی تصدیق بہت تیزی سے ہوتی ہے کیونکہ یہ 1 سیکنڈ سے بھی کم وقت میں ہو سکتی ہے کیونکہ نئے بلاکس کی توثیق کے لیے صرف محدود تعداد میں دستخط کنندگان کی ضرورت ہوتی ہے۔ | بدنیتی پر مبنی دستخط کنندگان نیٹ ورک میں ری آرگ، ڈبل اسپینڈ، سنسر ٹرانزیکشنز کر سکتے ہیں، ان حملوں کو کم کیا جاتا ہے لیکن پھر بھی ممکن ہیں۔ | + +## مزید پڑھیں {#further-reading} + +- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique معیار_ +- [اختیار کا ثبوت مطالعہ](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_ +- [اختیار کا ثبوت کیا ہے](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_ +- [اختیار کے ثبوت کی وضاحت](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_ +- [بلاک چین میں PoA](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba) +- [Clique کی وضاحت](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d) +- [متروک PoA، Aura تفصیلات](https://openethereum.github.io/Chain-specification) +- [IBFT 2.0، ایک اور PoA نفاذ](https://besu.hyperledger.org/private-networks/concepts/poa) + +### کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + +اختیار کے ثبوت کی بصری وضاحت دیکھیں: + + + +## متعلقہ موضوعات {#related-topics} + +- [ثبوتِ کار (Proof-of-work)](/developers/docs/consensus-mechanisms/pow/) +- [ثبوتِ حصص (Proof-of-stake)](/developers/docs/consensus-mechanisms/pos/) + diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md new file mode 100644 index 00000000000..407a415582a --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -0,0 +1,166 @@ +--- +title: "Ethereum پروف-آف-اسٹیک حملہ اور دفاع" +description: "پروف-آف-اسٹیک Ethereum پر معلوم حملہ آور ویکٹرز کے بارے میں جانیں اور ان کا دفاع کیسے کیا جاتا ہے۔" +lang: ur-in +--- + +چور اور تخریب کار مسلسل Ethereum کے کلائنٹ سافٹ ویئر پر حملہ کرنے کے مواقع کی تلاش میں رہتے ہیں۔ یہ صفحہ Ethereum کی اتفاق رائے کی پرت (Consensus Layer) پر معلوم حملہ آور ویکٹرز کا خاکہ پیش کرتا ہے اور یہ بتاتا ہے کہ ان حملوں کا دفاع کیسے کیا جا سکتا ہے۔ اس صفحے پر دی گئی معلومات ایک [طویل شکل کے ورژن](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) سے اخذ کی گئی ہے۔ + +## شرائط {#prerequisites} + +[پروف-آف-اسٹیک](/developers/docs/consensus-mechanisms/pos/) کا کچھ بنیادی علم درکار ہے۔ اس کے علاوہ، Ethereum کی [ترغیبی پرت](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) اور فورک-چوائس الگورتھم، [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) کا بنیادی فہم حاصل کرنا مددگار ثابت ہوگا۔ + +## حملہ آور کیا چاہتے ہیں؟ {#what-do-attackers-want} + +ایک عام غلط فہمی یہ ہے کہ ایک کامیاب حملہ آور نیا ایتھر (ether) پیدا کر سکتا ہے، یا من مانے اکاؤنٹس سے ایتھر نکال سکتا ہے۔ ان میں سے کوئی بھی ممکن نہیں ہے کیونکہ تمام ٹرانزیکشنز پر نیٹ ورک پر موجود تمام ایگزیکیوشن کلائنٹس کے ذریعے عمل درآمد ہوتا ہے۔ انہیں جواز کی بنیادی شرائط کو پورا کرنا ہوگا (مثال کے طور پر، ٹرانزیکشنز پر بھیجنے والے کی پرائیویٹ کلید سے دستخط ہوں، بھیجنے والے کے پاس کافی بیلنس ہو، وغیرہ) ورنہ وہ بس ریورٹ ہو جاتی ہیں۔ نتائج کی تین قسمیں ہیں جنہیں ایک حملہ آور حقیقت پسندانہ طور پر نشانہ بنا سکتا ہے: ریورگس (reorgs)، ڈبل فائنیلیٹی (double finality) یا فائنیلیٹی میں تاخیر (finality delay)۔ + +ایک **“ریورگ”** بلاکس کی ایک نئی ترتیب میں دوبارہ ترتیب ہے، شاید کینونیکل چین میں کچھ بلاکس کے اضافے یا گھٹاؤ کے ساتھ۔ ایک بدنیتی پر مبنی ریورگ مخصوص بلاکس کو شامل یا خارج کرنا یقینی بنا سکتا ہے، جس سے فرنٹ رننگ اور بیک رننگ ٹرانزیکشنز (MEV) کے ذریعے ڈبل اسپینڈنگ یا ویلیو ایکسٹریکشن کی اجازت ملتی ہے۔ ریورگس کا استعمال کچھ ٹرانزیکشنز کو کینونیکل چین میں شامل ہونے سے روکنے کے لیے بھی کیا جا سکتا ہے - جو سنسرشپ کی ایک شکل ہے۔ ریورگ کی سب سے شدید شکل 'فائنیلیٹی ریورژن' ہے جو ان بلاکس کو ہٹا دیتی ہے یا بدل دیتی ہے جنہیں پہلے ہی حتمی شکل دی جا چکی ہے۔ یہ صرف تبھی ممکن ہے جب کل اسٹیک شدہ ایتھر کا ⅓ سے زیادہ حملہ آور کے ذریعہ تباہ کر دیا جائے - اس گارنٹی کو 'اقتصادی فائنیلیٹی' کے نام سے جانا جاتا ہے - اس پر بعد میں مزید بات ہوگی۔ + +**ڈبل فائنیلیٹی** ایک غیر متوقع لیکن سنگین حالت ہے جہاں دو فورکس ایک ساتھ حتمی شکل دینے کے قابل ہوتے ہیں، جس سے چین میں ایک مستقل تقسیم پیدا ہو جاتی ہے۔ یہ نظریاتی طور پر ایک ایسے حملہ آور کے لیے ممکن ہے جو کل اسٹیک شدہ ایتھر کا 34% داؤ پر لگانے کو تیار ہو۔ کمیونٹی کو آف چین تال میل کرنے پر مجبور کیا جائے گا اور اس بات پر متفق ہونا پڑے گا کہ کس چین کی پیروی کرنی ہے، جس کے لیے سماجی پرت میں مضبوطی کی ضرورت ہوگی۔ + +ایک **فائنیلیٹی تاخیر** کا حملہ نیٹ ورک کو چین کے حصوں کو حتمی شکل دینے کے لیے ضروری شرائط تک پہنچنے سے روکتا ہے۔ فائنیلیٹی کے بغیر، Ethereum پر بنائے گئے مالیاتی ایپلیکیشنز پر بھروسہ کرنا مشکل ہے۔ فائنیلیٹی تاخیر کے حملے کا مقصد ممکنہ طور پر براہ راست منافع کمانے کے بجائے محض Ethereum میں خلل ڈالنا ہے، جب تک کہ حملہ آور کے پاس کچھ اسٹریٹجک شارٹ پوزیشن (پوزیشنیں) نہ ہوں۔ + +سماجی پرت پر حملے کا مقصد Ethereum میں عوامی اعتماد کو کمزور کرنا، ایتھر کی قدر میں کمی کرنا، اپنانے کو کم کرنا یا Ethereum کمیونٹی کو کمزور کرنا ہو سکتا ہے تاکہ آؤٹ آف بینڈ کوآرڈینیشن کو مزید مشکل بنایا جا سکے۔ + +یہ قائم کرنے کے بعد کہ کوئی مخالف Ethereum پر کیوں حملہ کر سکتا ہے، مندرجہ ذیل حصے اس بات کا جائزہ لیتے ہیں کہ وہ اس کے بارے میں _کیسے_ کام کر سکتے ہیں۔ + +## حملے کے طریقے {#methods-of-attack} + +### پرت 0 کے حملے {#layer-0} + +سب سے پہلے، وہ افراد جو Ethereum میں فعال طور پر حصہ نہیں لے رہے ہیں (کلائنٹ سافٹ ویئر چلا کر) سماجی پرت (پرت 0) کو نشانہ بنا کر حملہ کر سکتے ہیں۔ پرت 0 وہ بنیاد ہے جس پر Ethereum بنایا گیا ہے، اور اس طرح یہ حملوں کے لیے ایک ممکنہ سطح کی نمائندگی کرتا ہے جس کے نتائج باقی اسٹیک کے ذریعے پھیلتے ہیں۔ کچھ مثالیں شامل ہو سکتی ہیں: + +- ایک غلط معلومات کی مہم کمیونٹی کے Ethereum کے روڈ میپ، ڈویلپرز کی ٹیموں، ایپس وغیرہ پر اعتماد کو ختم کر سکتی ہے۔ اس سے پھر نیٹ ورک کو محفوظ بنانے میں حصہ لینے کے خواہشمند افراد کی تعداد میں کمی آسکتی ہے، جس سے وکندریقرت اور کرپٹو-اقتصادی سیکیورٹی دونوں میں کمی آئے گی۔ + +- ڈویلپر کمیونٹی کے خلاف ہدفی حملے اور/یا دھمکیاں۔ اس سے ڈویلپرز کا رضاکارانہ اخراج ہو سکتا ہے اور Ethereum کی پیشرفت سست ہو سکتی ہے۔ + +- ضرورت سے زیادہ ضابطے کو بھی پرت 0 پر حملہ سمجھا جا سکتا ہے، کیونکہ یہ شرکت اور اپنانے کی تیزی سے حوصلہ شکنی کر سکتا ہے۔ + +- ڈویلپر کمیونٹی میں باخبر لیکن بدنیتی پر مبنی کرداروں کی دراندازی جن کا مقصد بائیک شیڈنگ مباحثوں کے ذریعے پیشرفت کو سست کرنا، کلیدی فیصلوں میں تاخیر کرنا، اسپام بنانا وغیرہ ہے۔ + +- فیصلہ سازی پر اثر انداز ہونے کے لیے Ethereum ایکو سسٹم میں کلیدی کھلاڑیوں کو دی جانے والی رشوت۔ + +جو چیز ان حملوں کو خاص طور پر خطرناک بناتی ہے وہ یہ ہے کہ بہت سے معاملات میں بہت کم سرمائے یا تکنیکی معلومات کی ضرورت ہوتی ہے۔ پرت 0 کا حملہ کرپٹو-اقتصادی حملے پر ایک ضرب ثابت ہو سکتا ہے۔ مثال کے طور پر، اگر سنسرشپ یا فائنیلیٹی ریورژن ایک بدنیتی پر مبنی اکثریتی اسٹیک ہولڈر کے ذریعہ حاصل کیا جاتا ہے، تو سماجی پرت کو کمزور کرنا ایک کمیونٹی ردعمل کو آؤٹ آف بینڈ میں مربوط کرنا مزید مشکل بنا سکتا ہے۔ + +پرت 0 کے حملوں سے دفاع کرنا شاید سیدھا نہیں ہے، لیکن کچھ بنیادی اصول قائم کیے جا سکتے ہیں۔ ایک یہ ہے کہ Ethereum کے بارے میں عوامی معلومات کے لیے مجموعی طور پر اعلی سگنل سے شور کا تناسب برقرار رکھا جائے، جو کمیونٹی کے ایماندار ممبروں کے ذریعے بلاگز، ڈسکارڈ سرورز، تشریح شدہ چشمیوں، کتابوں، پوڈ کاسٹس اور یوٹیوب کے ذریعے تخلیق اور پھیلایا جائے۔ یہاں ethereum.org پر ہم درست معلومات کو برقرار رکھنے اور اسے زیادہ سے زیادہ زبانوں میں ترجمہ کرنے کی بھرپور کوشش کرتے ہیں۔ اعلی معیار کی معلومات اور میمز کے ساتھ ایک جگہ کو بھرنا غلط معلومات کے خلاف ایک موثر دفاع ہے۔ + +سماجی پرت کے حملوں کے خلاف ایک اور اہم قلعہ بندی ایک واضح مشن کا بیان اور گورننس پروٹوکول ہے۔ Ethereum نے خود کو اسمارٹ-کنٹریکٹ پرت 1 کے درمیان وکندریقرت اور سیکیورٹی چیمپیئن کے طور پر پوزیشن دی ہے، جبکہ اسکیل ایبلٹی اور پائیداری کو بھی بہت اہمیت دی ہے۔ Ethereum کمیونٹی میں جو بھی اختلافات پیدا ہوتے ہیں، ان بنیادی اصولوں سے کم سے کم سمجھوتہ کیا جاتا ہے۔ ان بنیادی اصولوں کے خلاف ایک بیانیے کا جائزہ لینا، اور EIP (Ethereum امپروومنٹ پروپوزل) کے عمل میں نظرثانی کے لگاتار دوروں کے ذریعے ان کا جائزہ لینا، کمیونٹی کو اچھے اور برے کرداروں میں فرق کرنے میں مدد کر سکتا ہے اور بدنیتی پر مبنی کرداروں کے لیے Ethereum کی مستقبل کی سمت کو متاثر کرنے کے دائرہ کار کو محدود کرتا ہے۔ + +آخر میں، یہ اہم ہے کہ Ethereum کمیونٹی تمام شرکاء کے لیے کھلی اور خوش آئند رہے۔ گیٹ کیپرز اور خصوصیت والی کمیونٹی سماجی حملے کے لیے خاص طور پر کمزور ہے کیونکہ 'ہم اور وہ' کے بیانیے بنانا آسان ہے۔ قبائلیت اور زہریلا زیادہ سے زیادہ پن کمیونٹی کو نقصان پہنچاتا ہے اور پرت 0 کی سیکیورٹی کو ختم کرتا ہے۔ نیٹ ورک کی سیکیورٹی میں دلچسپی رکھنے والے Ethereans کو آن لائن اور میٹ اسپیس میں اپنے طرز عمل کو Ethereum کی پرت 0 کی سیکیورٹی میں براہ راست شراکت دار کے طور پر دیکھنا چاہیے۔ + +### پروٹوکول پر حملہ {#attacking-the-protocol} + +کوئی بھی Ethereum کا کلائنٹ سافٹ ویئر چلا سکتا ہے۔ کلائنٹ میں ایک ویلیڈیٹر شامل کرنے کے لیے، صارف کو ڈپازٹ کنٹریکٹ میں 32 ایتھر اسٹیک کرنا ہوتا ہے۔ ایک ویلیڈیٹر صارف کو نئے بلاکس کی تجویز اور تصدیق کرکے Ethereum کے نیٹ ورک سیکیورٹی میں فعال طور پر حصہ لینے کی اجازت دیتا ہے۔ ویلیڈیٹر کے پاس اب ایک آواز ہے جس کا استعمال وہ بلاک چین کے مستقبل کے مواد کو متاثر کرنے کے لیے کر سکتے ہیں - وہ ایمانداری سے ایسا کر سکتے ہیں اور انعامات کے ذریعے اپنے ایتھر کے ذخیرے کو بڑھا سکتے ہیں یا وہ اپنے فائدے کے لیے عمل میں ہیرا پھیری کرنے کی کوشش کر سکتے ہیں، اپنے اسٹیک کو خطرے میں ڈال کر۔ حملہ کرنے کا ایک طریقہ یہ ہے کہ کل اسٹیک کا ایک بڑا تناسب جمع کیا جائے اور پھر اسے ایماندار ویلیڈیٹرز کو آؤٹ ووٹ کرنے کے لیے استعمال کیا جائے۔ حملہ آور کے زیر کنٹرول اسٹیک کا تناسب جتنا زیادہ ہوگا، ان کی ووٹنگ کی طاقت اتنی ہی زیادہ ہوگی، خاص طور پر کچھ اقتصادی سنگ میلوں پر جن کا ہم بعد میں جائزہ لیں گے۔ تاہم، زیادہ تر حملہ آور اس طرح حملہ کرنے کے لیے کافی ایتھر جمع نہیں کر پائیں گے، اس لیے اس کے بجائے انہیں ایماندار اکثریت کو ایک خاص طریقے سے کام کرنے کے لیے جوڑ توڑ کرنے کے لیے لطیف تکنیکوں کا استعمال کرنا ہوگا۔ + +بنیادی طور پر، تمام چھوٹے اسٹیک کے حملے ویلیڈیٹر کے دو قسم کے غلط برتاؤ پر لطیف تغیرات ہیں: کم سرگرمی (تصدیق/تجویز کرنے میں ناکامی یا دیر سے ایسا کرنا) یا زیادہ سرگرمی (ایک سلاٹ میں بہت زیادہ بار تجویز/تصدیق کرنا)۔ ان کی سب سے زیادہ ونیلا شکلوں میں ان کارروائیوں کو فورک-چوائس الگورتھم اور ترغیبی پرت کے ذریعے آسانی سے سنبھال لیا جاتا ہے، لیکن سسٹم کو حملہ آور کے فائدے کے لیے گیم کرنے کے ہوشیار طریقے ہیں۔ + +### ETH کی چھوٹی مقدار کا استعمال کرتے ہوئے حملے {#attacks-by-small-stakeholders} + +#### ریورگس {#reorgs} + +کئی مقالوں نے Ethereum پر حملوں کی وضاحت کی ہے جو کل اسٹیک شدہ ایتھر کے صرف ایک چھوٹے سے تناسب کے ساتھ ریورگس یا فائنیلیٹی میں تاخیر حاصل کرتے ہیں۔ یہ حملے عام طور پر حملہ آور پر انحصار کرتے ہیں جو دوسرے ویلیڈیٹرز سے کچھ معلومات روکتا ہے اور پھر اسے کسی نہ کسی طرح سے اور/یا کسی مناسب لمحے پر جاری کرتا ہے۔ وہ عام طور پر کینونیکل چین سے کچھ ایماندار بلاک (بلاکس) کو ہٹانے کا مقصد رکھتے ہیں۔ [نیوڈر ایٹ ال 2020](https://arxiv.org/pdf/2102.02247.pdf) نے دکھایا کہ کس طرح ایک حملہ آور ویلیڈیٹر ایک خاص سلاٹ n+1 کے لیے ایک بلاک (`B`) بنا اور تصدیق کر سکتا ہے لیکن اسے نیٹ ورک پر دوسرے نوڈس میں پھیلانے سے باز رہتا ہے۔ اس کے بجائے، وہ اس تصدیق شدہ بلاک کو اگلے سلاٹ n+2 تک روکے رکھتے ہیں۔ ایک ایماندار ویلیڈیٹر سلاٹ n+2 کے لیے ایک بلاک (`C`) تجویز کرتا ہے۔ تقریباً ایک ساتھ، حملہ آور اپنے روکے ہوئے بلاک (`B`) اور اس کے لیے اپنی روکی ہوئی تصدیقوں کو جاری کر سکتا ہے، اور سلاٹ n+2 کے لیے اپنے ووٹوں کے ساتھ چین کے سربراہ ہونے کی بھی تصدیق کر سکتا ہے، جس سے ایماندار بلاک `C` کے وجود سے مؤثر طریقے سے انکار کیا جا سکتا ہے۔ جب ایماندار بلاک `D` جاری ہوتا ہے، تو فورک چوائس الگورتھم `B` کے اوپر `D` کی تعمیر کو `C` پر `D` کی تعمیر سے زیادہ بھاری دیکھتا ہے۔ اس لیے حملہ آور نے 1-بلاک سابقہ ریورگ کا استعمال کرتے ہوئے کینونیکل چین سے سلاٹ n+2 میں ایماندار بلاک `C` کو ہٹانے میں کامیابی حاصل کی ہے۔ [ایک حملہ آور جس کے پاس 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) اسٹیک ہے، اس حملے میں کامیاب ہونے کا بہت اچھا موقع ہے، جیسا کہ [اس نوٹ میں](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) وضاحت کی گئی ہے۔ تاہم، نظریاتی طور پر، یہ حملہ چھوٹے اسٹیک کے ساتھ بھی کیا جا سکتا ہے۔ [نیوڈر ایٹ ال 2020](https://arxiv.org/pdf/2102.02247.pdf) نے اس حملے کو 30% اسٹیک کے ساتھ کام کرنے کے طور پر بیان کیا، لیکن بعد میں یہ [کل اسٹیک کے 2%](https://arxiv.org/pdf/2009.04987.pdf) کے ساتھ اور پھر [ایک واحد ویلیڈیٹر](https://arxiv.org/abs/2110.10086#) کے لیے بیلنسنگ تکنیک کا استعمال کرتے ہوئے قابل عمل دکھایا گیا جس کا ہم اگلے حصے میں جائزہ لیں گے۔ + +![ex-ante re-org](reorg-schematic.png) + +اوپر بیان کردہ ون-بلاک ریورگ حملے کا ایک تصوراتی خاکہ (https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair سے اخذ کیا گیا) + +ایک زیادہ نفیس حملہ ایماندار ویلیڈیٹر سیٹ کو الگ الگ گروہوں میں تقسیم کر سکتا ہے جن کے چین کے سربراہ کے بارے میں مختلف خیالات ہوتے ہیں۔ اسے **بیلنسنگ اٹیک** کے نام سے جانا جاتا ہے۔ حملہ آور ایک بلاک تجویز کرنے کے اپنے موقع کا انتظار کرتا ہے، اور جب یہ آتا ہے تو وہ مساوات کرتا ہے اور دو تجویز کرتا ہے۔ وہ ایک بلاک ایماندار ویلیڈیٹر سیٹ کے آدھے حصے کو بھیجتے ہیں اور دوسرا بلاک دوسرے آدھے حصے کو۔ فورک-چوائس الگورتھم کے ذریعہ مساوات کا پتہ لگایا جائے گا اور بلاک پروپوزر کو سلیش کر کے نیٹ ورک سے نکال دیا جائے گا، لیکن دونوں بلاکس اب بھی موجود ہوں گے اور ہر فورک کی تصدیق کرنے والے تقریبا آدھے ویلیڈیٹر سیٹ ہوں گے۔ دریں اثنا، باقی بدنیتی پر مبنی ویلیڈیٹرز اپنی تصدیقیں روک لیتے ہیں۔ پھر، ایک یا دوسرے فورک کے حق میں تصدیقوں کو منتخب طور پر صرف اتنے ویلیڈیٹرز کو جاری کرکے جیسے ہی فورک-چوائس الگورتھم عمل میں آتا ہے، وہ ایک یا دوسرے فورک کے حق میں تصدیقوں کے جمع شدہ وزن کو جھکا دیتے ہیں۔ یہ غیر معینہ مدت تک جاری رہ سکتا ہے، جس میں حملہ آور ویلیڈیٹرز دونوں فورکس پر ویلیڈیٹرز کی یکساں تقسیم برقرار رکھتے ہیں۔ چونکہ کوئی بھی فورک 2/3 کی سپر میجورٹی کو اپنی طرف متوجہ نہیں کر سکتا، اس لیے نیٹ ورک حتمی شکل نہیں دے گا۔ + +**باؤنسنگ حملے** بھی اسی طرح کے ہیں۔ ووٹ پھر سے حملہ آور ویلیڈیٹرز کے ذریعے روکے جاتے ہیں۔ دو فورکس کے درمیان یکساں تقسیم رکھنے کے لیے ووٹ جاری کرنے کے بجائے، وہ اپنے ووٹوں کا استعمال مناسب لمحات میں ان چیک پوائنٹس کو جواز فراہم کرنے کے لیے کرتے ہیں جو فورک A اور فورک B کے درمیان باری باری آتے ہیں۔ دو فورکس کے درمیان جواز کا یہ الٹ پھیر کسی بھی چین پر حتمی شکل دی جا سکنے والے جائز سورس اور ٹارگٹ چیک پوائنٹس کے جوڑوں کو بننے سے روکتا ہے، جس سے فائنیلیٹی رک جاتی ہے۔ + + + +باؤنسنگ اور بیلنسنگ دونوں حملے حملہ آور پر انحصار کرتے ہیں کہ وہ نیٹ ورک پر پیغام کے وقت پر بہت عمدہ کنٹرول رکھتا ہے، جو کہ غیر امکانی ہے۔ بہر حال، سست پیغامات کے مقابلے میں فوری پیغامات کو دیے جانے والے اضافی وزن کی شکل میں دفاع پروٹوکول میں بنائے گئے ہیں۔ اسے [پرپوزر-ویٹ بوسٹنگ](https://github.com/ethereum/consensus-specs/pull/2730) کے نام سے جانا جاتا ہے۔ باؤنسنگ حملوں سے دفاع کے لیے فورک-چوائس الگورتھم کو اپ ڈیٹ کیا گیا تھا تاکہ تازہ ترین جائز چیک پوائنٹ صرف [ہر عہد کے پہلے 1/3 سلاٹس میں](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) ایک متبادل چین کے چیک پوائنٹ پر سوئچ کر سکے۔ یہ شرط حملہ آور کو بعد میں تعینات کرنے کے لیے ووٹ بچانے سے روکتی ہے - فورک چوائس الگورتھم بس اس چیک پوائنٹ کے لیے وفادار رہتا ہے جسے اس نے عہد کے پہلے 1/3 کے دوران منتخب کیا تھا جس دوران زیادہ تر ایماندار ویلیڈیٹرز نے ووٹ دیا ہوگا۔ + +مجموعی طور پر، یہ اقدامات ایک ایسا منظر نامہ بناتے ہیں جس میں ایک ایماندار بلاک پروپوزر سلاٹ کے آغاز کے فوراً بعد اپنا بلاک خارج کرتا ہے، پھر ~1/3 سلاٹ (4 سیکنڈ) کا ایک دورانیہ ہوتا ہے جہاں وہ نیا بلاک فورک-چوائس الگورتھم کو کسی دوسری چین پر سوئچ کرنے کا سبب بن سکتا ہے۔ اسی ڈیڈ لائن کے بعد، سست ویلیڈیٹرز سے آنے والی تصدیقوں کا وزن ان کے مقابلے میں کم کر دیا جاتا ہے جو پہلے پہنچی تھیں۔ یہ چین کے سربراہ کا تعین کرنے میں فوری پروپوزرز اور ویلیڈیٹرز کی بھرپور حمایت کرتا ہے اور کامیاب بیلنسنگ یا باؤنسنگ حملے کے امکان کو کافی حد تک کم کرتا ہے۔ + +یہ بات قابل ذکر ہے، کہ پرپوزر بوسٹنگ اکیلے صرف 'سستے ریورگس' سے دفاع کرتا ہے، یعنی، وہ جو ایک چھوٹے اسٹیک والے حملہ آور کے ذریعہ کیے جاتے ہیں۔ درحقیقت، پرپوزر-بوسٹنگ کو خود بڑے اسٹیک ہولڈرز کے ذریعے گیم کیا جا سکتا ہے۔ [اس پوسٹ](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) کے مصنفین بیان کرتے ہیں کہ کس طرح 7% اسٹیک والا حملہ آور ایماندار ویلیڈیٹرز کو اپنے فورک پر تعمیر کرنے کے لیے دھوکہ دینے کے لیے اپنے ووٹوں کو حکمت عملی کے ساتھ تعینات کر سکتا ہے، جس سے ایک ایماندار بلاک کو ریورگ کیا جا سکتا ہے۔ یہ حملہ مثالی لیٹنسی شرائط کو فرض کرتے ہوئے وضع کیا گیا تھا جو بہت غیر امکانی ہیں۔ حملہ آور کے لیے مشکلات اب بھی بہت لمبی ہیں، اور زیادہ اسٹیک کا مطلب بھی زیادہ سرمایہ خطرے میں اور ایک مضبوط اقتصادی حوصلہ شکنی ہے۔ + +ایک [بیلنسنگ اٹیک جو خاص طور پر LMD اصول کو نشانہ بناتا ہے](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) بھی تجویز کیا گیا تھا، جس کے بارے میں تجویز کیا گیا تھا کہ وہ پرپوزر بوسٹنگ کے باوجود قابل عمل ہے۔ ایک حملہ آور اپنی بلاک تجویز کو مساوی بنا کر دو مسابقتی چینز قائم کرتا ہے اور ہر بلاک کو تقریبا آدھے نیٹ ورک تک پھیلاتا ہے، جس سے فورکس کے درمیان ایک تخمینی توازن قائم ہوتا ہے۔ پھر، سازشی ویلیڈیٹرز اپنے ووٹوں کو مساوی بناتے ہیں، اس کا وقت اس طرح لگاتے ہیں کہ آدھا نیٹ ورک فورک `A` کے لیے اپنے ووٹ پہلے وصول کرتا ہے اور دوسرا آدھا فورک `B` کے لیے اپنے ووٹ پہلے وصول کرتا ہے۔ چونکہ LMD اصول دوسری تصدیق کو مسترد کرتا ہے اور ہر ویلیڈیٹر کے لیے صرف پہلی کو رکھتا ہے، آدھا نیٹ ورک `A` کے لیے ووٹ دیکھتا ہے اور `B` کے لیے کوئی نہیں، دوسرا آدھا `B` کے لیے ووٹ دیکھتا ہے اور `A` کے لیے کوئی نہیں۔ مصنفین LMD اصول کو بیان کرتے ہیں جو مخالف کو بیلنسنگ اٹیک کرنے کے لیے 'غیر معمولی طاقت' دیتا ہے۔ + +اس LMD حملہ ویکٹر کو [فورک چوائس الگورتھم کو اپ ڈیٹ کرکے](https://github.com/ethereum/consensus-specs/pull/2845) بند کر دیا گیا تھا تاکہ یہ مساوی ویلیڈیٹرز کو فورک چوائس پر غور سے مکمل طور پر خارج کر دے۔ مساوی ویلیڈیٹرز کے مستقبل کے اثر و رسوخ کو بھی فورک چوائس الگورتھم کے ذریعے رعایت دی جاتی ہے۔ یہ اوپر بیان کردہ بیلنسنگ اٹیک کو روکتا ہے جبکہ برفانی تودے کے حملوں کے خلاف لچک کو بھی برقرار رکھتا ہے۔ + +حملے کی ایک اور قسم، جسے [**ایولانچ اٹیکس**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3) کہا جاتا ہے، [مارچ 2022 کے ایک مقالے](https://arxiv.org/pdf/2203.01315.pdf) میں بیان کی گئی تھی۔ ایولانچ اٹیک کرنے کے لیے، حملہ آور کو لگاتار کئی بلاک پروپوزرز کو کنٹرول کرنے کی ضرورت ہوتی ہے۔ بلاک پروپوزل سلاٹس میں سے ہر ایک میں، حملہ آور اپنے بلاک کو روکتا ہے، انہیں اس وقت تک جمع کرتا رہتا ہے جب تک کہ ایماندار چین روکے ہوئے بلاکس کے ساتھ مساوی سب ٹری وزن تک نہ پہنچ جائے۔ پھر، روکے ہوئے بلاکس کو جاری کیا جاتا ہے تاکہ وہ زیادہ سے زیادہ مساوی ہوں۔ مصنفین کا مشورہ ہے کہ پرپوزر بوسٹنگ - بیلنسنگ اور باؤنسنگ حملوں کے خلاف بنیادی دفاع - ایولانچ اٹیک کی کچھ اقسام سے حفاظت نہیں کرتا ہے۔ تاہم، مصنفین نے بھی صرف Ethereum کے فورک-چوائس الگورتھم کے ایک انتہائی مثالی ورژن پر حملے کا مظاہرہ کیا (انہوں نے LMD کے بغیر GHOST کا استعمال کیا)۔ + +ایولانچ اٹیک کو LMD-GHOST فورک چوائس الگورتھم کے LMD حصے کے ذریعے کم کیا جاتا ہے۔ LMD کا مطلب 'تازہ ترین پیغام سے چلنے والا' ہے اور یہ ہر ویلیڈیٹر کے پاس موجود ایک ٹیبل کا حوالہ دیتا ہے جس میں دوسرے ویلیڈیٹرز سے موصول ہونے والا تازہ ترین پیغام ہوتا ہے۔ اس فیلڈ کو صرف اس صورت میں اپ ڈیٹ کیا جاتا ہے جب نیا پیغام کسی خاص ویلیڈیٹر کے لیے ٹیبل میں پہلے سے موجود سلاٹ سے بعد کے سلاٹ سے ہو۔ عملی طور پر، اس کا مطلب ہے کہ ہر سلاٹ میں، موصول ہونے والا پہلا پیغام وہ ہوتا ہے جسے قبول کیا جاتا ہے اور کوئی بھی اضافی پیغام نظر انداز کیے جانے والے مساوات ہوتے ہیں۔ دوسرے لفظوں میں، اتفاق رائے کلائنٹس مساوات کو شمار نہیں کرتے ہیں - وہ ہر ویلیڈیٹر سے پہلے پہنچنے والے پیغام کا استعمال کرتے ہیں اور مساوات کو صرف مسترد کر دیا جاتا ہے، جس سے ایولانچ حملوں کو روکا جاتا ہے۔ + +فورک چوائس اصول میں کئی دیگر ممکنہ مستقبل کی اپ گریڈ ہیں جو پرپوزر-بوسٹ کے ذریعہ فراہم کردہ سیکیورٹی میں اضافہ کر سکتی ہیں۔ ایک ہے [ویو-مرج](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)، جہاں تصدیق کرنے والے ایک سلاٹ کے آغاز سے `n` سیکنڈ پہلے فورک چوائس کے اپنے نظریہ کو منجمد کر دیتے ہیں اور پروپوزر پھر نیٹ ورک پر چین کے نظریہ کو ہم آہنگ کرنے میں مدد کرتا ہے۔ ایک اور ممکنہ اپ گریڈ [سنگل-سلاٹ فائنیلیٹی](https://notes.ethereum.org/@vbuterin/single_slot_finality) ہے، جو صرف ایک سلاٹ کے بعد چین کو حتمی شکل دے کر پیغام کے وقت پر مبنی حملوں سے بچاتی ہے۔ + +#### فائنیلیٹی تاخیر {#finality-delay} + +[وہی مقالہ](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) جس نے پہلی بار کم لاگت والے سنگل بلاک ریورگ حملے کی وضاحت کی تھی، نے ایک فائنیلیٹی تاخیر (عرف 'لائیونیس فیلر') حملے کی بھی وضاحت کی تھی جو حملہ آور پر انحصار کرتا ہے جو ایک عہد کی باؤنڈری بلاک کے لیے بلاک پروپوزر ہو۔ یہ اہم ہے کیونکہ یہ عہد باؤنڈری بلاکس وہ چیک پوائنٹس بن جاتے ہیں جن کا استعمال Casper FFG چین کے حصوں کو حتمی شکل دینے کے لیے کرتا ہے۔ حملہ آور صرف اپنے بلاک کو اس وقت تک روکے رکھتا ہے جب تک کہ کافی ایماندار ویلیڈیٹرز اپنے FFG ووٹوں کا استعمال پچھلے عہد-باؤنڈری بلاک کے حق میں موجودہ حتمی ہدف کے طور پر نہ کریں۔ پھر وہ اپنا روکا ہوا بلاک جاری کرتے ہیں۔ وہ اپنے بلاک کی تصدیق کرتے ہیں اور باقی ایماندار ویلیڈیٹرز بھی ایسا ہی کرتے ہیں جس سے مختلف ٹارگٹ چیک پوائنٹس کے ساتھ فورکس بنتے ہیں۔ اگر انہوں نے اسے بالکل صحیح وقت پر کیا، تو وہ فائنیلیٹی کو روک دیں گے کیونکہ کسی بھی فورک کی تصدیق کرنے والی 2/3 کی سپر میجورٹی نہیں ہوگی۔ اسٹیک جتنا چھوٹا ہوگا، وقت اتنا ہی درست ہونا چاہیے کیونکہ حملہ آور براہ راست کم تصدیقوں کو کنٹرول کرتا ہے، اور حملہ آور کے کسی دیے گئے عہد-باؤنڈری بلاک کی تجویز کرنے والے ویلیڈیٹر کو کنٹرول کرنے کے امکانات اتنے ہی کم ہوتے ہیں۔ + +#### طویل فاصلے کے حملے {#long-range-attacks} + +پروف-آف-اسٹیک بلاک چینز کے لیے مخصوص حملے کی ایک قسم بھی ہے جس میں ایک ویلیڈیٹر شامل ہوتا ہے جس نے جینیسس بلاک میں حصہ لیا تھا جو ایماندار کے ساتھ ساتھ بلاک چین کے ایک الگ فورک کو برقرار رکھتا ہے، آخر کار ایماندار ویلیڈیٹر سیٹ کو بہت بعد میں کسی مناسب وقت پر اس پر سوئچ کرنے پر راضی کرتا ہے۔ اس قسم کا حملہ Ethereum پر ممکن نہیں ہے کیونکہ فائنیلیٹی گیجٹ اس بات کو یقینی بناتا ہے کہ تمام ویلیڈیٹرز باقاعدہ وقفوں ('چیک پوائنٹس') پر ایماندار چین کی حالت پر متفق ہوں۔ یہ سادہ طریقہ کار طویل فاصلے کے حملہ آوروں کو بے اثر کر دیتا ہے کیونکہ Ethereum کلائنٹس صرف حتمی بلاکس کو ریورگ نہیں کریں گے۔ نیٹ ورک میں شامل ہونے والے نئے نوڈس ایک قابل اعتماد حالیہ اسٹیٹ ہیش ('[کمزور موضوعیت](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) چیک پوائنٹ') تلاش کرکے اور اسے ایک چھدم-جینیسس بلاک کے طور پر استعمال کرکے ایسا کرتے ہیں جس پر تعمیر کی جائے۔ یہ نیٹ ورک میں داخل ہونے والے ایک نئے نوڈ کے لیے ایک 'اعتماد کا گیٹ وے' بناتا ہے اس سے پہلے کہ وہ خود معلومات کی تصدیق کرنا شروع کر سکے۔ + +#### سروس سے انکار {#denial-of-service} + +Ethereum کا PoS میکانزم ہر سلاٹ میں بلاک پروپوزر بننے کے لیے کل ویلیڈیٹر سیٹ سے ایک واحد ویلیڈیٹر کا انتخاب کرتا ہے۔ اس کا حساب ایک عوامی طور پر معلوم فنکشن کا استعمال کرتے ہوئے کیا جا سکتا ہے اور ایک مخالف کے لیے اگلے بلاک پروپوزر کی شناخت ان کے بلاک پروپوزل سے تھوڑا پہلے ممکن ہے۔ پھر، حملہ آور بلاک پروپوزر کو اسپام کر سکتا ہے تاکہ انہیں اپنے ساتھیوں کے ساتھ معلومات کا تبادلہ کرنے سے روکا جا سکے۔ باقی نیٹ ورک کے لیے، یہ ظاہر ہوگا کہ بلاک پروپوزر آف لائن تھا اور سلاٹ صرف خالی رہ جائے گا۔ یہ مخصوص ویلیڈیٹرز کے خلاف سنسرشپ کی ایک شکل ہوسکتی ہے، جو انہیں بلاک چین میں معلومات شامل کرنے سے روکتی ہے۔ سنگل سیکرٹ لیڈر الیکشنز (SSLE) یا نان-سنگل سیکرٹ لیڈر الیکشنز کو نافذ کرنے سے DoS کے خطرات کم ہوں گے کیونکہ صرف بلاک پروپوزر ہی جانتا ہے کہ اسے منتخب کیا گیا ہے اور انتخاب پہلے سے جاننا ممکن نہیں ہے۔ یہ ابھی تک نافذ نہیں کیا گیا ہے، لیکن یہ [تحقیق اور ترقی](https://ethresear.ch/t/secret-non-single-leader-election/11789) کا ایک فعال شعبہ ہے۔ + +یہ سب اس حقیقت کی طرف اشارہ کرتا ہے کہ ایک چھوٹے اسٹیک کے ساتھ Ethereum پر کامیابی سے حملہ کرنا بہت مشکل ہے۔ یہاں بیان کیے گئے قابل عمل حملوں کے لیے ایک مثالی فورک-چوائس الگورتھم، غیر امکانی نیٹ ورک حالات کی ضرورت ہوتی ہے، یا حملہ آور ویکٹرز کو کلائنٹ سافٹ ویئر میں نسبتاً معمولی پیچز کے ساتھ پہلے ہی بند کر دیا گیا ہے۔ یہ، یقیناً، جنگل میں زیرو-ڈیز کے موجود ہونے کے امکان کو رد نہیں کرتا، لیکن یہ ایک اقلیتی-اسٹیک حملہ آور کے موثر ہونے کے لیے درکار تکنیکی قابلیت، اتفاق رائے کی پرت کے علم اور قسمت کی انتہائی اعلی بار کو ظاہر کرتا ہے۔ ایک حملہ آور کے نقطہ نظر سے، ان کی بہترین شرط یہ ہوسکتی ہے کہ وہ زیادہ سے زیادہ ایتھر جمع کریں اور کل اسٹیک کے زیادہ تناسب سے لیس ہوکر واپس آئیں۔ + +### کل اسٹیک کے >= 33% کا استعمال کرنے والے حملہ آور {#attackers-with-33-stake} + +اس مضمون میں پہلے ذکر کیے گئے تمام حملوں کے کامیاب ہونے کا امکان زیادہ ہوتا ہے جب حملہ آور کے پاس ووٹ دینے کے لیے زیادہ اسٹیک شدہ ایتھر ہو، اور زیادہ ویلیڈیٹرز ہوں جنہیں ہر سلاٹ میں بلاکس تجویز کرنے کے لیے منتخب کیا جا سکتا ہے۔ اس لیے ایک بدنیتی پر مبنی ویلیڈیٹر زیادہ سے زیادہ اسٹیک شدہ ایتھر کو کنٹرول کرنے کا مقصد رکھ سکتا ہے۔ + +اسٹیک شدہ ایتھر کا 33% ایک حملہ آور کے لیے ایک بینچ مارک ہے کیونکہ اس رقم سے زیادہ کسی بھی چیز کے ساتھ ان کے پاس دوسرے ویلیڈیٹرز کے اعمال کو باریکی سے کنٹرول کیے بغیر چین کو حتمی شکل دینے سے روکنے کی صلاحیت ہوتی ہے۔ وہ سب مل کر غائب ہو سکتے ہیں۔ اگر اسٹیک شدہ ایتھر کا 1/3 یا اس سے زیادہ بدنیتی سے تصدیق کر رہا ہے یا تصدیق کرنے میں ناکام ہو رہا ہے، تو 2/3 کی سپر میجورٹی موجود نہیں ہوسکتی ہے اور چین حتمی شکل نہیں دے سکتا ہے۔ اس کے خلاف دفاع غیرفعالیت کا رساو ہے۔ غیرفعالیت کا رساو ان ویلیڈیٹرز کی نشاندہی کرتا ہے جو تصدیق کرنے میں ناکام ہو رہے ہیں یا اکثریت کے خلاف تصدیق کر رہے ہیں۔ ان غیر تصدیق کرنے والے ویلیڈیٹرز کے زیر ملکیت اسٹیک شدہ ایتھر آہستہ آہستہ ختم ہو جاتا ہے یہاں تک کہ آخر کار وہ اجتماعی طور پر کل کے 1/3 سے بھی کم کی نمائندگی کرتے ہیں تاکہ چین دوبارہ حتمی شکل دے سکے۔ + +غیرفعالیت کے رساو کا مقصد چین کو دوبارہ حتمی شکل دینا ہے۔ تاہم، حملہ آور اپنے اسٹیک شدہ ایتھر کا ایک حصہ بھی کھو دیتا ہے۔ کل اسٹیک شدہ ایتھر کے 33% کی نمائندگی کرنے والے ویلیڈیٹرز میں مستقل غیرفعالیت بہت مہنگی ہے حالانکہ ویلیڈیٹرز کو سلیش نہیں کیا جاتا ہے۔ + +یہ فرض کرتے ہوئے کہ Ethereum نیٹ ورک غیر ہم آہنگ ہے (یعنی، پیغامات بھیجنے اور وصول کرنے کے درمیان تاخیر ہوتی ہے)، کل اسٹیک کے 34% کو کنٹرول کرنے والا حملہ آور ڈبل فائنیلیٹی کا سبب بن سکتا ہے۔ اس کی وجہ یہ ہے کہ حملہ آور اس وقت مساوی کر سکتا ہے جب انہیں بلاک پروڈیوسر کے طور پر منتخب کیا جاتا ہے، پھر اپنے تمام ویلیڈیٹرز کے ساتھ ڈبل ووٹ دیتے ہیں۔ یہ ایک ایسی صورتحال پیدا کرتا ہے جہاں بلاک چین کا ایک فورک موجود ہوتا ہے، ہر ایک کے پاس 34% اسٹیک شدہ ایتھر اس کے لیے ووٹ دیتا ہے۔ ہر فورک کو صرف باقی ویلیڈیٹرز کے 50% کی ضرورت ہوتی ہے تاکہ اس کے حق میں ووٹ دیں تاکہ دونوں فورکس کو سپر میجورٹی کی حمایت حاصل ہو، اس صورت میں دونوں چینز حتمی شکل دے سکتی ہیں (کیونکہ حملہ آوروں کے ویلیڈیٹرز کا 34% + باقی 66% کا نصف = ہر فورک پر 67%)۔ مسابقتی بلاکس کو ہر ایک کو تقریبا 50% ایماندار ویلیڈیٹرز کے ذریعہ وصول کرنا ہوگا لہذا یہ حملہ صرف اس وقت قابل عمل ہے جب حملہ آور کے پاس نیٹ ورک پر پھیلنے والے پیغامات کے وقت پر کچھ حد تک کنٹرول ہو تاکہ وہ ہر چین پر آدھے ایماندار ویلیڈیٹرز کو دھکیل سکے۔ حملہ آور لازمی طور پر اپنے پورے اسٹیک (آج کے ویلیڈیٹر سیٹ کے ساتھ ~10 ملین ایتھر کا 34%) کو اس دوہری حتمی شکل کو حاصل کرنے کے لیے تباہ کر دے گا کیونکہ ان کے 34% ویلیڈیٹرز ایک ساتھ ڈبل ووٹنگ کر رہے ہوں گے - زیادہ سے زیادہ ارتباط کی سزا کے ساتھ ایک قابل سلیش جرم۔ اس حملے کے خلاف دفاع کل اسٹیک شدہ ایتھر کے 34% کو تباہ کرنے کی بہت بڑی لاگت ہے۔ اس حملے سے بحالی کے لیے Ethereum کمیونٹی کو 'آؤٹ-آف-بینڈ' میں ہم آہنگی پیدا کرنے اور ایک یا دوسرے فورک کی پیروی کرنے اور دوسرے کو نظر انداز کرنے پر اتفاق کرنے کی ضرورت ہوگی۔ + +### کل اسٹیک کے ~50% کا استعمال کرنے والے حملہ آور {#attackers-with-50-stake} + +اسٹیک شدہ ایتھر کے 50% پر، ویلیڈیٹرز کا ایک شرارتی گروہ نظریاتی طور پر چین کو دو مساوی سائز کے فورکس میں تقسیم کر سکتا ہے اور پھر ایماندار ویلیڈیٹر سیٹ کے برعکس ووٹ دینے کے لیے اپنے پورے 50% اسٹیک کا استعمال کر سکتا ہے، اس طرح دونوں فورکس کو برقرار رکھا جا سکتا ہے اور فائنیلیٹی کو روکا جا سکتا ہے۔ دونوں فورکس پر غیرفعالیت کا رساو بالآخر دونوں چینز کو حتمی شکل دینے کا باعث بنے گا۔ اس وقت، واحد آپشن سماجی بحالی کا سہارا لینا ہے۔ + +یہ بہت غیر امکانی ہے کہ ویلیڈیٹرز کا ایک مخالف گروہ ایماندار ویلیڈیٹر نمبروں، نیٹ ورک لیٹنسی وغیرہ میں اتار چڑھاؤ کی ایک ڈگری کے پیش نظر مسلسل کل اسٹیک کے ٹھیک 50% کو کنٹرول کر سکتا ہے - اس طرح کے حملے کو کرنے کی بھاری لاگت کامیابی کے کم امکان کے ساتھ مل کر ایک عقلی حملہ آور کے لیے ایک مضبوط حوصلہ شکنی معلوم ہوتی ہے، خاص طور پر جب 50% سے _زیادہ_ حاصل کرنے میں ایک چھوٹی سی اضافی سرمایہ کاری بہت زیادہ طاقت کو کھول دیتی ہے۔ + +کل اسٹیک کے >50% پر حملہ آور فورک چوائس الگورتھم پر غلبہ حاصل کر سکتا ہے۔ اس صورت میں، حملہ آور اکثریت کے ووٹ کے ساتھ تصدیق کرنے کے قابل ہو گا، جو انہیں ایماندار کلائنٹس کو بے وقوف بنائے بغیر مختصر ریورگس کرنے کے لیے کافی کنٹرول دے گا۔ ایماندار ویلیڈیٹرز اس کی پیروی کریں گے کیونکہ ان کا فورک چوائس الگورتھم بھی حملہ آور کی پسندیدہ چین کو سب سے بھاری کے طور پر دیکھے گا، لہذا چین حتمی شکل دے سکتا ہے۔ یہ حملہ آور کو کچھ ٹرانزیکشنز کو سنسر کرنے، مختصر رینج کے ریورگس کرنے اور ان کے حق میں بلاکس کو دوبارہ ترتیب دے کر زیادہ سے زیادہ MEV نکالنے کے قابل بناتا ہے۔ اس کے خلاف دفاع اکثریتی اسٹیک کی بھاری لاگت ہے (فی الحال صرف 19 بلین امریکی ڈالر سے کم) جو ایک حملہ آور کے ذریعہ خطرے میں ڈالی جاتی ہے کیونکہ سماجی پرت کے قدم رکھنے اور ایک ایماندار اقلیتی فورک کو اپنانے کا امکان ہے، جس سے حملہ آور کے اسٹیک کی قدر میں ڈرامائی طور پر کمی آئے گی۔ + +### کل اسٹیک کے >=66% کا استعمال کرنے والے حملہ آور {#attackers-with-66-stake} + +66% یا اس سے زیادہ کل اسٹیک شدہ ایتھر والا حملہ آور کسی بھی ایماندار ویلیڈیٹر کو مجبور کیے بغیر اپنی ترجیحی چین کو حتمی شکل دے سکتا ہے۔ حملہ آور صرف اپنی ترجیحی فورک کے لیے ووٹ دے سکتا ہے اور پھر اسے حتمی شکل دے سکتا ہے، صرف اس لیے کہ وہ ایک بے ایمان سپر میجورٹی کے ساتھ ووٹ دے سکتے ہیں۔ سپر میجورٹی اسٹیک ہولڈر کے طور پر، حملہ آور ہمیشہ حتمی بلاکس کے مواد کو کنٹرول کرے گا، جس میں خرچ کرنے، ریوائنڈ کرنے اور دوبارہ خرچ کرنے، کچھ ٹرانزیکشنز کو سنسر کرنے اور اپنی مرضی سے چین کو ریورگ کرنے کی طاقت ہوگی۔ 51% کے بجائے 66% کو کنٹرول کرنے کے لیے اضافی ایتھر خرید کر، حملہ آور مؤثر طریقے سے سابقہ ریورگس اور فائنیلیٹی ریورژنز کرنے کی صلاحیت خرید رہا ہے (یعنی، ماضی کو تبدیل کرنے کے ساتھ ساتھ مستقبل کو بھی کنٹرول کرنا)۔ یہاں واحد حقیقی دفاع کل اسٹیک شدہ ایتھر کے 66% کی بھاری لاگت ہے، اور ایک متبادل فورک کو اپنانے کے لیے سماجی پرت کا سہارا لینے کا آپشن۔ ہم اگلے حصے میں اس کا مزید تفصیل سے جائزہ لے سکتے ہیں۔ + +## لوگ: دفاع کی آخری لائن {#people-the-last-line-of-defense} + +اگر بے ایمان ویلیڈیٹرز چین کے اپنے ترجیحی ورژن کو حتمی شکل دینے میں کامیاب ہو جاتے ہیں، تو Ethereum کمیونٹی ایک مشکل صورتحال میں پڑ جاتی ہے۔ کینونیکل چین میں اس کی تاریخ میں ایک بے ایمان حصہ شامل ہے، جبکہ ایماندار ویلیڈیٹرز کو ایک متبادل (ایماندار) چین کی تصدیق کرنے پر سزا دی جا سکتی ہے۔ نوٹ کریں کہ ایک حتمی لیکن غلط چین بھی اکثریتی کلائنٹ میں ایک بگ سے پیدا ہوسکتی ہے۔ آخر میں، حتمی فال بیک صورتحال کو حل کرنے کے لیے سماجی پرت - پرت 0 - پر انحصار کرنا ہے۔ + +Ethereum کے PoS اتفاق رائے کی ایک خوبی یہ ہے کہ [دفاعی حکمت عملیوں کی ایک رینج](https://youtu.be/1m12zgJ42dI?t=1712) ہے جسے کمیونٹی حملے کے پیش نظر استعمال کر سکتی ہے۔ ایک کم سے کم ردعمل حملہ آوروں کے ویلیڈیٹرز کو بغیر کسی اضافی سزا کے نیٹ ورک سے زبردستی باہر نکالنا ہو سکتا ہے۔ نیٹ ورک میں دوبارہ داخل ہونے کے لیے حملہ آور کو ایکٹیویشن کی قطار میں شامل ہونا پڑے گا جو اس بات کو یقینی بناتی ہے کہ ویلیڈیٹر سیٹ بتدریج بڑھے۔ مثال کے طور پر، اسٹیک شدہ ایتھر کی مقدار کو دوگنا کرنے کے لیے کافی ویلیڈیٹرز شامل کرنے میں تقریبا 200 دن لگتے ہیں، جو مؤثر طریقے سے ایماندار ویلیڈیٹرز کو 200 دن خریدتے ہیں اس سے پہلے کہ حملہ آور 51% حملے کی ایک اور کوشش کر سکے۔ تاہم، کمیونٹی حملہ آور کو زیادہ سختی سے سزا دینے کا فیصلہ بھی کر سکتی ہے، پچھلے انعامات کو منسوخ کرکے یا ان کے اسٹیک شدہ سرمائے کا کچھ حصہ (100٪ تک) جلا کر۔ + +حملہ آور پر جو بھی سزا عائد کی جاتی ہے، کمیونٹی کو مل کر یہ بھی فیصلہ کرنا ہوگا کہ کیا بے ایمان چین، Ethereum کلائنٹس میں کوڈ کیے گئے فورک چوائس الگورتھم کے ذریعہ پسندیدہ ہونے کے باوجود، درحقیقت ناجائز ہے اور کمیونٹی کو اس کے بجائے ایماندار چین پر تعمیر کرنا چاہئے۔ ایماندار ویلیڈیٹرز اجتماعی طور پر Ethereum بلاک چین کے کمیونٹی سے منظور شدہ فورک پر تعمیر کرنے پر اتفاق کر سکتے ہیں جو، مثال کے طور پر، حملے کے شروع ہونے سے پہلے کینونیکل چین سے فورک ہو گیا ہو یا حملہ آوروں کے ویلیڈیٹرز کو زبردستی ہٹا دیا گیا ہو۔ ایماندار ویلیڈیٹرز کو اس چین پر تعمیر کرنے کی ترغیب دی جائے گی کیونکہ وہ حملہ آور کی چین کی تصدیق کرنے میں (بجا طور پر) ناکام ہونے پر ان پر لاگو ہونے والی سزاؤں سے بچیں گے۔ Ethereum پر بنائے گئے ایکسچینجز، آن-ریمپس اور ایپلی کیشنز ممکنہ طور پر ایماندار چین پر رہنا پسند کریں گے اور ایماندار ویلیڈیٹرز کی پیروی کرکے ایماندار بلاک چین پر جائیں گے۔ + +تاہم، یہ ایک اہم گورننس چیلنج ہوگا۔ کچھ صارفین اور ویلیڈیٹرز بلاشبہ ایماندار چین پر واپس سوئچ کے نتیجے میں نقصان اٹھائیں گے، حملے کے بعد تصدیق شدہ بلاکس میں ٹرانزیکشنز ممکنہ طور پر رول بیک ہو سکتے ہیں، جس سے ایپلیکیشن پرت میں خلل پڑ سکتا ہے، اور یہ کچھ صارفین کے اخلاقیات کو بالکل کمزور کرتا ہے جو 'کوڈ قانون ہے' پر یقین رکھتے ہیں۔ ایکسچینجز اور ایپلی کیشنز نے غالباً آف چین کارروائیوں کو آن چین ٹرانزیکشنز سے جوڑا ہوگا جنہیں اب رول بیک کیا جا سکتا ہے، جس سے واپسیوں اور نظرثانیوں کا ایک سلسلہ شروع ہو جائے گا جسے منصفانہ طور پر سلجھانا مشکل ہوگا، خاص طور پر اگر ناجائز کمائی کو ملایا گیا ہو، DeFi یا دیگر ڈیریویٹوز میں جمع کیا گیا ہو جس کے ایماندار صارفین کے لیے ثانوی اثرات ہوں۔ بلاشبہ کچھ صارفین، شاید ادارہ جاتی بھی، پہلے ہی بے ایمان چین سے فائدہ اٹھا چکے ہوں گے یا تو ہوشیار ہو کر یا اتفاق سے، اور اپنے فوائد کی حفاظت کے لیے ایک فورک کی مخالفت کر سکتے ہیں۔ >51% حملوں پر کمیونٹی کے ردعمل کی مشق کرنے کے لیے کالیں کی گئی ہیں تاکہ ایک سمجھدار مربوط تخفیف کو تیزی سے انجام دیا جا سکے۔ ایتھریسرچ پر وائٹالک کی کچھ مفید بحث [یہاں](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) اور [یہاں](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) اور ٹویٹر پر [یہاں](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw) موجود ہے۔ ایک مربوط سماجی ردعمل کا مقصد حملہ آور کو سزا دینے اور دوسرے صارفین کے لیے اثرات کو کم کرنے کے بارے میں بہت ہدفی اور مخصوص ہونا چاہیے۔ + +گورننس پہلے ہی ایک پیچیدہ موضوع ہے۔ ایک بے ایمان حتمی چین کے لیے پرت-0 ہنگامی ردعمل کا انتظام کرنا بلاشبہ Ethereum کمیونٹی کے لیے چیلنجنگ ہوگا، لیکن یہ Ethereum کی تاریخ میں [ہوا ہے](/ethereum-forks/#dao-fork-summary) - [دو بار](/ethereum-forks/#tangerine-whistle))۔ + +بہر حال، میٹ اسپیس میں حتمی فال بیک بیٹھنے میں کچھ نہ کچھ اطمینان بخش ہے۔ بالآخر، ہمارے اوپر ٹیکنالوجی کے اس غیر معمولی اسٹیک کے ساتھ بھی، اگر بدترین کبھی ہوتا ہے تو حقیقی لوگوں کو اس سے نکلنے کے لیے اپنا راستہ ہم آہنگ کرنا پڑے گا۔ + +## خلاصہ {#summary} + +اس صفحے نے کچھ طریقوں کا جائزہ لیا جن سے حملہ آور Ethereum کے پروف-آف-اسٹیک اتفاق رائے پروٹوکول کا استحصال کرنے کی کوشش کر سکتے ہیں۔ ریورگس اور فائنیلیٹی تاخیر کا جائزہ کل اسٹیک شدہ ایتھر کے بڑھتے ہوئے تناسب والے حملہ آوروں کے لیے کیا گیا تھا۔ مجموعی طور پر، ایک امیر حملہ آور کے کامیاب ہونے کا زیادہ امکان ہے کیونکہ ان کا اسٹیک ووٹنگ کی طاقت میں ترجمہ ہوتا ہے جسے وہ مستقبل کے بلاکس کے مواد کو متاثر کرنے کے لیے استعمال کر سکتے ہیں۔ اسٹیک شدہ ایتھر کی کچھ حد کی مقدار پر، حملہ آور کی طاقت کی سطح بڑھ جاتی ہے: + +33٪: فائنیلیٹی تاخیر + +34٪: فائنیلیٹی تاخیر، ڈبل فائنیلیٹی + +51٪: فائنیلیٹی تاخیر، ڈبل فائنیلیٹی، سنسرشپ، بلاک چین کے مستقبل پر کنٹرول + +66%: فائنیلیٹی تاخیر، ڈبل فائنیلیٹی، سنسرشپ، بلاک چین کے مستقبل اور ماضی پر کنٹرول + +اس کے علاوہ مزید نفیس حملوں کی ایک رینج بھی ہے جس کے لیے کم مقدار میں اسٹیک شدہ ایتھر کی ضرورت ہوتی ہے لیکن وہ ایک بہت ہی نفیس حملہ آور پر انحصار کرتے ہیں جو اپنے حق میں ایماندار ویلیڈیٹر سیٹ کو جھکانے کے لیے پیغام کے وقت پر عمدہ کنٹرول رکھتا ہے۔ + +مجموعی طور پر، ان ممکنہ حملہ آور ویکٹرز کے باوجود ایک کامیاب حملے کا خطرہ کم ہے، یقینی طور پر پروف-آف-ورک کے مساوی سے کم ہے۔ اس کی وجہ یہ ہے کہ ایک حملہ آور کے ذریعہ خطرے میں ڈالے گئے اسٹیک شدہ ایتھر کی بھاری لاگت ہے جس کا مقصد ایماندار ویلیڈیٹرز کو اپنی ووٹنگ کی طاقت سے مغلوب کرنا ہے۔ بلٹ ان 'گاجر اور چھڑی' ترغیبی پرت زیادہ تر بددیانتی سے بچاتی ہے، خاص طور پر کم اسٹیک والے حملہ آوروں کے لیے۔ زیادہ لطیف باؤنسنگ اور بیلنسنگ حملوں کے کامیاب ہونے کا بھی امکان نہیں ہے کیونکہ حقیقی نیٹ ورک کے حالات ویلیڈیٹرز کے مخصوص ذیلی سیٹوں کو پیغام کی ترسیل کے عمدہ کنٹرول کو حاصل کرنا بہت مشکل بنا دیتے ہیں، اور کلائنٹ ٹیموں نے سادہ پیچز کے ساتھ معلوم باؤنسنگ، بیلنسنگ اور ایولانچ اٹیک ویکٹرز کو تیزی سے بند کر دیا ہے۔ + +34%، 51% یا 66% حملوں کو حل کرنے کے لیے ممکنہ طور پر آؤٹ-آف-بینڈ سماجی ہم آہنگی کی ضرورت ہوگی۔ جبکہ یہ کمیونٹی کے لیے ممکنہ طور پر تکلیف دہ ہوگا، ایک کمیونٹی کی آؤٹ-آف-بینڈ میں جواب دینے کی صلاحیت ایک حملہ آور کے لیے ایک مضبوط حوصلہ شکنی ہے۔ Ethereum سماجی پرت حتمی بیک اسٹاپ ہے - ایک تکنیکی طور پر کامیاب حملہ اب بھی کمیونٹی کے ذریعہ ایک ایماندار فورک کو اپنانے پر اتفاق کرکے بے اثر کیا جا سکتا ہے۔ حملہ آور اور Ethereum کمیونٹی کے درمیان ایک دوڑ ہوگی - 66% حملے پر خرچ ہونے والے اربوں ڈالر ممکنہ طور پر ایک کامیاب سماجی ہم آہنگی حملے سے ختم ہو جائیں گے اگر اسے کافی تیزی سے پہنچایا گیا، جس سے حملہ آور Ethereum کمیونٹی کے ذریعہ نظر انداز کیے گئے ایک معلوم بے ایمان چین پر غیر مائع اسٹیک شدہ ایتھر کے بھاری بیگ کے ساتھ رہ جائے گا۔ اس بات کا امکان کہ یہ حملہ آور کے لیے منافع بخش ثابت ہوگا اتنا کم ہے کہ یہ ایک موثر روک تھام ہے۔ یہی وجہ ہے کہ مضبوطی سے منسلک اقدار کے ساتھ ایک مربوط سماجی پرت کو برقرار رکھنے میں سرمایہ کاری اتنی اہم ہے۔ + +## مزید مطالعہ {#further-reading} + +- [اس صفحے کا مزید تفصیلی ورژن](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [سیٹلمنٹ فائنیلیٹی پر وائٹالک](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [LMD GHOST پیپر](https://arxiv.org/abs/2003.03052) +- [Casper-FFG پیپر](https://arxiv.org/abs/1710.09437) +- [Gasper پیپر](https://arxiv.org/pdf/2003.03052.pdf) +- [پرپوزر ویٹ بوسٹنگ اتفاق رائے کی تفصیلات](https://github.com/ethereum/consensus-specs/pull/2730) +- [ایتھریسرچ پر باؤنسنگ حملے](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) +- [SSLE تحقیق](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..1a7922ac7f8 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "تصدیقات" +description: "پروف-آف-اسٹیک Ethereum پر تصدیقات کی تفصیل۔" +lang: ur-in +--- + +ہر ایپوک کے دوران ایک ویلیڈیٹر سے ایک تصدیق بنانے، اس پر دستخط کرنے اور اسے براڈکاسٹ کرنے کی توقع کی جاتی ہے۔ یہ صفحہ اس بات کا خاکہ پیش کرتا ہے کہ یہ تصدیقات کیسی دکھتی ہیں اور کنسنسس کلائنٹس کے درمیان ان پر کارروائی اور ان کا تبادلہ کیسے ہوتا ہے۔ + +## تصدیق کیا ہے؟ {#what-is-an-attestation} + +ہر [ایپوک](/glossary/#epoch) (6.4 منٹ) میں ایک ویلیڈیٹر نیٹ ورک کو ایک تصدیق کی تجویز پیش کرتا ہے۔ تصدیق ایپوک میں ایک مخصوص سلاٹ کے لیے ہوتی ہے۔ تصدیق کا مقصد چین کے بارے میں ویلیڈیٹر کے نظریہ کے حق میں ووٹ دینا ہے، خاص طور پر سب سے حالیہ جائز بلاک اور موجودہ ایپوک کے پہلے بلاک (جسے `source` اور `target` چیک پوائنٹس کے نام سے جانا جاتا ہے) کے حق میں۔ یہ معلومات تمام حصہ لینے والے ویلیڈیٹرز کے لیے یکجا کی جاتی ہیں، جس سے نیٹ ورک بلاک چین کی اسٹیٹ کے بارے میں کنسنسس تک پہنچ پاتا ہے۔ + +تصدیق میں درج ذیل اجزاء ہوتے ہیں: + +- `aggregation_bits`: ویلیڈیٹرز کی ایک بٹ لسٹ جہاں پوزیشن ان کی کمیٹی میں ویلیڈیٹر انڈیکس سے مطابقت رکھتی ہے؛ ویلیو (0/1) اس بات کی نشاندہی کرتی ہے کہ آیا ویلیڈیٹر نے `data` پر دستخط کیے ہیں (یعنی، آیا وہ فعال ہیں اور بلاک پروپوزر سے اتفاق کرتے ہیں) +- `data`: تصدیق سے متعلق تفصیلات، جیسا کہ ذیل میں بیان کیا گیا ہے +- `signature`: ایک BLS دستخط جو انفرادی ویلیڈیٹرز کے دستخطوں کو جمع کرتا ہے + +ایک تصدیق کرنے والے ویلیڈیٹر کے لیے پہلا کام `data` بنانا ہے۔ `data` میں درج ذیل معلومات ہوتی ہیں: + +- `slot`: وہ سلاٹ نمبر جس کا تصدیق حوالہ دیتی ہے +- `index`: ایک نمبر جو یہ شناخت کرتا ہے کہ ایک دیے گئے سلاٹ میں ویلیڈیٹر کس کمیٹی سے تعلق رکھتا ہے +- `beacon_block_root`: اس بلاک کا روٹ ہیش جسے ویلیڈیٹر چین کے ہیڈ پر دیکھتا ہے (فورک-چوائس الگورتھم کو لاگو کرنے کا نتیجہ) +- `source`: فائنلٹی ووٹ کا حصہ جو اس بات کی نشاندہی کرتا ہے کہ ویلیڈیٹرز سب سے حالیہ جائز بلاک کے طور پر کیا دیکھتے ہیں +- `target`: فائنلٹی ووٹ کا حصہ جو اس بات کی نشاندہی کرتا ہے کہ ویلیڈیٹرز موجودہ ایپوک میں پہلے بلاک کے طور پر کیا دیکھتے ہیں + +ایک بار جب `data` بن جاتا ہے، تو ویلیڈیٹر `aggregation_bits` میں اپنے ویلیڈیٹر انڈیکس کے مطابق بٹ کو 0 سے 1 میں پلٹ سکتا ہے تاکہ یہ ظاہر ہو کہ اس نے حصہ لیا تھا۔ + +آخر میں، ویلیڈیٹر تصدیق پر دستخط کرتا ہے اور اسے نیٹ ورک پر براڈکاسٹ کرتا ہے۔ + +### مجموعی تصدیق {#aggregated-attestation} + +ہر ویلیڈیٹر کے لیے نیٹ ورک پر اس ڈیٹا کو منتقل کرنے سے وابستہ ایک خاطر خواہ اوورہیڈ ہے۔ لہذا، انفرادی ویلیڈیٹرز کی تصدیقات کو زیادہ وسیع پیمانے پر براڈکاسٹ کیے جانے سے پہلے سب نیٹس کے اندر جمع کیا جاتا ہے۔ اس میں دستخطوں کو ایک ساتھ جمع کرنا شامل ہے تاکہ براڈکاسٹ ہونے والی تصدیق میں کنسنسس `data` اور ان تمام ویلیڈیٹرز کے دستخطوں کو ملا کر بنایا گیا ایک واحد دستخط شامل ہو جو اس `data` سے اتفاق کرتے ہیں۔ اسے `aggregation_bits` کا استعمال کرکے چیک کیا جاسکتا ہے کیونکہ یہ ان کی کمیٹی میں ہر ویلیڈیٹر کا انڈیکس فراہم کرتا ہے (جس کی ID `data` میں فراہم کی گئی ہے) جسے انفرادی دستخطوں کی استفسار کے لیے استعمال کیا جاسکتا ہے۔ + +ہر ایپوک میں ہر سب نیٹ میں 16 ویلیڈیٹرز کو `aggregators` کے طور پر منتخب کیا جاتا ہے۔ ایگریگیٹرز گوسپ نیٹ ورک پر سنی گئی ان تمام تصدیقات کو جمع کرتے ہیں جن کا `data` ان کے اپنے `data` کے برابر ہوتا ہے۔ ہر مماثل تصدیق کے بھیجنے والے کو `aggregation_bits` میں ریکارڈ کیا جاتا ہے۔ اس کے بعد ایگریگیٹرز تصدیق کے مجموعے کو وسیع تر نیٹ ورک پر براڈکاسٹ کرتے ہیں۔ + +جب کسی ویلیڈیٹر کو بلاک پروپوزر کے طور پر منتخب کیا جاتا ہے تو وہ نئے بلاک میں تازہ ترین سلاٹ تک سب نیٹس سے مجموعی تصدیقات کو پیکج کرتے ہیں۔ + +### تصدیق کی شمولیت کا لائف سائیکل {#attestation-inclusion-lifecycle} + +1. جنریشن +2. پھیلاؤ +3. ایگریگیشن +4. پھیلاؤ +5. شمولیت + +تصدیق کا لائف سائیکل نیچے دیے گئے خاکے میں بیان کیا گیا ہے: + +![تصدیق کا لائف سائیکل](./attestation_schematic.png) + +## انعامات {#rewards} + +ویلیڈیٹرز کو تصدیقات جمع کرنے پر انعام دیا جاتا ہے۔ تصدیق کا انعام شرکت کے فلیگس (سورس، ٹارگٹ اور ہیڈ)، بنیادی انعام اور شرکت کی شرح پر منحصر ہے۔ + +جمع کی گئی تصدیق اور اس کی شمولیت میں تاخیر کے لحاظ سے ہر شرکت کا فلیگ یا تو درست یا غلط ہو سکتا ہے۔ + +بہترین منظرنامہ اس وقت ہوتا ہے جب تینوں فلیگس درست ہوں، اس صورت میں ایک ویلیڈیٹر کمائے گا (فی درست فلیگ): + +`reward += base reward * flag weight * flag attesting rate / 64` + +فلیگ تصدیقی شرح کو دیے گئے فلیگ کے لیے تمام تصدیق کرنے والے ویلیڈیٹرز کے مؤثر بیلنس کے مجموعے کا کل فعال مؤثر بیلنس سے موازنہ کرکے ماپا جاتا ہے۔ + +### بنیادی انعام {#base-reward} + +بنیادی انعام کا حساب تصدیق کرنے والے ویلیڈیٹرز کی تعداد اور ان کے مؤثر اسٹیک شدہ ایتھر بیلنس کے مطابق کیا جاتا ہے: + +`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` + +#### شمولیت میں تاخیر {#inclusion-delay} + +جس وقت ویلیڈیٹرز نے چین کے ہیڈ (`block n`) پر ووٹ دیا، اس وقت `block n+1` ابھی تک تجویز نہیں کیا گیا تھا۔ لہذا تصدیقات قدرتی طور پر **ایک بلاک بعد** شامل ہو جاتی ہیں، اس لیے `block n` کو چین کا ہیڈ ہونے پر ووٹ دینے والی تمام تصدیقات `block n+1` میں شامل ہو گئیں، اور **شمولیت میں تاخیر** 1 ہے۔ اگر شمولیت میں تاخیر دوگنی ہو کر دو سلاٹس ہو جاتی ہے، تو تصدیق کا انعام آدھا ہو جاتا ہے، کیونکہ تصدیق کے انعام کا حساب لگانے کے لیے بنیادی انعام کو شمولیت میں تاخیر کے معکوس سے ضرب دیا جاتا ہے۔ + +### تصدیق کے منظرنامے {#attestation-scenarios} + +#### گمشدہ ووٹنگ ویلیڈیٹر {#missing-voting-validator} + +ویلیڈیٹرز کے پاس اپنی تصدیق جمع کرانے کے لیے زیادہ سے زیادہ 1 ایپوک ہوتا ہے۔ اگر ایپوک 0 میں تصدیق چھوٹ گئی تھی، تو وہ اسے ایپوک 1 میں شمولیت میں تاخیر کے ساتھ جمع کرا سکتے ہیں۔ + +#### گمشدہ ایگریگیٹر {#missing-aggregator} + +کل ملا کر ہر ایپوک میں 16 ایگریگیٹرز ہوتے ہیں۔ اس کے علاوہ، بے ترتیب ویلیڈیٹرز **256 ایپوکس کے لیے دو سب نیٹس** کو سبسکرائب کرتے ہیں اور ایگریگیٹرز کے گم ہونے کی صورت میں بیک اپ کے طور پر کام کرتے ہیں۔ + +#### گمشدہ بلاک پروپوزر {#missing-block-proposer} + +نوٹ کریں کہ کچھ معاملات میں ایک خوش قسمت ایگریگیٹر بلاک پروپوزر بھی بن سکتا ہے۔ اگر بلاک پروپوزر کے گم ہو جانے کی وجہ سے تصدیق شامل نہیں کی گئی تھی، تو اگلا بلاک پروپوزر مجموعی تصدیق کو اٹھا کر اگلے بلاک میں شامل کر دے گا۔ تاہم، **شمولیت میں تاخیر** میں ایک کا اضافہ ہو جائے گا۔ + +## مزید پڑھیں {#further-reading} + +- [Vitalik کی اینوٹیٹڈ کنسنسس اسپیک میں تصدیقات](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [eth2book.info میں تصدیقات](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..a4a1664b5d8 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "بلاک کی تجویز" +description: "پروف آف اسٹیک Ethereum میں بلاکس کی تجویز کیسے دی جاتی ہے اس کی وضاحت۔" +lang: ur-in +--- + +بلاک چین کی بنیادی اکائیاں بلاکس ہیں۔ بلاکس معلومات کی مجرد اکائیاں ہیں جو نوڈس کے درمیان منتقل ہوتی ہیں، ان پر اتفاق کیا جاتا ہے اور ہر نوڈ کے ڈیٹا بیس میں شامل کی جاتی ہیں۔ یہ صفحہ وضاحت کرتا ہے کہ وہ کیسے تیار کیے جاتے ہیں۔ + +## شرائط {#prerequisites} + +بلاک کی تجویز پروف آف اسٹیک پروٹوکول کا حصہ ہے۔ اس صفحہ کو سمجھنے میں مدد کے لیے، ہم تجویز کرتے ہیں کہ آپ [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) اور [block architecture](/developers/docs/blocks/) کے بارے میں پڑھیں۔ + +## بلاکس کون تیار کرتا ہے؟ {#who-produces-blocks} + +ویلیڈیٹر اکاؤنٹس بلاکس کی تجویز دیتے ہیں۔ ویلیڈیٹر اکاؤنٹس کو نوڈ آپریٹرز کے ذریعے منظم کیا جاتا ہے جو اپنے ایگزیکیوشن اور کنسینسس کلائنٹس کے حصے کے طور پر ویلیڈیٹر سافٹ ویئر چلاتے ہیں اور انہوں نے ڈیپازٹ کنٹریکٹ میں کم از کم 32 ETH جمع کرائے ہیں۔ تاہم، ہر ویلیڈیٹر صرف کبھی کبھار ہی ایک بلاک کی تجویز دینے کا ذمہ دار ہوتا ہے۔ Ethereum وقت کی پیمائش سلاٹس اور ایپوکس میں کرتا ہے۔ ہر سلاٹ بارہ سیکنڈ کا ہوتا ہے، اور 32 سلاٹس (6.4 منٹ) مل کر ایک ایپوک بناتے ہیں۔ ہر سلاٹ Ethereum پر ایک نیا بلاک شامل کرنے کا ایک موقع ہوتا ہے۔ + +### بے ترتیب انتخاب {#random-selection} + +ہر سلاٹ میں ایک بلاک کی تجویز دینے کے لیے ایک واحد ویلیڈیٹر کو نیم بے ترتیب طور پر منتخب کیا جاتا ہے۔ بلاک چین میں حقیقی بے ترتیبی جیسی کوئی چیز نہیں ہے کیونکہ اگر ہر نوڈ حقیقی طور پر بے ترتیب نمبر تیار کرتا، تو وہ اتفاق رائے پر نہیں پہنچ سکتے۔ اس کے بجائے، مقصد ویلیڈیٹر کے انتخاب کے عمل کو غیر متوقع بنانا ہے۔ Ethereum پر بے ترتیبی RANDAO نامی ایک الگورتھم کا استعمال کرتے ہوئے حاصل کی جاتی ہے جو بلاک پروپوزر سے ایک ہیش کو ایک سیڈ کے ساتھ ملاتا ہے جو ہر بلاک پر اپ ڈیٹ ہوتا ہے۔ یہ قدر کل ویلیڈیٹر سیٹ سے ایک مخصوص ویلیڈیٹر کو منتخب کرنے کے لیے استعمال کی جاتی ہے۔ بعض قسم کی سیڈ کی ہیرا پھیری سے بچانے کے ایک طریقے کے طور پر ویلیڈیٹر کا انتخاب دو ایپوکس پہلے سے طے کیا جاتا ہے۔ + +اگرچہ ویلیڈیٹرز ہر سلاٹ میں RANDAO میں اضافہ کرتے ہیں، لیکن عالمی RANDAO ویلیو ہر ایپوک میں صرف ایک بار اپ ڈیٹ ہوتی ہے۔ اگلے بلاک پروپوزر کے انڈیکس کا حساب لگانے کے لیے، RANDAO ویلیو کو سلاٹ نمبر کے ساتھ ملایا جاتا ہے تاکہ ہر سلاٹ میں ایک منفرد ویلیو حاصل ہو۔ کسی انفرادی ویلیڈیٹر کے منتخب ہونے کا امکان صرف `1/N` نہیں ہے (جہاں `N` = کل فعال ویلیڈیٹرز)۔ اس کے بجائے، اسے ہر ویلیڈیٹر کے مؤثر ETH بیلنس کے حساب سے وزن دیا جاتا ہے۔ زیادہ سے زیادہ مؤثر بیلنس 32 ETH ہے (اس کا مطلب ہے کہ `balance < 32 ETH` کا وزن `balance == 32 ETH` سے کم ہوتا ہے، لیکن `balance > 32 ETH` کا وزن `balance == 32 ETH` سے زیادہ نہیں ہوتا)۔ + +ہر سلاٹ میں صرف ایک بلاک پروپوزر منتخب کیا جاتا ہے۔ عام حالات میں، ایک واحد بلاک پروڈیوسر اپنے مخصوص سلاٹ میں ایک ہی بلاک بناتا اور جاری کرتا ہے۔ ایک ہی سلاٹ کے لیے دو بلاکس بنانا ایک سلیش ایبل جرم ہے، جسے اکثر "equivocation" کہا جاتا ہے۔ + +## بلاک کیسے بنایا جاتا ہے؟ {#how-is-a-block-created} + +بلاک پروپوزر سے توقع کی جاتی ہے کہ وہ اپنے مقامی طور پر چلنے والے فورک چوائس الگورتھم کے مطابق چین کے سب سے حالیہ ہیڈ پر بننے والے ایک دستخط شدہ بیکن بلاک کو براڈکاسٹ کرے۔ فورک چوائس الگورتھم پچھلے سلاٹ سے بچی ہوئی کسی بھی قطار میں لگی تصدیقوں کو لاگو کرتا ہے، پھر اپنی تاریخ میں تصدیقوں کے سب سے زیادہ جمع شدہ وزن والے بلاک کو تلاش کرتا ہے۔ وہ بلاک پروپوزر کے ذریعہ بنائے گئے نئے بلاک کا پیرنٹ ہوتا ہے۔ + +بلاک پروپوزر اپنے مقامی ڈیٹا بیس اور چین کے ویو سے ڈیٹا اکٹھا کرکے ایک بلاک بناتا ہے۔ بلاک کے مندرجات نیچے دیے گئے سنیپٹ میں دکھائے گئے ہیں: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +`randao_reveal` فیلڈ ایک قابل تصدیق بے ترتیب ویلیو لیتا ہے جسے بلاک پروپوزر موجودہ ایپوک نمبر پر دستخط کرکے بناتا ہے۔ `eth1_data` ڈیپازٹ کنٹریکٹ کے بارے میں بلاک پروپوزر کے ویو کے لیے ایک ووٹ ہے، جس میں ڈیپازٹ مرکل ٹرائی کی روٹ اور ڈیپازٹس کی کل تعداد شامل ہے جو نئے ڈیپازٹس کی تصدیق کو ممکن بناتی ہے۔ `graffiti` ایک اختیاری فیلڈ ہے جسے بلاک میں پیغام شامل کرنے کے لیے استعمال کیا جا سکتا ہے۔ `proposer_slashings` اور `attester_slashings` وہ فیلڈز ہیں جن میں اس بات کا ثبوت ہوتا ہے کہ پروپوزر کے چین کے ویو کے مطابق کچھ ویلیڈیٹرز نے سلیش ایبل جرائم کیے ہیں۔ `deposits` نئے ویلیڈیٹر ڈیپازٹس کی ایک فہرست ہے جن سے بلاک پروپوزر واقف ہے، اور `voluntary_exits` ان ویلیڈیٹرز کی ایک فہرست ہے جو باہر نکلنا چاہتے ہیں جن کے بارے میں بلاک پروپوزر نے کنسینسس لیئر گاسپ نیٹ ورک پر سنا ہے۔ `sync_aggregate` ایک ویکٹر ہے جو یہ دکھاتا ہے کہ کن ویلیڈیٹرز کو پہلے ایک سنک کمیٹی (ویلیڈیٹرز کا ایک سب سیٹ جو لائٹ کلائنٹ ڈیٹا پیش کرتا ہے) کو تفویض کیا گیا تھا اور انہوں نے ڈیٹا پر دستخط کرنے میں حصہ لیا تھا۔ + +`execution_payload` ایگزیکیوشن اور کنسینسس کلائنٹس کے درمیان ٹرانزیکشنز کے بارے میں معلومات کو منتقل کرنے کے قابل بناتا ہے۔ `execution_payload` ایگزیکیوشن ڈیٹا کا ایک بلاک ہے جو ایک بیکن بلاک کے اندر نیسٹ کیا جاتا ہے۔ `execution_payload` کے اندر موجود فیلڈز Ethereum یلو پیپر میں بیان کردہ بلاک کی ساخت کی عکاسی کرتے ہیں، سوائے اس کے کہ کوئی اومرز نہیں ہیں اور `difficulty` کی جگہ `prev_randao` موجود ہے۔ ایگزیکیوشن کلائنٹ کو ٹرانزیکشنز کے ایک مقامی پول تک رسائی حاصل ہے جس کے بارے میں اس نے اپنے گاسپ نیٹ ورک پر سنا ہے۔ یہ ٹرانزیکشنز مقامی طور پر ایگزیکیوٹ کی جاتی ہیں تاکہ ایک اپ ڈیٹ شدہ اسٹیٹ ٹرائی تیار ہو سکے جسے پوسٹ اسٹیٹ کہا جاتا ہے۔ ٹرانزیکشنز کو `execution_payload` میں `transactions` نامی فہرست کے طور پر شامل کیا جاتا ہے اور پوسٹ اسٹیٹ `state-root` فیلڈ میں فراہم کیا جاتا ہے۔ + +یہ تمام ڈیٹا ایک بیکن بلاک میں جمع کیا جاتا ہے، اس پر دستخط کیے جاتے ہیں، اور بلاک پروپوزر کے پیئرز کو براڈکاسٹ کیا جاتا ہے، جو اسے اپنے پیئرز تک پھیلاتے ہیں، وغیرہ۔ + +[blocks کی اناٹومی](/developers/docs/blocks) کے بارے میں مزید پڑھیں۔ + +## بلاک کا کیا ہوتا ہے؟ {#what-happens-to-blocks} + +بلاک کو بلاک پروپوزر کے مقامی ڈیٹا بیس میں شامل کیا جاتا ہے اور کنسینسس لیئر گاسپ نیٹ ورک پر پیئرز کو براڈکاسٹ کیا جاتا ہے۔ جب ایک ویلیڈیٹر کو بلاک موصول ہوتا ہے، تو وہ اس کے اندر موجود ڈیٹا کی تصدیق کرتا ہے، جس میں یہ جانچنا شامل ہے کہ بلاک کا پیرنٹ درست ہے، یہ درست سلاٹ سے مطابقت رکھتا ہے، پروپوزر انڈیکس متوقع ہے، RANDAO ریویل درست ہے اور یہ کہ پروپوزر کو سلیش نہیں کیا گیا ہے۔ `execution_payload` کو ان بنڈل کیا جاتا ہے، اور ویلیڈیٹر کا ایگزیکیوشن کلائنٹ مجوزہ اسٹیٹ کی تبدیلی کی جانچ کرنے کے لیے فہرست میں موجود ٹرانزیکشنز کو دوبارہ ایگزیکیوٹ کرتا ہے۔ یہ فرض کرتے ہوئے کہ بلاک ان تمام جانچوں سے گزر جاتا ہے، ہر ویلیڈیڈیٹر بلاک کو اپنی کینونیکل چین میں شامل کر لیتا ہے۔ پھر یہ عمل اگلے سلاٹ میں دوبارہ شروع ہوتا ہے۔ + +## بلاک کے انعامات {#block-rewards} + +بلاک پروپوزر کو اپنے کام کے لیے ادائیگی ملتی ہے۔ ایک `base_reward` ہوتا ہے جس کا حساب فعال ویلیڈیٹرز کی تعداد اور ان کے مؤثر بیلنس کے فنکشن کے طور پر کیا جاتا ہے۔ پھر بلاک پروپوزر کو بلاک میں شامل ہر درست تصدیق کے لیے `base_reward` کا ایک حصہ ملتا ہے؛ جتنے زیادہ ویلیڈیٹرز بلاک کی تصدیق کرتے ہیں، بلاک پروپوزر کا انعام اتنا ہی زیادہ ہوتا ہے۔ ان ویلیڈیٹرز کی رپورٹ کرنے پر بھی ایک انعام ہے جنہیں سلیش کیا جانا چاہیے، جو ہر سلیش کیے گئے ویلیڈیٹر کے لیے `1/512 * مؤثر بیلنس` کے برابر ہے۔ + +[انعامات اور جرمانوں کے بارے میں مزید](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## مزید پڑھیں {#further-reading} + +- [بلاکس کا تعارف](/developers/docs/blocks/) +- [پروف-آف-اسٹیک کا تعارف](/developers/docs/consensus-mechanisms/pos/) +- [Ethereum کنسینسس کی تفصیلات](https://github.com/ethereum/consensus-specs) +- [Gasper کا تعارف](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Ethereum کو اپ گریڈ کرنا](https://eth2book.info/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..169c1894116 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "اکثر پوچھے جانے والے سوالات" +description: "Proof-of-stake Ethereum پر اکثر پوچھے جانے والے سوالات۔" +lang: ur-in +--- + +## Proof-of-stake کیا ہے؟ {#what-is-proof-of-stake} + +Proof-of-stake ایک قسم کا الگورتھم ہے جو بلاک چینز کو سیکورٹی فراہم کر سکتا ہے یہ یقینی بنا کر کہ جو حملہ آور بددیانتی سے کام کرتے ہیں وہ اپنی قیمتی اثاثے کھو دیتے ہیں۔ Proof-of-stake سسٹمز کو ویلیڈیٹرز کے ایک سیٹ کی ضرورت ہوتی ہے تاکہ وہ کچھ اثاثے دستیاب کرائیں جنہیں تباہ کیا جا سکتا ہے اگر ویلیڈیٹر کسی ثابت شدہ بددیانت رویے میں ملوث ہو۔ Ethereum بلاک چین کو محفوظ بنانے کے لیے proof-of-stake میکانزم کا استعمال کرتا ہے۔ + +## Proof-of-stake کا موازنہ proof-of-work سے کیسے کیا جاتا ہے؟ {#comparison-to-proof-of-work} + +Proof-of-work اور proof-of-stake دونوں ایسے میکانزم ہیں جو بدنیتی پر مبنی اداکاروں کو نیٹ ورک کو اسپیم کرنے یا دھوکہ دہی سے معاشی طور پر روکتے ہیں۔ دونوں صورتوں میں، جو نوڈس اتفاق رائے میں فعال طور پر حصہ لیتے ہیں وہ کچھ اثاثہ "نیٹ ورک میں" ڈالتے ہیں جسے وہ بدسلوکی کرنے پر کھو دیں گے۔ + +Proof-of-work میں، یہ اثاثہ توانائی ہے۔ نوڈ، جسے مائنر کہا جاتا ہے، ایک الگورتھم چلاتا ہے جس کا مقصد کسی بھی دوسرے نوڈ سے زیادہ تیزی سے ایک قدر کا حساب لگانا ہے۔ سب سے تیز نوڈ کو چین میں ایک بلاک تجویز کرنے کا حق ہے۔ چین کی تاریخ کو تبدیل کرنے یا بلاک کی تجویز پر غلبہ حاصل کرنے کے لیے، ایک مائنر کے پاس اتنی کمپیوٹنگ طاقت ہونی چاہیے کہ وہ ہمیشہ ریس جیتے۔ یہ ممنوعہ طور پر مہنگا اور عمل میں لانا مشکل ہے، جو چین کو حملوں سے بچاتا ہے۔ Proof-of-work کا استعمال کرتے ہوئے "مائن" کرنے کے لیے درکار توانائی ایک حقیقی دنیا کا اثاثہ ہے جس کے لیے مائنرز ادائیگی کرتے ہیں۔ + +Proof-of-stake میں نوڈس، جنہیں ویلیڈیٹرز کہا جاتا ہے، کو واضح طور پر ایک سمارٹ کنٹریکٹ میں کرپٹو اثاثہ جمع کرنے کی ضرورت ہوتی ہے۔ اگر کوئی ویلیڈیٹر بدسلوکی کرتا ہے، تو اس کرپٹو کو تباہ کیا جا سکتا ہے کیونکہ وہ توانائی کے اخراجات کے ذریعے بالواسطہ طور پر اپنے اثاثوں کو چین میں "اسٹیک" کر رہے ہیں۔ + +Proof-of-work بہت زیادہ توانائی کا بھوکا ہے کیونکہ کان کنی کے عمل میں بجلی جلتی ہے۔ دوسری طرف، Proof-of-stake کے لیے صرف بہت کم توانائی کی ضرورت ہوتی ہے - Ethereum ویلیڈیٹرز Raspberry Pi جیسے کم طاقت والے ڈیوائس پر بھی چل سکتے ہیں۔ Ethereum کا proof-of-stake میکانزم proof-of-work سے زیادہ محفوظ سمجھا جاتا ہے کیونکہ حملہ کرنے کی لاگت زیادہ ہوتی ہے، اور حملہ آور کے لیے نتائج زیادہ سنگین ہوتے ہیں۔ + +Proof-of-work بمقابلہ proof-of-stake ایک متنازعہ موضوع ہے۔ [Vitalik Buterin کا بلاگ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) اور جسٹن ڈریک اور لن ایلڈن کے درمیان بحث دلائل کا ایک اچھا خلاصہ پیش کرتی ہے۔ + + + +## کیا proof-of-stake توانائی کے لحاظ سے موثر ہے؟ {#is-pos-energy-efficient} + +جی ہاں. ایک proof-of-stake نیٹ ورک پر نوڈس بہت کم توانائی استعمال کرتے ہیں۔ ایک تھرڈ پارٹی مطالعہ نے یہ نتیجہ اخذ کیا کہ پورا proof-of-stake Ethereum نیٹ ورک تقریباً 0.0026 TWh/yr استعمال کرتا ہے - جو صرف امریکہ میں گیمنگ سے تقریباً 13,000 گنا کم ہے۔ + +[Ethereum کی توانائی کی کھپت پر مزید](/energy-consumption/)۔ + +## کیا proof-of-stake محفوظ ہے؟ {#is-pos-secure} + +Ethereum کا proof-of-stake بہت محفوظ ہے۔ اس میکانزم پر لائیو ہونے سے پہلے آٹھ سال سے زیادہ عرصے تک سختی سے تحقیق، ترقی اور جانچ کی گئی۔ سیکورٹی کی ضمانتیں proof-of-work بلاک چینز سے مختلف ہیں۔ Proof-of-stake میں، بدنیتی پر مبنی ویلیڈیٹرز کو فعال طور پر سزا دی جا سکتی ہے ("slashed") اور ویلیڈیٹر سیٹ سے نکال دیا جا سکتا ہے، جس پر ETH کی کافی مقدار خرچ ہوتی ہے۔ Proof-of-work کے تحت، ایک حملہ آور اپنے حملے کو دہراتا رہ سکتا ہے جب تک کہ ان کے پاس کافی ہیش پاور ہو۔ Proof-of-work کے تحت کے مقابلے میں proof-of-stake Ethereum پر مساوی حملے کرنا بھی زیادہ مہنگا ہے۔ چین کی لائیونیس کو متاثر کرنے کے لیے، نیٹ ورک پر کل اسٹیک شدہ ایتھر کا کم از کم 33% درکار ہے (انتہائی پیچیدہ حملوں کے معاملات کے علاوہ جن کی کامیابی کا امکان انتہائی کم ہے)۔ مستقبل کے بلاکس کے مواد کو کنٹرول کرنے کے لیے، کل اسٹیک شدہ ETH کا کم از کم 51% درکار ہے، اور تاریخ کو دوبارہ لکھنے کے لیے، کل اسٹیک کے 66% سے زیادہ کی ضرورت ہے۔ Ethereum پروٹوکول ان اثاثوں کو 33% یا 51% حملے کے منظرناموں میں اور 66% حملے کے منظر نامے میں سماجی اتفاق رائے سے تباہ کر دے گا۔ + +- [حملہ آوروں سے Ethereum proof-of-stake کے دفاع پر مزید](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Proof-of-stake ڈیزائن پر مزید](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## کیا proof-of-stake Ethereum کو سستا بناتا ہے؟ {#does-pos-make-ethereum-cheaper} + +نہیں. ٹرانزیکشن بھیجنے کی لاگت (گیس فیس) کا تعین ایک متحرک فیس مارکیٹ سے ہوتا ہے جو نیٹ ورک کی زیادہ مانگ کے ساتھ بڑھتا ہے۔ اتفاق رائے کا طریقہ کار اس پر براہ راست اثر انداز نہیں ہوتا ہے۔ + +[گیس پر مزید](/developers/docs/gas)۔ + +## نوڈس، کلائنٹس اور ویلیڈیٹرز کیا ہیں؟ {#what-are-nodes-clients-and-validators} + +نوڈس Ethereum نیٹ ورک سے جڑے ہوئے کمپیوٹر ہیں۔ کلائنٹس وہ سافٹ ویئر ہیں جو وہ چلاتے ہیں جو کمپیوٹر کو نوڈ میں بدل دیتا ہے۔ کلائنٹس کی دو قسمیں ہیں: ایگزیکیوشن کلائنٹس اور کنسینسس کلائنٹس۔ نوڈ بنانے کے لیے دونوں کی ضرورت ہے۔ ایک ویلیڈیٹر کنسینسس کلائنٹ کے لیے ایک اختیاری ایڈ آن ہے جو نوڈ کو proof-of-stake کنسینسس میں حصہ لینے کے قابل بناتا ہے۔ اس کا مطلب ہے منتخب ہونے پر بلاکس بنانا اور تجویز کرنا اور نیٹ ورک پر جن بلاکس کے بارے میں وہ سنتے ہیں ان کی تصدیق کرنا۔ ویلیڈیٹر چلانے کے لیے، نوڈ آپریٹر کو ڈپازٹ کنٹریکٹ میں 32 ETH جمع کرنا ضروری ہے۔ + +- [نوڈس اور کلائنٹس پر مزید](/developers/docs/nodes-and-clients) +- [اسٹیکنگ پر مزید](/staking) + +## کیا proof-of-stake ایک نیا خیال ہے؟ {#is-pos-new} + +نہیں. BitcoinTalk پر ایک صارف نے 2011 میں Bitcoin کے اپ گریڈ کے طور پر [proof-of-stake کا بنیادی خیال پیش کیا](https://bitcointalk.org/index.php?topic=27787.0)۔ Ethereum Mainnet پر عمل درآمد کے لیے تیار ہونے میں گیارہ سال لگے۔ کچھ دیگر چینوں نے Ethereum سے پہلے proof-of-stake نافذ کیا، لیکن Ethereum کا مخصوص طریقہ کار نہیں (جسے Gasper کہا جاتا ہے)۔ + +## Ethereum کے proof-of-stake میں کیا خاص ہے؟ {#why-is-ethereum-pos-special} + +Ethereum کا proof-of-stake میکانزم اپنے ڈیزائن میں منفرد ہے۔ یہ ڈیزائن اور نافذ کیا جانے والا پہلا proof-of-stake میکانزم نہیں تھا، لیکن یہ سب سے زیادہ مضبوط ہے۔ Proof-of-stake میکانزم کو "Casper" کہا جاتا ہے۔ Casper یہ بتاتا ہے کہ بلاکس تجویز کرنے کے لیے ویلیڈیٹرز کا انتخاب کیسے کیا جاتا ہے، تصدیق کب اور کیسے کی جاتی ہے، تصدیق کی گنتی کیسے کی جاتی ہے، ویلیڈیٹرز کو دیے جانے والے انعامات اور جرمانے، سلیشنگ کی شرائط، فیل سیف میکانزم جیسے کہ غیر فعال لیک، اور "فائنیلٹی" کی شرائط۔ حتمیت ایک ایسی شرط ہے کہ ایک بلاک کو کینونیکل چین کا مستقل حصہ سمجھا جائے اس کے لیے نیٹ ورک پر کل اسٹیک شدہ ETH کے کم از کم 66% کے ذریعے ووٹ دیا جانا چاہیے۔ محققین نے Casper کو خاص طور پر Ethereum کے لیے تیار کیا، اور Ethereum اسے نافذ کرنے والا پہلا اور واحد بلاک چین ہے۔ + +Casper کے علاوہ، Ethereum کا proof-of-stake ایک فورک چوائس الگورتھم کا استعمال کرتا ہے جسے LMD-GHOST کہا جاتا ہے۔ اس کی ضرورت اس صورت میں ہوتی ہے جب کوئی ایسی حالت پیدا ہو جائے جہاں ایک ہی سلاٹ کے لیے دو بلاکس موجود ہوں۔ یہ بلاک چین کے دو فورک بناتا ہے۔ LMD-GHOST اس کو چنتا ہے جس میں تصدیق کا سب سے زیادہ "وزن" ہوتا ہے۔ وزن ویلیڈیٹرز کے موثر بیلنس سے وزنی تصدیق کی تعداد ہے۔ LMD-GHOST Ethereum کے لیے منفرد ہے۔ + +Casper اور LMD_GHOST کے امتزاج کو Gasper کہا جاتا ہے۔ + +[Gasper پر مزید](/developers/docs/consensus-mechanisms/pos/gasper/) + +## سلیشنگ کیا ہے؟ {#what-is-slashing} + +سلیشنگ ایک ویلیڈیٹر کے کچھ اسٹیک کی تباہی اور نیٹ ورک سے ویلیڈیٹر کو نکالنے کے لیے دیا جانے والا اصطلاح ہے۔ سلیشنگ میں کھو جانے والی ETH کی رقم سلیش کیے جانے والے ویلیڈیٹرز کی تعداد کے ساتھ بڑھتی ہے - اس کا مطلب ہے کہ سازش کرنے والے ویلیڈیٹرز کو افراد سے زیادہ سخت سزا ملتی ہے۔ + +[سلیشنگ پر مزید](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## ویلیڈیٹرز کو 32 ETH کی ضرورت کیوں ہے؟ {#why-32-eth} + +ویلیڈیٹرز کو ETH اسٹیک کرنا پڑتا ہے تاکہ اگر وہ بدسلوکی کریں تو ان کے پاس کھونے کے لیے کچھ ہو۔ انہیں خاص طور پر 32 ETH اسٹیک کرنے کی وجہ یہ ہے کہ نوڈس کو معمولی ہارڈویئر پر چلنے کے قابل بنانا ہے۔ اگر فی ویلیڈیٹر کم از کم ETH کم ہوتا، تو ویلیڈیٹرز کی تعداد اور اس وجہ سے ہر سلاٹ میں پروسیس کیے جانے والے پیغامات کی تعداد بڑھ جاتی، یعنی نوڈ چلانے کے لیے زیادہ طاقتور ہارڈویئر کی ضرورت ہوتی۔ + +## ویلیڈیٹرز کا انتخاب کیسے کیا جاتا ہے؟ {#how-are-validators-selected} + +ہر سلاٹ میں ایک بلاک تجویز کرنے کے لیے RANDAO نامی ایک الگورتھم کا استعمال کرتے ہوئے ایک واحد ویلیڈیٹر کو سیوڈو-رینڈملی طور پر منتخب کیا جاتا ہے جو بلاک پروپوزر سے ایک ہیش کو ایک سیڈ کے ساتھ ملاتا ہے جو ہر بلاک کو اپ ڈیٹ کرتا ہے۔ یہ قدر کل ویلیڈیٹر سیٹ سے ایک مخصوص ویلیڈیٹر کو منتخب کرنے کے لیے استعمال کی جاتی ہے۔ ویلیڈیٹر کا انتخاب دو ایپوکس پہلے سے طے شدہ ہے۔ + +[ویلیڈیٹر کے انتخاب پر مزید](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## اسٹیک گرائنڈنگ کیا ہے؟ {#what-is-stake-grinding} + +اسٹیک گرائنڈنگ proof-of-stake نیٹ ورکس پر حملے کی ایک قسم ہے جہاں حملہ آور ویلیڈیٹر سلیکشن الگورتھم کو اپنے ویلیڈیٹرز کے حق میں متعصب کرنے کی کوشش کرتا ہے۔ RANDAO پر اسٹیک گرائنڈنگ حملوں کے لیے کل اسٹیک شدہ ETH کا تقریباً نصف درکار ہوتا ہے۔ + +[اسٹیک گرائنڈنگ پر مزید](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## سوشل سلیشنگ کیا ہے؟ {#what-is-social-slashing} + +سوشل سلیشنگ کمیونٹی کی ایک حملے کے جواب میں بلاک چین کے ایک فورک کو مربوط کرنے کی صلاحیت ہے۔ یہ کمیونٹی کو ایک حملہ آور سے بازیافت کرنے کے قابل بناتا ہے جو ایک بے ایمان چین کو حتمی شکل دے رہا ہے۔ سوشل سلیشنگ کو سنسر شپ حملوں کے خلاف بھی استعمال کیا جا سکتا ہے۔ + +- [سوشل سلیشنگ پر مزید](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Vitalik Buterin آن سوشل سلیشنگ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## کیا مجھے سلیش کیا جائے گا؟ {#will-i-get-slashed} + +ایک ویلیڈیٹر کے طور پر، جب تک کہ آپ جان بوجھ کر بدنیتی پر مبنی رویے میں ملوث نہ ہوں، سلیش ہونا بہت مشکل ہے۔ سلیشنگ صرف بہت مخصوص منظرناموں میں نافذ کی جاتی ہے جہاں ویلیڈیٹرز ایک ہی سلاٹ کے لیے متعدد بلاکس تجویز کرتے ہیں یا اپنی تصدیق سے خود کو متصادم کرتے ہیں - یہ حادثاتی طور پر پیدا ہونے کا امکان بہت کم ہے۔ + +[سلیشنگ کی شرائط پر مزید](https://eth2book.info/altair/part2/incentives/slashing) + +## nothing-at-stake مسئلہ کیا ہے؟ {#what-is-nothing-at-stake-problem} + +nothing-at-stake مسئلہ کچھ proof-of-stake میکانزم کے ساتھ ایک تصوراتی مسئلہ ہے جہاں صرف انعامات ہوتے ہیں اور کوئی جرمانہ نہیں ہوتا ہے۔ اگر داؤ پر کچھ نہیں ہے تو، ایک عملی ویلیڈیٹر بلاک چین کے کسی بھی، یا یہاں تک کہ متعدد، فورکس کی تصدیق کرنے میں یکساں طور پر خوش ہے، کیونکہ اس سے ان کے انعامات میں اضافہ ہوتا ہے۔ Ethereum ایک کینونیکل چین کو یقینی بنانے کے لیے حتمی شرائط اور سلیشنگ کا استعمال کرتے ہوئے اس سے بچتا ہے۔ + +[nothing-at-stake مسئلے پر مزید](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## فورک چوائس الگورتھم کیا ہے؟ {#what-is-a-fork-choice-algorithm} + +ایک فورک چوائس الگورتھم ان اصولوں کو نافذ کرتا ہے جو یہ تعین کرتے ہیں کہ کون سی چین کینونیکل ہے۔ بہترین حالات میں، فورک چوائس کے اصول کی کوئی ضرورت نہیں ہے کیونکہ فی سلاٹ صرف ایک بلاک پروپوزر ہے اور اس میں سے انتخاب کرنے کے لیے ایک بلاک ہے۔ تاہم، کبھی کبھار، ایک ہی سلاٹ کے لیے متعدد بلاکس یا دیر سے پہنچنے والی معلومات اس بات کے لیے متعدد اختیارات کا باعث بنتی ہیں کہ چین کے سر کے قریب بلاکس کو کیسے منظم کیا جاتا ہے۔ ان صورتوں میں، تمام کلائنٹس کو کچھ اصولوں کو یکساں طور پر نافذ کرنا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ وہ سب بلاکس کی صحیح ترتیب کا انتخاب کرتے ہیں۔ فورک چوائس الگورتھم ان اصولوں کو انکوڈ کرتا ہے۔ + +Ethereum کا فورک چوائس الگورتھم LMD-GHOST کہلاتا ہے۔ یہ سب سے زیادہ وزن والے تصدیق کے ساتھ فورک کو چنتا ہے، یعنی جس کے لیے سب سے زیادہ اسٹیک شدہ ETH نے ووٹ دیا ہے۔ + +[LMD-GHOST پر مزید](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Proof-of-stake میں حتمیت کیا ہے؟ {#what-is-finality} + +Proof-of-stake میں حتمیت اس بات کی ضمانت ہے کہ ایک دیا گیا بلاک کینونیکل چین کا مستقل حصہ ہے اور اسے اس وقت تک واپس نہیں کیا جا سکتا جب تک کہ کوئی اتفاق رائے ناکام نہ ہو جائے جس میں حملہ آور کل اسٹیک شدہ ایتھر کا 33% جلا دیتا ہے۔ یہ "کرپٹو-اکنامک" حتمیت ہے، "پروبابلیسٹک فائنلٹی" کے برعکس جو proof-of-work بلاک چینز سے متعلق ہے۔ پروبابلیسٹک فائنلٹی میں، بلاکس کے لیے کوئی واضح حتمی/غیر حتمی حالتیں نہیں ہیں - یہ صرف اس بات کا امکان کم سے کم ہوتا جاتا ہے کہ ایک بلاک پرانا ہونے پر چین سے ہٹایا جا سکتا ہے، اور صارفین خود اس بات کا تعین کرتے ہیں کہ وہ کب کافی پراعتماد ہیں کہ ایک بلاک "محفوظ" ہے۔ کرپٹو-اکنامک حتمیت کے ساتھ، چیک پوائنٹ بلاکس کے جوڑوں کو 66% اسٹیک شدہ ایتھر کے ذریعے ووٹ دینا پڑتا ہے۔ اگر یہ شرط پوری ہو جاتی ہے، تو ان چیک پوائنٹس کے درمیان والے بلاکس کو واضح طور پر "فائنلائزڈ" کر دیا جاتا ہے۔ + +[حتمیت پر مزید](/developers/docs/consensus-mechanisms/pos/#finality) + +## "کمزور موضوعیت" کیا ہے؟ {#what-is-weak-subjectivity} + +کمزور موضوعیت proof-of-stake نیٹ ورکس کی ایک خصوصیت ہے جہاں بلاک چین کی موجودہ حالت کی تصدیق کے لیے سماجی معلومات کا استعمال کیا جاتا ہے۔ نئے نوڈس یا نوڈس جو طویل عرصے تک آف لائن رہنے کے بعد نیٹ ورک میں دوبارہ شامل ہو رہے ہیں انہیں حالیہ حالت دی جا سکتی ہے تاکہ نوڈ فوری طور پر دیکھ سکے کہ آیا وہ صحیح چین پر ہیں۔ ان حالتوں کو "کمزور موضوعیت چیک پوائنٹس" کے نام سے جانا جاتا ہے اور انہیں دوسرے نوڈ آپریٹرز سے آؤٹ آف بینڈ، یا بلاک ایکسپلوررز سے، یا کئی عوامی اختتامی پوائنٹس سے حاصل کیا جا سکتا ہے۔ + +[کمزور موضوعیت پر مزید](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## کیا proof-of-stake سنسر شپ مزاحم ہے؟ {#is-pos-censorship-resistant} + +سنسر شپ مزاحمت کو فی الحال ثابت کرنا مشکل ہے۔ تاہم، proof-of-work کے برعکس، proof-of-stake سنسر کرنے والے ویلیڈیٹرز کو سزا دینے کے لیے سلیشنگ کو مربوط کرنے کا اختیار پیش کرتا ہے۔ پروٹوکول میں آنے والی تبدیلیاں ہیں جو بلاک بلڈرز کو بلاک پروپوزر سے الگ کرتی ہیں اور ٹرانزیکشنز کی فہرستیں نافذ کرتی ہیں جنہیں بلڈرز کو ہر بلاک میں شامل کرنا ضروری ہے۔ اس تجویز کو پروپر بلڈر سیپریشن کہا جاتا ہے اور یہ ویلیڈیٹرز کو ٹرانزیکشنز کو سنسر کرنے سے روکنے میں مدد کرتا ہے۔ + +[پروپوزر-بلڈر علیحدگی پر مزید](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## کیا Ethereum کے proof-of-stake سسٹم پر 51% حملہ ہو سکتا ہے؟ {#pos-51-attack} + +جی ہاں. Proof-of-stake 51% حملوں کے لیے کمزور ہے، بالکل proof-of-work کی طرح۔ حملہ آور کو نیٹ ورک کی 51% ہیش پاور کی ضرورت کے بجائے، حملہ آور کو کل اسٹیک شدہ ETH کا 51% درکار ہے۔ ایک حملہ آور جو کل اسٹیک کا 51% جمع کرتا ہے اسے فورک چوائس الگورتھم کو کنٹرول کرنے کا موقع ملتا ہے۔ یہ حملہ آور کو بعض ٹرانزیکشنز کو سنسر کرنے، شارٹ رینج ری آرگس کرنے اور اپنے حق میں بلاکس کو دوبارہ ترتیب دے کر MEV نکالنے کے قابل بناتا ہے۔ + +[proof-of-stake پر حملوں پر مزید](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## سماجی ہم آہنگی کیا ہے، اور اس کی ضرورت کیوں ہے؟ {#what-is-social-coordination} + +سماجی ہم آہنگی Ethereum کے لیے دفاع کی آخری لائن ہے جو ایک ایماندار چین کو ایک ایسے حملے سے بازیافت کرنے کی اجازت دے گی جس نے بے ایمان بلاکس کو حتمی شکل دی تھی۔ اس معاملے میں، Ethereum کمیونٹی کو "آؤٹ آف بینڈ" کوآرڈینیٹ کرنا ہوگا اور ایک ایماندار اقلیتی فورک استعمال کرنے پر اتفاق کرنا ہوگا، اس عمل میں حملہ آور کے ویلیڈیٹرز کو سلیش کرنا ہوگا۔ اس کے لیے ایپس اور ایکسچینجز کو بھی ایماندار فورک کو تسلیم کرنے کی ضرورت ہوگی۔ + +[سماجی ہم آہنگی پر مزید پڑھیں](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## کیا proof-of-stake میں امیر اور امیر ہو جاتا ہے؟ {#do-rich-get-richer} + +کسی کے پاس جتنا زیادہ ETH اسٹیک کرنے کے لیے ہوگا، وہ اتنے ہی زیادہ ویلیڈیٹرز چلا سکتا ہے، اور اتنے ہی زیادہ انعامات وہ حاصل کر سکتا ہے۔ انعامات اسٹیک شدہ ETH کی رقم کے ساتھ لکیری طور پر بڑھتے ہیں، اور ہر ایک کو یکساں فیصد منافع ملتا ہے۔ Proof-of-work امیروں کو proof-of-stake سے زیادہ مالا مال کرتا ہے کیونکہ امیر کان کن جو بڑے پیمانے پر ہارڈویئر خریدتے ہیں وہ پیمانے کی معیشتوں سے فائدہ اٹھاتے ہیں، یعنی دولت اور انعام کے درمیان تعلق غیر لکیری ہے۔ + +## کیا proof-of-stake proof-of-work سے زیادہ مرکزیت رکھتا ہے؟ {#is-pos-decentralized} + +نہیں، proof-of-work مرکزیت کی طرف مائل ہوتا ہے کیونکہ کان کنی کے اخراجات بڑھتے ہیں اور افراد کو قیمت سے باہر کر دیتے ہیں، پھر چھوٹی کمپنیوں کو قیمت سے باہر کر دیتے ہیں، وغیرہ۔ proof-of-stake کے ساتھ موجودہ مسئلہ مائع اسٹیکنگ ڈیریویٹوز (LSDs) کا اثر ہے۔ یہ ٹوکنز ہیں جو کسی فراہم کنندہ کے ذریعے اسٹیک کیے گئے ETH کی نمائندگی کرتے ہیں جسے کوئی بھی ثانوی بازاروں میں تبادلہ کر سکتا ہے بغیر اصل ETH کو ان اسٹیک کیے۔ LSDs صارفین کو 32 ETH سے کم کے ساتھ اسٹیک کرنے کی اجازت دیتے ہیں، لیکن وہ مرکزیت کا خطرہ بھی پیدا کرتے ہیں جہاں چند بڑی تنظیمیں زیادہ تر اسٹیک کو کنٹرول کر سکتی ہیں۔ یہی وجہ ہے کہ [سولو اسٹیکنگ](/staking/solo) Ethereum کے لیے بہترین آپشن ہے۔ + +[LSDs میں اسٹیک سنٹرلائزیشن پر مزید](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## میں صرف ETH کیوں اسٹیک کر سکتا ہوں؟ {#why-can-i-only-stake-eth} + +ETH Ethereum کی مقامی کرنسی ہے۔ یہ ضروری ہے کہ ایک واحد کرنسی ہو جس میں تمام اسٹیکز کو نامزد کیا گیا ہو، دونوں ووٹوں اور سیکیورٹی کے وزن کے لیے موثر بیلنس کا حساب کتاب کرنے کے لیے۔ ETH خود ایک سمارٹ کنٹریکٹ کے بجائے Ethereum کا ایک بنیادی جزو ہے۔ دیگر کرنسیوں کو شامل کرنے سے پیچیدگی میں نمایاں اضافہ ہوگا اور اسٹیکنگ کی سیکیورٹی میں کمی آئے گی۔ + +## کیا Ethereum واحد proof-of-stake بلاک چین ہے؟ {#is-ethereum-the-only-pos-blockchain} + +نہیں، کئی proof-of-stake بلاک چینز ہیں۔ کوئی بھی Ethereum سے مماثل نہیں ہے؛ Ethereum کا proof-of-stake میکانزم منفرد ہے۔ + +## مرج کیا ہے؟ {#what-is-the-merge} + +مرج وہ لمحہ تھا جب Ethereum نے اپنے proof-of-work پر مبنی اتفاق رائے کے طریقہ کار کو بند کر دیا اور اپنے proof-of-stake پر مبنی اتفاق رائے کے طریقہ کار کو آن کر دیا۔ مرج 15 ستمبر 2022 کو ہوا۔ + +[مرج پر مزید](/roadmap/merge) + +## لائیونیس اور سیفٹی کیا ہیں؟ {#what-are-liveness-and-safety} + +لائیونیس اور سیفٹی ایک بلاک چین کے لیے دو بنیادی سیکورٹی خدشات ہیں۔ لائیونیس ایک حتمی چین کی دستیابی ہے۔ اگر چین کو حتمی شکل دینا بند ہو جائے یا صارفین آسانی سے اس تک رسائی حاصل نہ کر پائیں تو یہ لائیونیس کی ناکامیاں ہیں۔ رسائی کی انتہائی زیادہ لاگت کو بھی لائیونیس کی ناکامی سمجھا جا سکتا ہے۔ حفاظت سے مراد یہ ہے کہ چین پر حملہ کرنا کتنا مشکل ہے - یعنی متصادم چیک پوائنٹس کو حتمی شکل دینا۔ + +[Casper پیپر میں مزید پڑھیں](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..c39eb6f68ac --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Gasper پروف آف اسٹیک میکانزم کی وضاحت۔" +lang: ur-in +--- + +Gasper, Casper the Friendly Finality Gadget (Casper-FFG) اور LMD-GHOST فورک چوائس الگورتھم کا ایک امتزاج ہے۔ یہ اجزاء مل کر پروف آف اسٹیک Ethereum کو محفوظ بنانے والا کنسینسس میکانزم بناتے ہیں۔ Casper وہ میکانزم ہے جو بعض بلاکس کو "finalized" میں اپ گریڈ کرتا ہے تاکہ نیٹ ورک میں نئے داخل ہونے والے اس بات پر یقین کر سکیں کہ وہ کینونیکل چین کو مطابقت پذیر کر رہے ہیں۔ فورک چوائس الگورتھم جمع شدہ ووٹوں کا استعمال اس بات کو یقینی بنانے کے لیے کرتا ہے کہ بلاک چین میں جب فورکس پیدا ہوں تو نوڈز آسانی سے درست کا انتخاب کر سکیں۔ + +**نوٹ** کریں کہ Gasper میں شمولیت کے لیے Casper-FFG کی اصل تعریف کو قدرے اپ ڈیٹ کیا گیا تھا۔ اس صفحہ پر ہم اپ ڈیٹ کردہ ورژن پر غور کرتے ہیں۔ + +## شرائط + +اس مواد کو سمجھنے کے لیے [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) پر تعارفی صفحہ پڑھنا ضروری ہے۔ + +## Gasper کا کردار {#role-of-gasper} + +Gasper پروف آف اسٹیک بلاک چین کے اوپر ہے جہاں نوڈز سیکیورٹی ڈپازٹ کے طور پر ایتھر فراہم کرتے ہیں جسے تباہ کیا جا سکتا ہے اگر وہ بلاکس کی تجویز یا توثیق کرنے میں سست یا بے ایمان ہوں۔ Gasper وہ میکانزم ہے جو یہ بتاتا ہے کہ توثیق کاروں کو کس طرح انعام اور سزا دی جاتی ہے، یہ فیصلہ کرتا ہے کہ کون سے بلاکس کو قبول اور مسترد کرنا ہے، اور بلاک چین کے کس فورک پر تعمیر کرنا ہے۔ + +## حتمیت کیا ہے؟ {#what-is-finality} + +حتمیت بعض بلاکس کی ایک خصوصیت ہے جس کا مطلب ہے کہ انہیں اس وقت تک واپس نہیں کیا جا سکتا جب تک کہ کوئی اہم اتفاق رائے کی ناکامی نہ ہوئی ہو اور کسی حملہ آور نے کل اسٹیک شدہ ایتھر کا کم از کم 1/3 حصہ تباہ نہ کر دیا ہو۔ حتمی شکل دیے گئے بلاکس کو ایسی معلومات کے طور پر سمجھا جا سکتا ہے جس کے بارے میں بلاک چین کو یقین ہے۔ ایک بلاک کو حتمی شکل دینے کے لیے اسے دو قدمی اپ گریڈ کے طریقہ کار سے گزرنا ہوگا: + +1. کل اسٹیک شدہ ایتھر کے دو تہائی نے اس بلاک کو کینونیکل چین میں شامل کرنے کے حق میں ووٹ دیا ہو۔ یہ شرط بلاک کو "justified" میں اپ گریڈ کرتی ہے۔ جسٹیفائڈ بلاکس کے واپس ہونے کا امکان نہیں ہے، لیکن وہ کچھ شرائط کے تحت ہو سکتے ہیں۔ +2. جب کسی جسٹیفائڈ بلاک کے اوپر دوسرے بلاک کو جسٹیفائڈ کیا جاتا ہے، تو اسے "finalized" میں اپ گریڈ کیا جاتا ہے۔ بلاک کو حتمی شکل دینا اس بلاک کو کینونیکل چین میں شامل کرنے کا ایک عزم ہے۔ اسے اس وقت تک واپس نہیں کیا جا سکتا جب تک کہ کوئی حملہ آور لاکھوں ایتھر (اربوں $USD) تباہ نہ کر دے۔ + +یہ بلاک اپ گریڈ ہر سلاٹ میں نہیں ہوتے ہیں۔ اس کے بجائے، صرف ایپوک-باؤنڈری بلاکس کو جسٹیفائی اور فائنلائز کیا جا سکتا ہے۔ ان بلاکس کو "checkpoints" کے نام سے جانا جاتا ہے۔ اپ گریڈنگ چیک پوائنٹس کے جوڑوں پر غور کرتی ہے۔ دو لگاتار چیک پوائنٹس کے درمیان ایک "سپر میجورٹی لنک" موجود ہونا چاہیے (یعنی، کل اسٹیک شدہ ایتھر کے دو تہائی کا ووٹ دینا کہ چیک پوائنٹ B چیک پوائنٹ A کا صحیح جانشین ہے) تاکہ کم حالیہ چیک پوائنٹ کو فائنلائز کیا جا سکے اور زیادہ حالیہ بلاک کو جسٹیفائی کیا جا سکے۔ + +چونکہ حتمیت کے لیے دو تہائی معاہدے کی ضرورت ہوتی ہے کہ ایک بلاک کینونیکل ہے، اس لیے کوئی حملہ آور اس کے بغیر متبادل حتمی چین نہیں بنا سکتا: + +1. کل اسٹیک شدہ ایتھر کے دو تہائی کی ملکیت یا اس میں ہیرا پھیری کرنا۔ +2. کل اسٹیک شدہ ایتھر کا کم از کم ایک تہائی تباہ کرنا۔ + +پہلی شرط اس لیے پیدا ہوتی ہے کیونکہ ایک چین کو حتمی شکل دینے کے لیے اسٹیک شدہ ایتھر کے دو تہائی کی ضرورت ہوتی ہے۔ دوسری شرط اس لیے پیدا ہوتی ہے کیونکہ اگر کل اسٹیک کے دو تہائی نے دونوں فورکس کے حق میں ووٹ دیا ہے، تو ایک تہائی نے دونوں پر ووٹ دیا ہوگا۔ ڈبل ووٹنگ ایک سلیشنگ شرط ہے جس پر زیادہ سے زیادہ سزا دی جائے گی، اور کل اسٹیک کا ایک تہائی تباہ ہو جائے گا۔ مئی 2022 تک، اس کے لیے ایک حملہ آور کو تقریباً 10 بلین ڈالر مالیت کا ایتھر جلانے کی ضرورت ہے۔ Gasper میں بلاکس کو جسٹیفائی اور فائنلائز کرنے والا الگورتھم [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) کی قدرے ترمیم شدہ شکل ہے۔ + +### مراعات اور سلیشنگ {#incentives-and-slashing} + +توثیق کاروں کو ایمانداری سے بلاکس کی تجویز اور توثیق کرنے پر انعام ملتا ہے۔ ایتھر کا انعام دیا جاتا ہے اور ان کے اسٹیک میں شامل کیا جاتا ہے۔ دوسری طرف، وہ توثیق کار جو غیر حاضر ہیں اور بلائے جانے پر کام کرنے میں ناکام رہتے ہیں، ان انعامات سے محروم رہ جاتے ہیں اور کبھی کبھی اپنے موجودہ اسٹیک کا ایک چھوٹا سا حصہ کھو دیتے ہیں۔ تاہم، آف لائن ہونے کے جرمانے چھوٹے ہیں اور، زیادہ تر معاملات میں، انعامات سے محروم ہونے کی موقع کی لاگت کے برابر ہیں۔ تاہم، کچھ توثیق کار کے اعمال غلطی سے کرنا بہت مشکل ہیں اور کچھ بدنیتی پر مبنی ارادے کی نشاندہی کرتے ہیں، جیسے کہ ایک ہی سلاٹ کے لیے متعدد بلاکس کی تجویز دینا، ایک ہی سلاٹ کے لیے متعدد بلاکس کی تصدیق کرنا، یا پچھلے چیک پوائنٹ ووٹوں سے متصادم ہونا۔ یہ "سلیش ایبل" رویے ہیں جن پر زیادہ سختی سے سزا دی جاتی ہے—سلیشنگ کے نتیجے میں توثیق کار کے اسٹیک کا کچھ حصہ تباہ ہو جاتا ہے اور توثیق کار کو توثیق کاروں کے نیٹ ورک سے ہٹا دیا جاتا ہے۔ اس عمل میں 36 دن لگتے ہیں۔ پہلے دن، 1 ETH تک کا ابتدائی جرمانہ ہے۔ پھر سلیش شدہ توثیق کار کا ایتھر ایگزٹ پیریڈ کے دوران آہستہ آہستہ ختم ہو جاتا ہے، لیکن 18 ویں دن، انہیں ایک "کوریلیشن پینلٹی" ملتی ہے، جو اس وقت بڑی ہوتی ہے جب ایک ہی وقت میں زیادہ توثیق کاروں کو سلیش کیا جاتا ہے۔ زیادہ سے زیادہ جرمانہ پورا اسٹیک ہے۔ یہ انعامات اور جرمانے ایماندار توثیق کاروں کی حوصلہ افزائی اور نیٹ ورک پر حملوں کی حوصلہ شکنی کے لیے بنائے گئے ہیں۔ + +### غیرفعالیت کا لیک {#inactivity-leak} + +سیکیورٹی کے ساتھ ساتھ، Gasper "قابل فہم لائیونیس" بھی فراہم کرتا ہے۔ یہ وہ شرط ہے کہ جب تک کل اسٹیک شدہ ایتھر کا دو تہائی ایمانداری سے ووٹ دے رہا ہے اور پروٹوکول کی پیروی کر رہا ہے، چین کسی بھی دوسری سرگرمی (جیسے حملے، لیٹینسی کے مسائل، یا سلیشنگز) سے قطع نظر حتمی شکل دے سکے گا۔ دوسرے لفظوں میں، چین کو حتمی شکل دینے سے روکنے کے لیے کل اسٹیک شدہ ایتھر کے ایک تہائی کے ساتھ کسی نہ کسی طرح سمجھوتہ کرنا ہوگا۔ Gasper میں، لائیونیس کی ناکامی کے خلاف دفاع کی ایک اضافی لائن ہے، جسے "غیرفعالیت کا لیک" کہا جاتا ہے۔ یہ میکانزم اس وقت فعال ہوتا ہے جب چین چار سے زیادہ ایپوکس تک حتمی شکل دینے میں ناکام ہو جاتا ہے۔ وہ توثیق کار جو اکثریتی چین کی فعال طور پر تصدیق نہیں کر رہے ہیں، ان کا اسٹیک آہستہ آہستہ ختم ہو جاتا ہے جب تک کہ اکثریت کل اسٹیک کا دو تہائی دوبارہ حاصل نہ کر لے، اس بات کو یقینی بناتے ہوئے کہ لائیونیس کی ناکامیاں صرف عارضی ہیں۔ + +### فورک کا انتخاب {#fork-choice} + +Casper-FFG کی اصل تعریف میں ایک فورک چوائس الگورتھم شامل تھا جس نے یہ اصول نافذ کیا تھا: `اس چین کی پیروی کریں جس میں سب سے زیادہ اونچائی والا جسٹیفائیڈ چیک پوائنٹ ہو` جہاں اونچائی کی تعریف جینیسس بلاک سے سب سے زیادہ فاصلہ کے طور پر کی گئی ہے۔ Gasper میں، اصل فورک چوائس اصول کو LMD-GHOST نامی ایک زیادہ نفیس الگورتھم کے حق میں متروک کر دیا گیا ہے۔ یہ سمجھنا ضروری ہے کہ عام حالات میں، ایک فورک چوائس اصول غیر ضروری ہے - ہر سلاٹ کے لیے ایک ہی بلاک پروپوزر ہوتا ہے، اور ایماندار توثیق کار اس کی تصدیق کرتے ہیں۔ یہ صرف بڑے نیٹ ورک کی غیر مطابقت پذیری کے معاملات میں یا جب کسی بے ایمان بلاک پروپوزر نے گول مول بات کی ہو، تب ہی ایک فورک چوائس الگورتھم کی ضرورت ہوتی ہے۔ تاہم، جب ایسے معاملات پیدا ہوتے ہیں، تو فورک چوائس الگورتھم ایک اہم دفاع ہے جو درست چین کو محفوظ بناتا ہے۔ + +LMD-GHOST کا مطلب ہے "latest message-driven greedy heaviest observed sub-tree"۔ یہ ایک الگورتھم کی تعریف کرنے کا ایک جارگن سے بھرا طریقہ ہے جو تصدیقوں کے سب سے بڑے جمع شدہ وزن والے فورک کو کینونیکل کے طور پر منتخب کرتا ہے (greedy heaviest subtree) اور یہ کہ اگر کسی توثیق کار سے متعدد پیغامات موصول ہوتے ہیں، تو صرف تازہ ترین پر غور کیا جاتا ہے (latest-message driven)۔ سب سے بھاری بلاک کو اپنی کینونیکل چین میں شامل کرنے سے پہلے، ہر توثیق کار اس اصول کا استعمال کرتے ہوئے ہر بلاک کا جائزہ لیتا ہے۔ + +## مزید مطالعہ {#further-reading} + +- [Gasper: GHOST اور Casper کا امتزاج](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..7636bc09a4b --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: "اسٹیک کا ثبوت (PoS)" +description: "اسٹیک کے ثبوت والے اتفاق رائے پروٹوکول اور ایتھیریم میں اس کے کردار کی وضاحت۔" +lang: ur-in +--- + +اسٹیک کا ثبوت (PoS) ایتھیریم کے [اتفاق رائے کے طریقہ کار](/developers/docs/consensus-mechanisms/) کی بنیاد ہے۔ ایتھیریم نے 2022 میں اپنے اسٹیک کے ثبوت کے طریقہ کار کو اپنایا کیونکہ یہ پچھلے [کام کے ثبوت](/developers/docs/consensus-mechanisms/pow) والے فن تعمیر کے مقابلے میں زیادہ محفوظ، کم توانائی خرچ کرنے والا، اور نئے اسکیلنگ حلوں کو نافذ کرنے کے لیے بہتر ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [اتفاق رائے کے طریقہ کار](/developers/docs/consensus-mechanisms/) کے بارے میں پڑھیں۔ + +## اسٹیک کا ثبوت (PoS) کیا ہے؟ {#what-is-pos} + +اسٹیک کا ثبوت یہ ثابت کرنے کا ایک طریقہ ہے کہ توثیق کاروں نے نیٹ ورک میں کوئی قیمتی چیز ڈالی ہے جسے تباہ کیا جا سکتا ہے اگر وہ بے ایمانی سے کام کرتے ہیں۔ ایتھیریم کے اسٹیک کے ثبوت میں، توثیق کار واضح طور پر ایتھیریم پر ایک اسمارٹ کنٹریکٹ میں ETH کی شکل میں سرمایہ لگاتے ہیں۔ پھر توثیق کار یہ جانچنے کا ذمہ دار ہوتا ہے کہ نیٹ ورک پر پھیلائے گئے نئے بلاکس درست ہیں اور کبھی کبھار خود نئے بلاکس بناتے اور پھیلاتے ہیں۔ اگر وہ نیٹ ورک کو دھوکہ دینے کی کوشش کرتے ہیں (مثال کے طور پر جب انہیں ایک بھیجنا چاہیے تو متعدد بلاکس کی تجویز دے کر یا متضاد تصدیقات بھیج کر)، تو ان کا لگایا گیا کچھ یا تمام ETH تباہ کیا جا سکتا ہے۔ + +## ویلیڈیٹرز {#validators} + +ایک توثیق کار کے طور پر حصہ لینے کے لیے، صارف کو ڈیپازٹ کنٹریکٹ میں 32 ETH جمع کرانا ہوگا اور تین الگ الگ سافٹ ویئر چلانے ہوں گے: ایک ایگزیکیوشن کلائنٹ، ایک کنسینسس کلائنٹ، اور ایک توثیق کار کلائنٹ۔ اپنا ETH جمع کرانے پر، صارف ایکٹیویشن قطار میں شامل ہو جاتا ہے جو نیٹ ورک میں شامل ہونے والے نئے توثیق کاروں کی شرح کو محدود کرتی ہے۔ ایک بار فعال ہونے کے بعد، توثیق کاروں کو ایتھیریم نیٹ ورک پر پیئرس سے نئے بلاکس موصول ہوتے ہیں۔ بلاک میں دی گئی ٹرانزیکشنز کو دوبارہ عمل میں لایا جاتا ہے تاکہ یہ جانچا جا سکے کہ ایتھیریم کی حالت میں مجوزہ تبدیلیاں درست ہیں، اور بلاک کے دستخط کی جانچ کی جاتی ہے۔ اس کے بعد توثیق کار نیٹ ورک پر اس بلاک کے حق میں ایک ووٹ (جسے تصدیق کہتے ہیں) بھیجتا ہے۔ + +جہاں کام کے ثبوت کے تحت، بلاکس کا وقت کان کنی کی مشکل سے طے ہوتا ہے، وہیں اسٹیک کے ثبوت میں، رفتار طے شدہ ہوتی ہے۔ اسٹیک کے ثبوت والے ایتھیریم میں وقت کو سلاٹس (12 سیکنڈ) اور عہدوں (32 سلاٹس) میں تقسیم کیا گیا ہے۔ ہر سلاٹ میں ایک توثیق کار کو تصادفی طور پر بلاک تجویز کنندہ کے طور پر منتخب کیا جاتا ہے۔ یہ توثیق کار ایک نیا بلاک بنانے اور اسے نیٹ ورک پر دوسرے نوڈس کو بھیجنے کا ذمہ دار ہے۔ ہر سلاٹ میں، توثیق کاروں کی ایک کمیٹی بھی تصادفی طور پر منتخب کی جاتی ہے، جن کے ووٹوں کا استعمال مجوزہ بلاک کی درستگی کا تعین کرنے کے لیے کیا جاتا ہے۔ توثیق کار کے سیٹ کو کمیٹیوں میں تقسیم کرنا نیٹ ورک کے بوجھ کو قابل انتظام رکھنے کے لیے اہم ہے۔ کمیٹیاں توثیق کار کے سیٹ کو اس طرح تقسیم کرتی ہیں کہ ہر فعال توثیق کار ہر عہد میں تصدیق کرتا ہے، لیکن ہر سلاٹ میں نہیں۔ + +## ایتھیریم PoS میں ایک ٹرانزیکشن کیسے عمل میں لائی جاتی ہے {#transaction-execution-ethereum-pos} + +مندرجہ ذیل میں اس بات کی مکمل وضاحت فراہم کی گئی ہے کہ ایتھیریم اسٹیک کے ثبوت میں ایک ٹرانزیکشن کیسے عمل میں لائی جاتی ہے۔ + +1. ایک صارف اپنی نجی کلید کے ساتھ ایک [ٹرانزیکشن](/developers/docs/transactions/) بناتا اور اس پر دستخط کرتا ہے۔ یہ عام طور پر ایک والیٹ یا لائبریری جیسے [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) وغیرہ کے ذریعے سنبھالا جاتا ہے لیکن درپردہ صارف ایتھیریم [JSON-RPC API](/developers/docs/apis/json-rpc/) کا استعمال کرتے ہوئے ایک نوڈ سے درخواست کر رہا ہوتا ہے۔ صارف گیس کی وہ مقدار متعین کرتا ہے جسے وہ ایک توثیق کار کو ٹپ کے طور پر ادا کرنے کے لیے تیار ہیں تاکہ انہیں ٹرانزیکشن کو بلاک میں شامل کرنے کی ترغیب دی جا سکے۔ [ٹپس](/developers/docs/gas/#priority-fee) توثیق کار کو ادا کی جاتی ہیں جبکہ [بیس فیس](/developers/docs/gas/#base-fee) جلا دی جاتی ہے۔ +2. ٹرانزیکشن ایک ایتھیریم [ایگزیکیوشن کلائنٹ](/developers/docs/nodes-and-clients/#execution-client) کو جمع کی جاتی ہے جو اس کی درستگی کی تصدیق کرتا ہے۔ اس کا مطلب یہ یقینی بنانا ہے کہ بھیجنے والے کے پاس ٹرانزیکشن کو پورا کرنے کے لیے کافی ETH ہے اور انہوں نے صحیح کلید سے اس پر دستخط کیے ہیں۔ +3. اگر ٹرانزیکشن درست ہے، تو ایگزیکیوشن کلائنٹ اسے اپنے مقامی میمپول (زیر التواء ٹرانزیکشنز کی فہرست) میں شامل کرتا ہے اور اسے ایگزیکیوشن لیئر گوسپ نیٹ ورک پر دوسرے نوڈس پر بھی نشر کرتا ہے۔ جب دوسرے نوڈس ٹرانزیکشن کے بارے میں سنتے ہیں تو وہ اسے اپنے مقامی میمپول میں بھی شامل کر لیتے ہیں۔ جدید صارفین اپنی ٹرانزیکشن کو نشر کرنے سے گریز کر سکتے ہیں اور اس کے بجائے اسے [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview) جیسے خصوصی بلاک بلڈرز کو بھیج سکتے ہیں۔ یہ انہیں زیادہ سے زیادہ منافع ([MEV](/developers/docs/mev/#mev-extraction)) کے لیے آنے والے بلاکس میں ٹرانزیکشنز کو منظم کرنے کی اجازت دیتا ہے۔ +4. نیٹ ورک پر موجود توثیق کار نوڈز میں سے ایک موجودہ سلاٹ کے لیے بلاک تجویز کنندہ ہے، جسے پہلے RANDAO کا استعمال کرتے ہوئے نیم تصادفی طور پر منتخب کیا گیا تھا۔ یہ نوڈ ایتھیریم بلاکچین میں شامل کیے جانے والے اگلے بلاک کی تعمیر اور نشر کرنے اور عالمی حالت کو اپ ڈیٹ کرنے کا ذمہ دار ہے۔ نوڈ تین حصوں پر مشتمل ہے: ایک ایگزیکیوشن کلائنٹ، ایک کنسینسس کلائنٹ اور ایک توثیق کار کلائنٹ۔ ایگزیکیوشن کلائنٹ مقامی میمپول سے ٹرانزیکشنز کو ایک "ایگزیکیوشن پے لوڈ" میں بنڈل کرتا ہے اور حالت میں تبدیلی پیدا کرنے کے لیے انہیں مقامی طور پر عمل میں لاتا ہے۔ یہ معلومات کنسینسس کلائنٹ کو بھیجی جاتی ہیں جہاں ایگزیکیوشن پے لوڈ کو "بیکن بلاک" کے حصے کے طور پر لپیٹا جاتا ہے جس میں انعامات، جرمانے، سلیشنگز، تصدیقات وغیرہ کے بارے میں معلومات بھی ہوتی ہیں جو نیٹ ورک کو چین کے سرے پر بلاکس کی ترتیب پر متفق ہونے کے قابل بناتی ہیں۔ ایگزیکیوشن اور کنسینسس کلائنٹس کے درمیان مواصلات کی مزید تفصیل [کنسینسس اور ایگزیکیوشن کلائنٹس کو جوڑنا](/developers/docs/networking-layer/#connecting-clients) میں بیان کی گئی ہے۔ +5. دیگر نوڈس کنسینسس لیئر گوسپ نیٹ ورک پر نیا بیکن بلاک وصول کرتے ہیں۔ وہ اسے اپنے ایگزیکیوشن کلائنٹ کو بھیجتے ہیں جہاں ٹرانزیکشنز کو مقامی طور پر دوبارہ عمل میں لایا جاتا ہے تاکہ یہ یقینی بنایا جا سکے کہ مجوزہ حالت میں تبدیلی درست ہے۔ اس کے بعد توثیق کار کلائنٹ تصدیق کرتا ہے کہ بلاک درست ہے اور چین کے بارے میں ان کے نظریے میں منطقی اگلا بلاک ہے (یعنی یہ [فورک کے انتخاب کے اصولوں](/developers/docs/consensus-mechanisms/pos/#fork-choice) میں بیان کردہ تصدیقات کے سب سے زیادہ وزن والی چین پر بنتا ہے)۔ بلاک ہر اس نوڈ میں مقامی ڈیٹا بیس میں شامل کیا جاتا ہے جو اس کی تصدیق کرتا ہے۔ +6. ٹرانزیکشن کو "حتمی شکل" دی گئی سمجھا جا سکتا ہے اگر یہ دو چیک پوائنٹس کے درمیان "سپر میجورٹی لنک" والی چین کا حصہ بن گیا ہو۔ چیک پوائنٹس ہر عہد کے آغاز میں ہوتے ہیں اور وہ اس حقیقت کا حساب رکھنے کے لیے موجود ہیں کہ فعال توثیق کاروں کا صرف ایک ذیلی سیٹ ہر سلاٹ میں تصدیق کرتا ہے، لیکن تمام فعال توثیق کار ہر عہد میں تصدیق کرتے ہیں۔ لہذا، یہ صرف عہدوں کے درمیان ہے کہ 'سپر میجورٹی لنک' کا مظاہرہ کیا جا سکتا ہے (یہ وہ جگہ ہے جہاں نیٹ ورک پر کل لگائے گئے ETH کا 66% دو چیک پوائنٹس پر متفق ہوتا ہے)۔ + +حتمیت کے بارے میں مزید تفصیلات ذیل میں مل سکتی ہیں۔ + +## حتمیت {#finality} + +تقسیم شدہ نیٹ ورکس میں ایک ٹرانزیکشن کی "حتمیت" تب ہوتی ہے جب وہ ایک ایسے بلاک کا حصہ ہو جسے بڑی مقدار میں ETH جلائے بغیر تبدیل نہیں کیا جا سکتا۔ اسٹیک کے ثبوت والے ایتھیریم پر، اس کا انتظام "چیک پوائنٹ" بلاکس کا استعمال کرتے ہوئے کیا جاتا ہے۔ ہر عہد میں پہلا بلاک ایک چیک پوائنٹ ہوتا ہے۔ توثیق کار چیک پوائنٹس کے جوڑوں کے لیے ووٹ دیتے ہیں جنہیں وہ درست سمجھتے ہیں۔ اگر چیک پوائنٹس کا ایک جوڑا کل لگائے گئے ETH کے کم از کم دو تہائی کی نمائندگی کرنے والے ووٹوں کو راغب کرتا ہے، تو چیک پوائنٹس کو اپ گریڈ کیا جاتا ہے۔ دونوں میں سے حالیہ (ہدف) "جائز" ہو جاتا ہے۔ دونوں میں سے پہلا پہلے ہی جائز ہے کیونکہ یہ پچھلے عہد میں "ہدف" تھا۔ اب اسے "حتمی شکل" میں اپ گریڈ کر دیا گیا ہے۔ چیک پوائنٹس کو اپ گریڈ کرنے کا یہ عمل **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)** کے ذریعے سنبھالا جاتا ہے۔ Casper-FFG اتفاق رائے کے لیے ایک بلاک حتمیت کا ٹول ہے۔ ایک بار جب کسی بلاک کو حتمی شکل دے دی جاتی ہے، تو اسے اسٹیکرز کی اکثریت کی سلیشنگ کے بغیر واپس نہیں لیا جا سکتا یا تبدیل نہیں کیا جا سکتا، جو اسے معاشی طور پر ناقابل عمل بنا دیتا ہے۔ + +ایک حتمی بلاک کو واپس لانے کے لیے، ایک حملہ آور کل سپلائی کے لگائے گئے ETH کا کم از کم ایک تہائی کھونے کا عہد کرے گا۔ اس کی صحیح وجہ اس [ایتھیریم فاؤنڈیشن بلاگ پوسٹ](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) میں بیان کی گئی ہے۔ چونکہ حتمیت کے لیے دو تہائی اکثریت کی ضرورت ہوتی ہے، اس لیے ایک حملہ آور کل اسٹیک کے ایک تہائی کے ساتھ ووٹ دے کر نیٹ ورک کو حتمیت تک پہنچنے سے روک سکتا ہے۔ اس سے دفاع کے لیے ایک طریقہ کار ہے: [غیرفعالیت کا رساؤ](https://eth2book.info/bellatrix/part2/incentives/inactivity)۔ یہ تب فعال ہوتا ہے جب چین چار سے زیادہ عہدوں تک حتمی شکل دینے میں ناکام رہتی ہے۔ غیرفعالیت کا رساؤ اکثریت کے خلاف ووٹ دینے والے توثیق کاروں سے لگائے گئے ETH کو ختم کر دیتا ہے، جس سے اکثریت کو دو تہائی اکثریت دوبارہ حاصل کرنے اور چین کو حتمی شکل دینے کی اجازت ملتی ہے۔ + +## کرپٹو-معاشی سیکیورٹی {#crypto-economic-security} + +ایک توثیق کار چلانا ایک عزم ہے۔ توثیق کار سے توقع کی جاتی ہے کہ وہ بلاک کی توثیق اور تجویز میں حصہ لینے کے لیے کافی ہارڈ ویئر اور کنیکٹیویٹی کو برقرار رکھے۔ بدلے میں، توثیق کار کو ETH میں ادائیگی کی جاتی ہے (ان کا لگایا گیا بیلنس بڑھ جاتا ہے)۔ دوسری طرف، ایک توثیق کار کے طور پر حصہ لینا صارفین کے لیے ذاتی فائدے یا تخریب کاری کے لیے نیٹ ورک پر حملہ کرنے کے نئے راستے بھی کھولتا ہے۔ اسے روکنے کے لیے، توثیق کار بلائے جانے پر حصہ لینے میں ناکام ہونے پر ETH انعامات سے محروم ہو جاتے ہیں، اور اگر وہ بے ایمانی سے برتاؤ کرتے ہیں تو ان کا موجودہ اسٹیک تباہ کیا جا سکتا ہے۔ دو بنیادی رویوں کو بے ایمانی سمجھا جا سکتا ہے: ایک ہی سلاٹ میں متعدد بلاکس کی تجویز دینا (ابہام پیدا کرنا) اور متضاد تصدیقات جمع کرنا۔ + +سلیش کیے گئے ETH کی مقدار اس بات پر منحصر ہے کہ ایک ہی وقت میں کتنے توثیق کاروں کو سلیش کیا جا رہا ہے۔ اسے ["ارتباطی جرمانہ"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) کے نام سے جانا جاتا ہے، اور یہ معمولی ہو سکتا ہے (ایک واحد توثیق کار کے لیے ~1% اسٹیک جو خود سلیش ہو جاتا ہے) یا اس کے نتیجے میں توثیق کار کا 100% اسٹیک تباہ ہو سکتا ہے (بڑے پیمانے پر سلیشنگ کا واقعہ)۔ یہ ایک جبری اخراج کی مدت کے آدھے راستے میں نافذ کیا جاتا ہے جو پہلے دن فوری جرمانے (1 ETH تک) سے شروع ہوتا ہے، 18 ویں دن ارتباطی جرمانہ، اور آخر میں، 36 ویں دن نیٹ ورک سے اخراج۔ انہیں ہر روز معمولی تصدیقی جرمانے ملتے ہیں کیونکہ وہ نیٹ ورک پر موجود ہیں لیکن ووٹ جمع نہیں کر رہے ہیں۔ ان سب کا مطلب ہے کہ ایک مربوط حملہ حملہ آور کے لیے بہت مہنگا ہوگا۔ + +## فورک کا انتخاب {#fork-choice} + +جب نیٹ ورک بہترین اور ایمانداری سے کام کرتا ہے، تو چین کے سرے پر ہمیشہ صرف ایک نیا بلاک ہوتا ہے، اور تمام توثیق کار اس کی تصدیق کرتے ہیں۔ تاہم، یہ ممکن ہے کہ توثیق کاروں کے پاس نیٹ ورک کی تاخیر کی وجہ سے یا اس لیے کہ ایک بلاک تجویز کنندہ نے ابہام پیدا کیا ہے، چین کے سرے کے بارے میں مختلف نظریات ہوں۔ لہذا، کنسینسس کلائنٹس کو یہ فیصلہ کرنے کے لیے ایک الگورتھم کی ضرورت ہوتی ہے کہ کس کی حمایت کرنی ہے۔ اسٹیک کے ثبوت والے ایتھیریم میں استعمال ہونے والے الگورتھم کو [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) کہا جاتا ہے، اور یہ اس فورک کی شناخت کرکے کام کرتا ہے جس کی تاریخ میں تصدیقات کا سب سے زیادہ وزن ہوتا ہے۔ + +## اسٹیک کا ثبوت اور سیکیورٹی {#pos-and-security} + +کام کے ثبوت کی طرح اسٹیک کے ثبوت پر بھی [51% حملے](https://www.investopedia.com/terms/1/51-attack.asp) کا خطرہ اب بھی موجود ہے، لیکن یہ حملہ آوروں کے لیے اور بھی زیادہ خطرناک ہے۔ ایک حملہ آور کو لگائے گئے ETH کا 51% درکار ہوگا۔ پھر وہ اپنی تصدیقات کا استعمال اس بات کو یقینی بنانے کے لیے کر سکتے ہیں کہ ان کا ترجیحی فورک سب سے زیادہ جمع شدہ تصدیقات والا تھا۔ جمع شدہ تصدیقات کا 'وزن' وہ ہے جسے کنسینسس کلائنٹس صحیح چین کا تعین کرنے کے لیے استعمال کرتے ہیں، لہذا یہ حملہ آور اپنے فورک کو کینونیکل بنانے کے قابل ہو گا۔ تاہم، کام کے ثبوت پر اسٹیک کے ثبوت کی ایک طاقت یہ ہے کہ کمیونٹی کے پاس جوابی حملہ کرنے میں لچک ہے۔ مثال کے طور پر، ایماندار توثیق کار اقلیتی چین پر تعمیر جاری رکھنے اور حملہ آور کے فورک کو نظر انداز کرنے کا فیصلہ کر سکتے ہیں جبکہ ایپس، ایکسچینجز، اور پولز کو بھی ایسا کرنے کی ترغیب دے سکتے ہیں۔ وہ حملہ آور کو نیٹ ورک سے زبردستی ہٹانے اور ان کے لگائے گئے ETH کو تباہ کرنے کا فیصلہ بھی کر سکتے ہیں۔ یہ 51% حملے کے خلاف مضبوط معاشی دفاع ہیں۔ + +51% حملوں کے علاوہ، برے اداکار دیگر قسم کی بدنیتی پر مبنی سرگرمیوں کی کوشش بھی کر سکتے ہیں، جیسے: + +- طویل فاصلے کے حملے (اگرچہ حتمیت کا گیجٹ اس حملے کے ویکٹر کو بے اثر کر دیتا ہے) +- مختصر فاصلے کی 'ری آرگس' (اگرچہ تجویز کنندہ کو فروغ دینا اور تصدیق کی آخری تاریخیں اسے کم کرتی ہیں) +- باؤنسنگ اور بیلنسنگ حملے (تجویز کنندہ کو فروغ دینے سے بھی کم کیے جاتے ہیں، اور یہ حملے ویسے بھی صرف مثالی نیٹ ورک حالات کے تحت دکھائے گئے ہیں) +- ایوالانچ حملے (فورک کے انتخاب کے الگورتھم کے صرف تازہ ترین پیغام پر غور کرنے کے اصول سے بے اثر) + +مجموعی طور پر، اسٹیک کا ثبوت، جیسا کہ اسے ایتھیریم پر نافذ کیا گیا ہے، کام کے ثبوت سے زیادہ معاشی طور پر محفوظ ثابت ہوا ہے۔ + +## فائدے اور نقصانات {#pros-and-cons} + +| فوائد | نقصانات | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | +| اسٹیکنگ افراد کے لیے نیٹ ورک کو محفوظ بنانے میں حصہ لینا آسان بناتی ہے، جس سے وکندریقرت کو فروغ ملتا ہے۔ توثیق کار نوڈ کو ایک عام لیپ ٹاپ پر چلایا جا سکتا ہے۔ اسٹیکنگ پولز صارفین کو 32 ETH کے بغیر اسٹیک کرنے کی اجازت دیتے ہیں۔ | اسٹیک کا ثبوت کام کے ثبوت کے مقابلے میں نیا اور کم آزمودہ ہے۔ | +| اسٹیکنگ زیادہ وکندریقرت ہے۔ پیمانے کی معیشتیں اس طرح لاگو نہیں ہوتیں جس طرح وہ PoW کان کنی کے لیے ہوتی ہیں۔ | اسٹیک کا ثبوت کام کے ثبوت کے مقابلے میں نافذ کرنے کے لیے زیادہ پیچیدہ ہے۔ | +| اسٹیک کا ثبوت کام کے ثبوت کے مقابلے میں زیادہ کرپٹو-معاشی سیکیورٹی فراہم کرتا ہے۔ | صارفین کو ایتھیریم کے اسٹیک کے ثبوت میں حصہ لینے کے لیے تین سافٹ ویئر چلانے کی ضرورت ہے۔ | +| نیٹ ورک کے شرکاء کی حوصلہ افزائی کے لیے نئے ETH کا کم اجراء درکار ہے۔ | | + +### کام کے ثبوت سے موازنہ {#comparison-to-proof-of-work} + +ایتھیریم نے اصل میں کام کا ثبوت استعمال کیا تھا لیکن ستمبر 2022 میں اسٹیک کے ثبوت پر منتقل ہو گیا۔ PoS، PoW کے مقابلے میں کئی فوائد پیش کرتا ہے، جیسے: + +- بہتر توانائی کی کارکردگی - کام کے ثبوت کی گنتی پر بہت زیادہ توانائی استعمال کرنے کی ضرورت نہیں ہے۔ +- داخلے کی کم رکاوٹیں، ہارڈ ویئر کی کم ضروریات - نئے بلاکس بنانے کا موقع حاصل کرنے کے لیے ایلیٹ ہارڈ ویئر کی ضرورت نہیں ہے۔ +- مرکزیت کا کم خطرہ - اسٹیک کا ثبوت نیٹ ورک کو محفوظ بنانے والے مزید نوڈس کا باعث بننا چاہیے۔ +- کم توانائی کی ضرورت کی وجہ سے شرکت کی حوصلہ افزائی کے لیے کم ETH اجراء کی ضرورت ہوتی ہے۔ +- غلط برتاؤ کے لیے معاشی جرمانے 51% طرز کے حملوں کو کام کے ثبوت کے مقابلے میں حملہ آور کے لیے زیادہ مہنگا بنا دیتے ہیں۔ +- اگر 51% کا حملہ کرپٹو-معاشی دفاع پر قابو پانے میں کامیاب ہو جائے تو کمیونٹی ایک ایماندار چین کی سماجی بحالی کا سہارا لے سکتی ہے۔ + +## مزید پڑھیں {#further-reading} + +- [اسٹیک کے ثبوت کے متعلق اکثر پوچھے گئے سوالات](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [اسٹیک کا ثبوت کیا ہے](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [اسٹیک کا ثبوت کیا ہے اور یہ کیوں اہم ہے](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [اسٹیک کا ثبوت کیوں (نومبر 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [اسٹیک کا ثبوت: میں نے کمزور موضوعیت سے محبت کرنا کیسے سیکھا](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [اسٹیک کے ثبوت والے ایتھیریم پر حملہ اور دفاع](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [اسٹیک کے ثبوت کے ڈیزائن کا فلسفہ](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [ویڈیو: Vitalik Buterin لیکس فریڈمین کو اسٹیک کے ثبوت کی وضاحت کرتے ہوئے](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## متعلقہ موضوعات {#related-topics} + +- [ثبوتِ کار (Proof-of-work)](/developers/docs/consensus-mechanisms/pow/) +- [ثبوتِ اختیار (Proof-of-authority)](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..7926acfb137 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "Proof-of-stake Ethereum میں کلیدیں" +description: "Ethereum کے proof-of-stake اتفاق رائے کے طریقہ کار میں استعمال ہونے والی کلیدوں کی وضاحت" +lang: ur-in +--- + +Ethereum پبلک-پرائیویٹ کلیدی کرپٹوگرافی کا استعمال کرتے ہوئے صارف کے اثاثوں کو محفوظ بناتا ہے۔ پبلک کلید کو Ethereum ایڈریس کی بنیاد کے طور پر استعمال کیا جاتا ہے—یعنی، یہ عام لوگوں کو نظر آتی ہے اور ایک منفرد شناخت کنندہ کے طور پر استعمال ہوتی ہے۔ پرائیویٹ (یا 'خفیہ') کلید صرف ایک اکاؤنٹ کے مالک کے لیے قابل رسائی ہونی چاہیے۔ پرائیویٹ کلید کا استعمال ٹرانزیکشنز اور ڈیٹا کو 'سائن' کرنے کے لیے کیا جاتا ہے تاکہ کرپٹوگرافی یہ ثابت کر سکے کہ ہولڈر ایک مخصوص پرائیویٹ کلید کی کچھ کارروائی کو منظور کرتا ہے۔ + +Ethereum کی کلیدیں [elliptic-curve cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) کا استعمال کرتے ہوئے تیار کی جاتی ہیں۔ + +تاہم، جب Ethereum نے [proof-of-work](/developers/docs/consensus-mechanisms/pow) سے [proof-of-stake](/developers/docs/consensus-mechanisms/pos) میں سوئچ کیا تو Ethereum میں ایک نئی قسم کی کلید شامل کی گئی۔ اصل کلیدیں اب بھی بالکل پہلے کی طرح کام کرتی ہیں—اکاؤنٹس کو محفوظ کرنے والی elliptic-curve-based کلیدوں میں کوئی تبدیلی نہیں کی گئی تھی۔ تاہم، صارفین کو ETH اسٹیک کرکے اور ویلیڈیٹرز چلا کر proof-of-stake میں حصہ لینے کے لیے ایک نئی قسم کی کلید کی ضرورت تھی۔ یہ ضرورت بڑی تعداد میں ویلیڈیٹرز کے درمیان گزرنے والے بہت سے پیغامات سے وابستہ اسکیل ایبلٹی چیلنجز سے پیدا ہوئی، جس کے لیے ایک ایسے کرپٹوگرافک طریقہ کی ضرورت تھی جسے آسانی سے جمع کیا جا سکے تاکہ نیٹ ورک کو اتفاق رائے پر آنے کے لیے درکار مواصلات کی مقدار کو کم کیا جا سکے۔ + +کلید کی یہ نئی قسم [**Boneh-Lynn-Shacham (BLS)** سگنیچر اسکیم](https://wikipedia.org/wiki/BLS_digital_signature) کا استعمال کرتی ہے۔ BLS دستخطوں کے بہت موثر جمع کرنے کو ممکن بناتا ہے لیکن مجموعی انفرادی ویلیڈیٹر کلیدوں کی ریورس انجینئرنگ کی بھی اجازت دیتا ہے اور ویلیڈیٹرز کے درمیان کارروائیوں کا انتظام کرنے کے لیے مثالی ہے۔ + +## ویلیڈیٹر کلیدوں کی دو اقسام {#two-types-of-keys} + +proof-of-stake میں سوئچ کرنے سے پہلے، Ethereum صارفین کے پاس اپنے فنڈز تک رسائی کے لیے صرف ایک ہی elliptic-curve-based پرائیویٹ کلید تھی۔ proof-of-stake کے تعارف کے ساتھ، جو صارفین سولو اسٹیکرز بننا چاہتے تھے انہیں ایک **ویلیڈیٹر کلید** اور ایک **وڈراول کلید** کی بھی ضرورت تھی۔ + +### ویلیڈیٹر کلید {#validator-key} + +ویلیڈیٹر سائننگ کلید دو عناصر پر مشتمل ہے: + +- ویلیڈیٹر **پرائیویٹ** کلید +- ویلیڈیٹر **پبلک** کلید + +ویلیڈیٹر پرائیویٹ کلید کا مقصد آن چین آپریشنز جیسے کہ بلاک پروپوزل اور اٹیسٹیشنز پر دستخط کرنا ہے۔ اس کی وجہ سے، ان کلیدوں کو ہاٹ والیٹ میں رکھا جانا چاہیے۔ + +اس لچک کا فائدہ یہ ہے کہ ویلیڈیٹر سائننگ کلیدوں کو ایک ڈیوائس سے دوسری ڈیوائس میں بہت تیزی سے منتقل کیا جا سکتا ہے، تاہم، اگر وہ گم ہو جائیں یا چوری ہو جائیں، تو چور چند طریقوں سے **بدنیتی سے کام** کر سکتا ہے: + +- ویلیڈیٹر کو سلیش کروا کر: + - ایک پروپوزر ہونے کے ناطے اور ایک ہی سلاٹ کے لیے دو مختلف بیکن بلاکس پر دستخط کرنا + - ایک اٹیسٹر ہونے کے ناطے اور ایک ایسے اٹیسٹیشن پر دستخط کرنا جو دوسرے کو "گھیرتا" ہے + - ایک اٹیسٹر ہونے کے ناطے اور ایک ہی ہدف والے دو مختلف اٹیسٹیشنز پر دستخط کرنا +- ایک رضاکارانہ اخراج پر مجبور کرنا، جو ویلیڈیٹر کو اسٹیکنگ سے روکتا ہے، اور اس کے ETH بیلنس تک رسائی وڈراول کلید کے مالک کو دیتا ہے + +جب کوئی صارف اسٹیکنگ ڈپازٹ کنٹریکٹ میں ETH جمع کرتا ہے تو **ویلیڈیٹر پبلک کلید** ٹرانزیکشن ڈیٹا میں شامل ہوتی ہے۔ اسے _ڈپازٹ ڈیٹا_ کے نام سے جانا جاتا ہے اور یہ Ethereum کو ویلیڈیٹر کی شناخت کرنے کی اجازت دیتا ہے۔ + +### وڈراول کریڈینشلز {#withdrawal-credentials} + +ہر ویلیڈیٹر کی ایک پراپرٹی ہوتی ہے جسے _وڈراول کریڈینشلز_ کہا جاتا ہے۔ اس 32 بائٹ فیلڈ کا پہلا بائٹ اکاؤنٹ کی قسم کی نشاندہی کرتا ہے: `0x00` اصل BLS (پری-شپیلا، نان-وڈراایبل) کریڈینشلز کی نمائندگی کرتا ہے، `0x01` لیگیسی کریڈینشلز کی نمائندگی کرتا ہے جو ایکزیکیوشن ایڈریس کی طرف اشارہ کرتے ہیں، اور `0x02` جدید کمپاؤنڈنگ کریڈینشل کی قسم کی نمائندگی کرتا ہے۔ + +`0x00` BLS کلیدوں والے ویلیڈیٹرز کو اضافی بیلنس کی ادائیگیوں یا اسٹیکنگ سے مکمل وڈراول کو فعال کرنے کے لیے ان کریڈینشلز کو ایکزیکیوشن ایڈریس کی طرف اشارہ کرنے کے لیے اپ ڈیٹ کرنا ہوگا۔ یہ ابتدائی کلیدی جنریشن کے دوران ڈپازٹ ڈیٹا میں ایکزیکیوشن ایڈریس فراہم کرکے، _یا_ بعد میں وڈراول کلید کا استعمال کرکے ایک `BLSToExecutionChange` پیغام پر دستخط کرنے اور براڈکاسٹ کرنے کے ذریعے کیا جا سکتا ہے۔ + +[ویلیڈیٹر وڈراول کریڈینشلز پر مزید](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### وڈراول کلید {#withdrawal-key} + +اگر ابتدائی ڈپازٹ کے دوران سیٹ نہیں کیا گیا ہے، تو وڈراول کریڈینشلز کو ایکزیکیوشن ایڈریس کی طرف اشارہ کرنے کے لیے اپ ڈیٹ کرنے کے لیے وڈراول کلید کی ضرورت ہوگی۔ اس سے اضافی بیلنس کی ادائیگیوں پر کارروائی شروع ہو جائے گی، اور یہ صارفین کو اپنے اسٹیک شدہ ETH کو مکمل طور پر نکالنے کی بھی اجازت دے گا۔ + +ویلیڈیٹر کلیدوں کی طرح، وڈراول کلیدیں بھی دو اجزاء پر مشتمل ہوتی ہیں: + +- وڈراول **پرائیویٹ** کلید +- وڈراول **پبلک** کلید + +وڈراول کریڈینشلز کو `0x01` قسم میں اپ ڈیٹ کرنے سے پہلے اس کلید کو کھونے کا مطلب ویلیڈیٹر بیلنس تک رسائی کھو دینا ہے۔ ویلیڈیٹر اب بھی اٹیسٹیشنز اور بلاکس پر دستخط کر سکتا ہے کیونکہ ان کارروائیوں کے لیے ویلیڈیٹر کی پرائیویٹ کلید کی ضرورت ہوتی ہے، تاہم اگر وڈراول کلیدیں گم ہو جائیں تو اس میں کوئی ترغیب نہیں ہے۔ + +ویلیڈیٹر کلیدوں کو Ethereum اکاؤنٹ کی کلیدوں سے الگ کرنے سے ایک ہی صارف کے ذریعے متعدد ویلیڈیٹرز چلائے جا سکتے ہیں۔ + +![ویلیڈیٹر کلید کا اسکیمیٹک](validator-key-schematic.png) + +**نوٹ**: اسٹیکنگ کے فرائض سے باہر نکلنے اور ویلیڈیٹر کے بیلنس کو نکالنے کے لیے فی الحال ویلیڈیٹر کلید کے ساتھ [رضاکارانہ اخراج کے پیغام (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) پر دستخط کرنے کی ضرورت ہوتی ہے۔ تاہم، [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) ایک تجویز ہے جو مستقبل میں کسی صارف کو وڈراول کلید کے ساتھ اخراج کے پیغامات پر دستخط کرکے ویلیڈیٹر کے اخراج کو متحرک کرنے اور اس کے بیلنس کو نکالنے کی اجازت دے گی۔ اس سے ان اسٹیکرز کو اپنے فنڈز پر کنٹرول برقرار رکھنے کے قابل بنا کر اعتماد کے مفروضوں کو کم کیا جائے گا جو ETH کو [اسٹیکنگ-ایز-اے-سروس فراہم کنندگان](/staking/saas/#what-is-staking-as-a-service) کو تفویض کرتے ہیں۔ + +## ایک سیڈ فریز سے کلیدیں اخذ کرنا {#deriving-keys-from-seed} + +اگر ہر 32 ETH اسٹیک کرنے کے لیے 2 مکمل طور پر آزاد کلیدوں کے ایک نئے سیٹ کی ضرورت ہوتی، تو کلیدی انتظام تیزی سے بوجھل ہو جاتا، خاص طور پر متعدد ویلیڈیٹرز چلانے والے صارفین کے لیے۔ اس کے بجائے، متعدد ویلیڈیٹر کلیدیں ایک ہی مشترکہ راز سے اخذ کی جا سکتی ہیں اور اس ایک راز کو ذخیرہ کرنے سے متعدد ویلیڈیٹر کلیدوں تک رسائی کی اجازت ملتی ہے۔ + +[Mnemonics](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) اور پاتھز نمایاں خصوصیات ہیں جن کا سامنا صارفین کو اکثر اپنے والیٹس [تک رسائی](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) حاصل کرتے وقت ہوتا ہے۔ نیمونک الفاظ کا ایک سلسلہ ہے جو پرائیویٹ کلید کے لیے ابتدائی سیڈ کے طور پر کام کرتا ہے۔ جب اضافی ڈیٹا کے ساتھ ملایا جاتا ہے، تو نیمونک ایک ہیش تیار کرتا ہے جسے 'ماسٹر کلید' کہا جاتا ہے۔ اسے ایک درخت کی جڑ کے طور پر سمجھا جا سکتا ہے۔ اس جڑ سے شاخیں پھر ایک درجہ بندی کے راستے کا استعمال کرتے ہوئے اخذ کی جا سکتی ہیں تاکہ چائلڈ نوڈس اپنے پیرنٹ نوڈ کے ہیش اور درخت میں ان کے انڈیکس کے امتزاج کے طور پر موجود رہ سکیں۔ نیمونک پر مبنی کلیدی جنریشن کے لیے [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) اور [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) معیارات کے بارے میں پڑھیں۔ + +ان پاتھز کی ساخت مندرجہ ذیل ہے، جو ان صارفین سے واقف ہوگی جنہوں نے ہارڈویئر والیٹس کے ساتھ تعامل کیا ہے: + +``` +m/44'/60'/0'/0` +``` + +اس پاتھ میں سلیش پرائیویٹ کلید کے اجزاء کو مندرجہ ذیل طور پر الگ کرتے ہیں: + +``` +ماسٹر_کلید / مقصد / کوائن_قسم / اکاؤنٹ / تبدیلی / ایڈریس_انڈیکس +``` + +یہ منطق صارفین کو ایک ہی **نیمونک فریز** سے زیادہ سے زیادہ ویلیڈیٹرز منسلک کرنے کے قابل بناتی ہے کیونکہ درخت کی جڑ مشترک ہو سکتی ہے، اور شاخوں پر تفریق ہو سکتی ہے۔ صارف نیمونک فریز سے **کتنی بھی تعداد میں کلیدیں اخذ** کر سکتا ہے۔ + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +ہر شاخ کو `/` سے الگ کیا جاتا ہے لہذا `m/2` کا مطلب ہے ماسٹر کلید سے شروع کریں اور شاخ 2 کی پیروی کریں۔ نیچے دیے گئے اسکیمیٹک میں ایک ہی نیمونک فریز کا استعمال تین وڈراول کلیدوں کو ذخیرہ کرنے کے لیے کیا گیا ہے، جن میں سے ہر ایک کے ساتھ دو منسلک ویلیڈیٹرز ہیں۔ + +![ویلیڈیٹر کلیدی منطق](multiple-keys.png) + +## مزید پڑھیں {#further-reading} + +- [کارل بیکھوئزن کا Ethereum فاؤنڈیشن بلاگ پوسٹ](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 BLS12-381 کلیدی جنریشن](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: ایکزیکیوشن لیئر ٹرگرڈ ایگزٹس](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [بڑے پیمانے پر کلیدی انتظام](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..cf4a0eefb08 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "Proof-of-stake بمقابلہ proof-of-work" +description: "Ethereum کے proof-of-stake اور proof-of-work پر مبنی consensus mechanism کے درمیان ایک موازنہ" +lang: ur-in +--- + +جب Ethereum لانچ ہوا، تو proof-of-stake کو Ethereum کو محفوظ بنانے کے لیے بھروسہ کیے جانے سے پہلے بہت زیادہ تحقیق اور ترقی کی ضرورت تھی۔ Proof-of-work ایک آسان میکانزم تھا جسے Bitcoin نے پہلے ہی ثابت کر دیا تھا، جس کا مطلب ہے کہ بنیادی ڈیولپرز Ethereum کو لانچ کرنے کے لیے اسے فوراً نافذ کر سکتے تھے۔ Proof-of-stake کو اس مقام تک پہنچانے میں مزید آٹھ سال لگے جہاں اسے نافذ کیا جا سکتا تھا۔ + +یہ صفحہ Ethereum کے proof-of-work سے proof-of-stake میں سوئچ کرنے کے پیچھے کی منطق اور اس میں شامل تجارتی سمجھوتوں کی وضاحت کرتا ہے۔ + +## سیکیورٹی {#security} + +Ethereum کے محققین proof-of-stake کو proof-of-work سے زیادہ محفوظ سمجھتے ہیں۔ تاہم، اسے حال ہی میں حقیقی Ethereum Mainnet کے لیے نافذ کیا گیا ہے اور یہ proof-of-work کے مقابلے میں کم وقت کا ثابت شدہ ہے۔ مندرجہ ذیل حصے proof-of-work کے مقابلے میں proof-of-stake کے سیکورٹی ماڈل کے فوائد اور نقصانات پر تبادلہ خیال کرتے ہیں۔ + +### حملہ کرنے کی لاگت {#cost-to-attack} + +Proof-of-stake میں، ویلیڈیٹرز کو ایک سمارٹ کنٹریکٹ میں کم از کم 32 ETH ایسکرو ("stake") کرنا ہوتا ہے۔ Ethereum غلط برتاؤ کرنے والے ویلیڈیٹرز کو سزا دینے کے لیے اسٹیک شدہ ایتھر کو تباہ کر سکتا ہے۔ اتفاق رائے پر پہنچنے کے لیے، کل اسٹیک شدہ ایتھر کا کم از کم 66% حصہ بلاکس کے ایک خاص سیٹ کے حق میں ووٹ دینا ہوتا ہے۔ >=66% اسٹیک کے ذریعے ووٹ دیے گئے بلاکس "حتمی" ہو جاتے ہیں، جس کا مطلب ہے کہ انہیں ہٹایا یا دوبارہ منظم نہیں کیا جا سکتا۔ + +نیٹ ورک پر حملہ کرنے کا مطلب ہو سکتا ہے چین کو حتمی شکل دینے سے روکنا یا کینونیکل چین میں بلاکس کی ایک خاص تنظیم کو یقینی بنانا جس سے کسی حملہ آور کو کسی طرح سے فائدہ پہنچے۔ اس کے لیے حملہ آور کو بڑی مقدار میں ایتھر جمع کرکے اور اس کے ساتھ براہ راست ووٹ دے کر یا ایماندار ویلیڈیٹرز کو کسی خاص طریقے سے ووٹ دینے کے لیے دھوکہ دے کر ایماندار اتفاق رائے کے راستے کو موڑنے کی ضرورت ہوتی ہے۔ ایماندار ویلیڈیٹرز کو دھوکہ دینے والے نفیس، کم امکانی حملوں کے علاوہ، Ethereum پر حملہ کرنے کی لاگت اس اسٹیک کی لاگت ہے جو ایک حملہ آور کو اپنے حق میں اتفاق رائے کو متاثر کرنے کے لیے جمع کرنا پڑتا ہے۔ + +حملے کی سب سے کم لاگت کل اسٹیک کا 33% سے زیادہ ہے۔ کل اسٹیک کا 33% سے زیادہ رکھنے والا حملہ آور صرف آف لائن ہو کر حتمیت میں تاخیر کا سبب بن سکتا ہے۔ یہ نیٹ ورک کے لیے نسبتاً معمولی مسئلہ ہے کیونکہ ایک میکانزم ہے جسے "inactivity leak" کے نام سے جانا جاتا ہے جو آف لائن ویلیڈیٹرز سے اسٹیک کو اس وقت تک لیک کرتا ہے جب تک کہ آن لائن اکثریت اسٹیک کے 66% کی نمائندگی نہ کرے اور چین کو دوبارہ حتمی شکل دے سکے۔ یہ بھی نظریاتی طور پر ممکن ہے کہ ایک حملہ آور کل اسٹیک کے 33% سے تھوڑا زیادہ کے ساتھ دوہری حتمیت کا سبب بنے جب انہیں بلاک پروڈیوسر بننے کے لیے کہا جائے تو ایک کے بجائے دو بلاکس بنا کر اور پھر اپنے تمام ویلیڈیٹرز کے ساتھ ڈبل ووٹ دے کر۔ ہر فورک کو صرف 50% باقی ایماندار ویلیڈیٹرز کی ضرورت ہوتی ہے کہ وہ ہر بلاک کو پہلے دیکھیں، لہذا اگر وہ اپنے پیغامات کو صحیح وقت پر منظم کرنے میں کامیاب ہو جاتے ہیں، تو وہ دونوں فورکس کو حتمی شکل دے سکتے ہیں۔ اس کی کامیابی کا امکان کم ہے، لیکن اگر کوئی حملہ آور دوہری حتمیت کا سبب بننے میں کامیاب ہو جاتا ہے، تو Ethereum کمیونٹی کو ایک فورک کی پیروی کرنے کا فیصلہ کرنا پڑے گا، جس صورت میں حملہ آور کے ویلیڈیٹرز کو دوسرے پر لازمی طور پر سلیش کر دیا جائے گا۔ + +کل اسٹیک کے 33% سے زیادہ کے ساتھ، ایک حملہ آور کے پاس Ethereum نیٹ ورک پر معمولی (حتمیت میں تاخیر) یا زیادہ شدید (دوہری حتمیت) اثر ڈالنے کا موقع ہوتا ہے۔ نیٹ ورک پر 14,000,000 سے زیادہ ETH اسٹیک ہونے اور 1000$/ETH کی نمائندہ قیمت کے ساتھ، ان حملوں کو کرنے کی کم از کم لاگت `1000 x 14,000,000 x 0.33 = $4,620,000,000` ہے۔ حملہ آور یہ رقم سلیشنگ کے ذریعے کھو دے گا اور اسے نیٹ ورک سے نکال دیا جائے گا۔ دوبارہ حملہ کرنے کے لیے، انہیں اسٹیک کا 33% سے زیادہ (دوبارہ) جمع کرنا ہوگا اور اسے (دوبارہ) جلانا ہوگا۔ نیٹ ورک پر حملہ کرنے کی ہر کوشش پر 4.6 بلین ڈالر سے زیادہ لاگت آئے گی (1000$/ETH اور 14M ETH اسٹیک پر)۔ حملہ آور کو اس وقت بھی نیٹ ورک سے نکال دیا جاتا ہے جب انہیں سلیش کیا جاتا ہے، اور انہیں دوبارہ شامل ہونے کے لیے ایکٹیویشن قطار میں شامل ہونا پڑتا ہے۔ اس کا مطلب ہے کہ بار بار حملے کی شرح نہ صرف اس شرح تک محدود ہے جس سے حملہ آور کل اسٹیک کا 33% سے زیادہ جمع کر سکتا ہے بلکہ اس وقت تک بھی محدود ہے جو اپنے تمام ویلیڈیٹرز کو نیٹ ورک پر آن بورڈ کرنے میں لگتا ہے۔ ہر بار جب حملہ آور حملہ کرتا ہے، وہ بہت غریب ہو جاتا ہے، اور باقی کمیونٹی امیر ہو جاتی ہے، جس کے نتیجے میں سپلائی کا جھٹکا لگتا ہے۔ + +دیگر حملے، جیسے 51% حملے یا کل اسٹیک کے 66% کے ساتھ حتمیت کی واپسی، کے لیے کافی زیادہ ETH کی ضرورت ہوتی ہے اور یہ حملہ آور کے لیے بہت زیادہ مہنگے ہوتے ہیں۔ + +اس کا proof-of-work سے موازنہ کریں۔ Proof-of-work Ethereum پر حملہ کرنے کی لاگت کل نیٹ ورک ہیش ریٹ کے 50% سے زیادہ کا مسلسل مالک ہونے کی لاگت تھی۔ یہ دوسرے مائنرز کو پیچھے چھوڑ کر مسلسل proof-of-work حل کا حساب لگانے کے لیے کافی کمپیوٹنگ پاور کے ہارڈ ویئر اور چلانے کے اخراجات کے برابر تھا۔ Ethereum کو زیادہ تر ASICs کے بجائے GPUs کا استعمال کرتے ہوئے مائن کیا گیا تھا، جس سے لاگت کم رہی (حالانکہ اگر Ethereum proof-of-work پر رہتا، تو ASIC مائننگ زیادہ مقبول ہو سکتی تھی)۔ ایک مخالف کو proof-of-work Ethereum نیٹ ورک پر حملہ کرنے کے لیے بہت سارے ہارڈ ویئر خریدنے اور اسے چلانے کے لیے بجلی کی ادائیگی کرنی ہوگی، لیکن کل لاگت حملہ شروع کرنے کے لیے کافی ETH جمع کرنے کے لیے درکار لاگت سے کم ہوگی۔ ایک 51% حملہ proof-of-stake کے مقابلے میں proof-of-work پر ~[20 گنا کم](https://youtu.be/1m12zgJ42dI?t=1562) مہنگا ہے۔ اگر حملے کا پتہ چل جاتا اور ان کی تبدیلیوں کو ہٹانے کے لیے چین کو ہارڈ فورک کیا جاتا، تو حملہ آور نئے فورک پر حملہ کرنے کے لیے بار بار اسی ہارڈ ویئر کا استعمال کر سکتا تھا۔ + +### پیچیدگی {#complexity} + +Proof-of-stake, proof-of-work سے کہیں زیادہ پیچیدہ ہے۔ یہ proof-of-work کے حق میں ایک نکتہ ہو سکتا ہے کیونکہ آسان پروٹوکول میں حادثاتی طور پر بگس یا غیر ارادی اثرات متعارف کرانا مشکل ہے۔ تاہم، پیچیدگی کو برسوں کی تحقیق اور ترقی، سمیلیشنز، اور ٹیسٹ نیٹ کے نفاذ کے ذریعے قابو میں لایا گیا ہے۔ Proof-of-stake پروٹوکول کو پانچ الگ الگ ٹیموں نے (ہر ایک ایگزیکیوشن اور کنسنسس لیئرز پر) پانچ پروگرامنگ زبانوں میں آزادانہ طور پر نافذ کیا ہے، جو کلائنٹ بگس کے خلاف لچک فراہم کرتا ہے۔ + +Proof-of-stake کنسنسس منطق کو محفوظ طریقے سے تیار کرنے اور جانچنے کے لیے، Beacon Chain کو Ethereum Mainnet پر proof-of-stake کے نفاذ سے دو سال پہلے لانچ کیا گیا تھا۔ Beacon Chain نے proof-of-stake کی جانچ کے لیے ایک سینڈ باکس کے طور پر کام کیا، کیونکہ یہ ایک لائیو بلاکچین تھا جو proof-of-stake کنسنسس منطق کو نافذ کرتا تھا لیکن حقیقی Ethereum ٹرانزیکشنز کو چھوئے بغیر - مؤثر طریقے سے صرف خود پر اتفاق رائے پر پہنچتا تھا۔ ایک بار جب یہ کافی وقت تک مستحکم اور بگ سے پاک ہو گیا، تو Beacon Chain کو Ethereum Mainnet کے ساتھ "ضم" کر دیا گیا۔ ان سب نے proof-of-stake کی پیچیدگی کو اس مقام تک قابو کرنے میں اہم کردار ادا کیا جہاں غیر ارادی نتائج یا کلائنٹ بگس کا خطرہ بہت کم تھا۔ + +### حملے کی سطح {#attack-surface} + +Proof-of-stake, proof-of-work سے زیادہ پیچیدہ ہے، جس کا مطلب ہے کہ نمٹنے کے لیے زیادہ ممکنہ حملے کے ویکٹرز ہیں۔ کلائنٹس کو جوڑنے والے ایک پیئر ٹو پیئر نیٹ ورک کے بجائے، دو ہیں، ہر ایک الگ پروٹوکول کو نافذ کرتا ہے۔ ہر سلاٹ میں ایک بلاک تجویز کرنے کے لیے پہلے سے منتخب ایک مخصوص ویلیڈیٹر کا ہونا ڈینائل-آف-سروس کا امکان پیدا کرتا ہے جہاں بڑی مقدار میں نیٹ ورک ٹریفک اس مخصوص ویلیڈیٹر کو آف لائن کر دیتی ہے۔ + +ایسے طریقے بھی ہیں جن سے حملہ آور اپنے بلاکس یا توثیق کے اجراء کو احتیاط سے وقت دے سکتے ہیں تاکہ انہیں ایماندار نیٹ ورک کے ایک خاص تناسب سے موصول کیا جا سکے، جس سے وہ بعض طریقوں سے ووٹ دینے پر اثر انداز ہوں۔ آخر میں، ایک حملہ آور صرف اسٹیک کرنے اور کنسنسس میکانزم پر غلبہ حاصل کرنے کے لیے کافی ETH جمع کر سکتا ہے۔ ان میں سے ہر ایک [حملے کے ویکٹر سے منسلک دفاعات ہیں](/developers/docs/consensus-mechanisms/pos/attack-and-defense)، لیکن وہ proof-of-work کے تحت دفاع کے لیے موجود نہیں ہیں۔ + +## وکندریقرت {#decentralization} + +Proof-of-stake, proof-of-work سے زیادہ وکندریقرت ہے کیونکہ مائننگ ہارڈ ویئر کی ہتھیاروں کی دوڑ افراد اور چھوٹی تنظیموں کو قیمت سے باہر کر دیتی ہے۔ جبکہ کوئی بھی تکنیکی طور پر معمولی ہارڈ ویئر کے ساتھ مائننگ شروع کر سکتا ہے، ادارہ جاتی مائننگ آپریشنز کے مقابلے میں ان کے کسی بھی انعام حاصل کرنے کا امکان بہت کم ہے۔ Proof-of-stake کے ساتھ، اسٹیکنگ کی لاگت اور اس اسٹیک پر فیصد واپسی سب کے لیے یکساں ہے۔ اس وقت ایک ویلیڈیٹر چلانے کے لیے 32 ETH کی لاگت آتی ہے۔ + +دوسری طرف، لیکویڈ اسٹیکنگ ڈیریویٹوز کی ایجاد نے مرکزیت کے خدشات کو جنم دیا ہے کیونکہ چند بڑے فراہم کنندگان بڑی مقدار میں اسٹیک شدہ ETH کا انتظام کرتے ہیں۔ یہ مسئلہ ہے اور اسے جلد از جلد درست کرنے کی ضرورت ہے، لیکن یہ اس سے زیادہ باریک بھی ہے جتنا یہ لگتا ہے۔ مرکزی اسٹیکنگ فراہم کرنے والوں کا ویلیڈیٹرز پر لازمی طور پر مرکزی کنٹرول نہیں ہوتا ہے - اکثر یہ ETH کا ایک مرکزی پول بنانے کا ایک طریقہ ہوتا ہے جسے بہت سے آزاد نوڈ آپریٹرز ہر شریک کو اپنے 32 ETH کی ضرورت کے بغیر اسٹیک کر سکتے ہیں۔ + +Ethereum کے لیے بہترین آپشن یہ ہے کہ ویلیڈیٹرز کو گھریلو کمپیوٹرز پر مقامی طور پر چلایا جائے، جس سے وکندریقرت کو زیادہ سے زیادہ کیا جائے۔ یہی وجہ ہے کہ Ethereum ان تبدیلیوں کی مزاحمت کرتا ہے جو نوڈ/ویلیڈیٹر چلانے کے لیے ہارڈ ویئر کی ضروریات میں اضافہ کرتی ہیں۔ + +## پائیداری {#sustainability} + +Proof-of-stake بلاکچین کو محفوظ بنانے کا ایک کاربن-سستا طریقہ ہے۔ Proof-of-work کے تحت مائنرز ایک بلاک مائن کرنے کے حق کے لیے مقابلہ کرتے ہیں۔ مائنرز زیادہ کامیاب ہوتے ہیں جب وہ تیزی سے حساب کتاب کر سکتے ہیں، ہارڈ ویئر اور توانائی کی کھپت میں سرمایہ کاری کی ترغیب دیتے ہیں۔ یہ Ethereum کے proof-of-stake پر سوئچ کرنے سے پہلے اس کے لیے مشاہدہ کیا گیا تھا۔ Proof-of-stake میں منتقلی سے کچھ دیر پہلے، Ethereum تقریباً 78 TWh/yr استعمال کر رہا تھا - جتنا ایک چھوٹا ملک۔ تاہم، proof-of-stake پر سوئچ کرنے سے اس توانائی کے خرچ میں ~99.98% کی کمی واقع ہوئی۔ Proof-of-stake نے Ethereum کو ایک توانائی-موثر، کم کاربن پلیٹ فارم بنایا۔ + +[Ethereum کی توانائی کی کھپت پر مزید](/energy-consumption) + +## اجراء {#issuance} + +Proof-of-stake Ethereum اپنی سیکیورٹی کے لیے proof-of-work Ethereum کے مقابلے میں بہت کم سکے جاری کر کے ادائیگی کر سکتا ہے کیونکہ ویلیڈیٹرز کو بجلی کے زیادہ اخراجات ادا نہیں کرنے پڑتے ہیں۔ نتیجے کے طور پر، ETH اپنی افراط زر کو کم کر سکتا ہے یا یہاں تک کہ جب بڑی مقدار میں ETH جلایا جاتا ہے تو وہ ڈیفلیشنری بھی بن سکتا ہے۔ کم افراط زر کی سطح کا مطلب ہے کہ Ethereum کی سیکیورٹی proof-of-work کے تحت اس سے سستی ہے۔ + +## کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + +جسٹن ڈریک کو proof-of-work پر proof-of-stake کے فوائد کی وضاحت کرتے ہوئے دیکھیں: + + + +## مزید پڑھیں {#further-reading} + +- [ویٹالک کا proof-of-stake ڈیزائن فلسفہ](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [ویٹالک کے proof-of-stake کے اکثر پوچھے گئے سوالات](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [pos بمقابلہ pow پر "Simply Explained" ویڈیو](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..d3963a73f9c --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "پروف-آف-اسٹیک انعامات اور سزائیں" +description: "پروف-آف-اسٹیک Ethereum میں ان-پروٹوکول ترغیبات کے بارے میں جانیں۔" +lang: ur-in +--- + +Ethereum کو اس کی مقامی کرپٹو کرنسی، ایتھر (ETH) کا استعمال کرتے ہوئے محفوظ بنایا گیا ہے۔ نوڈ آپریٹرز جو بلاکس کی توثیق کرنے اور چین کے ہیڈ کی شناخت کرنے میں حصہ لینا چاہتے ہیں، وہ Ethereum پر [ڈیپازٹ کنٹریکٹ](/staking/deposit-contract/) میں ایتھر جمع کرتے ہیں۔ پھر انہیں ویلیڈیٹر سافٹ ویئر چلانے کے لیے ایتھر میں ادائیگی کی جاتی ہے جو پیئر-ٹو-پیئر نیٹ ورک پر موصول ہونے والے نئے بلاکس کی درستگی کی جانچ کرتا ہے اور چین کے ہیڈ کی شناخت کرنے کے لیے فورک-چوائس الگورتھم کا اطلاق کرتا ہے۔ + +ایک ویلیڈیٹر کے دو بنیادی کردار ہیں: 1) نئے بلاکس کی جانچ کرنا اور اگر وہ درست ہیں تو ان کی "تصدیق" کرنا، 2) کل ویلیڈیٹر پول سے تصادفی طور پر منتخب ہونے پر نئے بلاکس کی تجویز دینا۔ اگر ویلیڈیٹر سے کہے جانے پر ان میں سے کوئی بھی کام کرنے میں ناکام رہتا ہے تو وہ ایتھر کی ادائیگی سے محروم ہو جاتا ہے۔ ویلیڈیٹرز کو کبھی کبھی سگنیچر ایگریگیشن اور سنک کمیٹیوں میں حصہ لینے کا کام بھی سونپا جاتا ہے۔ + +کچھ ایسے اعمال بھی ہیں جنہیں اتفاقی طور پر کرنا بہت مشکل ہے اور جو کچھ بدنیتی پر مبنی ارادے کی نشاندہی کرتے ہیں، جیسے کہ ایک ہی سلاٹ کے لیے متعدد بلاکس کی تجویز دینا یا ایک ہی سلاٹ کے لیے متعدد بلاکس کی تصدیق کرنا۔ یہ "سلیش ایبل" رویے ہیں جن کے نتیجے میں ویلیڈیٹر کو نیٹ ورک سے ہٹانے سے پہلے اس کے کچھ ایتھر (1 ETH تک) کو برن کر دیا جاتا ہے، جس میں 36 دن لگتے ہیں۔ سلیش کیے گئے ویلیڈیٹر کا ایتھر ایگزٹ پیریڈ کے دوران آہستہ آہستہ ختم ہو جاتا ہے، لیکن 18 ویں دن انہیں ایک "کوریلیشن پینلٹی" ملتی ہے جو اس وقت بڑی ہوتی ہے جب ایک ہی وقت میں زیادہ ویلیڈیٹرز کو سلیش کیا جاتا ہے۔ اس لیے کنسینسس میکانزم کا ترغیبی ڈھانچہ ایمانداری کا صلہ دیتا ہے اور برے کرداروں کو سزا دیتا ہے۔ + +تمام انعامات اور سزائیں ہر ایپوک میں ایک بار لاگو ہوتی ہیں۔ + +مزید تفصیلات کے لیے پڑھتے رہیں... + +## انعامات اور سزائیں {#rewards} + +### انعامات {#rewards} + +ویلیڈیٹرز کو انعامات اس وقت ملتے ہیں جب وہ ایسے ووٹ دیتے ہیں جو دوسرے ویلیڈیٹرز کی اکثریت کے مطابق ہوں، جب وہ بلاکس کی تجویز دیتے ہیں، اور جب وہ سنک کمیٹیوں میں حصہ لیتے ہیں۔ ہر ایپوک میں انعامات کی قدر کو ایک `base_reward` سے شمار کیا جاتا ہے۔ یہ وہ بنیادی اکائی ہے جس سے دوسرے انعامات کا حساب لگایا جاتا ہے۔ `base_reward` بہترین حالات میں فی ایپوک ایک ویلیڈیٹر کے ذریعے حاصل کردہ اوسط انعام کی نمائندگی کرتا ہے۔ اس کا حساب ویلیڈیٹر کے مؤثر بیلنس اور فعال ویلیڈیٹرز کی کل تعداد سے مندرجہ ذیل طور پر لگایا جاتا ہے: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +جہاں `base_reward_factor` 64 ہے، `base_rewards_per_epoch` 4 ہے اور `sum(active balance)` تمام فعال ویلیڈیٹرز میں اسٹیک کیا گیا کل ایتھر ہے۔ + +اس کا مطلب ہے کہ بنیادی انعام ویلیڈیٹر کے مؤثر بیلنس کے متناسب ہے اور نیٹ ورک پر ویلیڈیٹرز کی تعداد کے معکوس متناسب ہے۔ جتنے زیادہ ویلیڈیٹرز ہوں گے، مجموعی اجراء اتنا ہی زیادہ ہوگا (`sqrt(N)` کے طور پر) لیکن فی ویلیڈیٹر `base_reward` اتنا ہی کم ہوگا (`1/sqrt(N)` کے طور پر)۔ یہ عوامل ایک اسٹیکنگ نوڈ کے APR کو متاثر کرتے ہیں۔ [Vitalik's notes](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards) میں اس کی دلیل پڑھیں۔ + +پھر کل انعام کا حساب پانچ اجزاء کے مجموعے کے طور پر لگایا جاتا ہے جن میں سے ہر ایک کا ایک وزن ہوتا ہے جو یہ تعین کرتا ہے کہ ہر جزو کل انعام میں کتنا اضافہ کرتا ہے۔ اجزاء یہ ہیں: + +``` +1. سورس ووٹ: ویلیڈیٹر نے درست سورس چیک پوائنٹ کے لیے بروقت ووٹ دیا ہے +2. ٹارگٹ ووٹ: ویلیڈیٹر نے درست ٹارگٹ چیک پوائنٹ کے لیے بروقت ووٹ دیا ہے +3. ہیڈ ووٹ: ویلیڈیٹر نے درست ہیڈ بلاک کے لیے بروقت ووٹ دیا ہے +4. سنک کمیٹی انعام: ویلیڈیٹر نے سنک کمیٹی میں حصہ لیا ہے +5. پروپوزر انعام: ویلیڈیٹر نے درست سلاٹ میں ایک بلاک کی تجویز دی ہے +``` + +ہر جزو کے لیے وزن مندرجہ ذیل ہیں: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +ان وزنوں کا مجموعہ 64 ہے۔ انعام کا حساب قابل اطلاق وزنوں کے مجموعے کو 64 سے تقسیم کر کے لگایا جاتا ہے۔ ایک ویلیڈیٹر جس نے بروقت سورس، ٹارگٹ اور ہیڈ ووٹ دیے ہیں، ایک بلاک کی تجویز دی ہے اور ایک سنک کمیٹی میں حصہ لیا ہے، وہ `64/64 * base_reward == base_reward` حاصل کر سکتا ہے۔ تاہم، ایک ویلیڈیٹر عام طور پر ایک بلاک پروپوزر نہیں ہوتا ہے، اس لیے اس کا زیادہ سے زیادہ انعام `64-8 /64 * base_reward == 7/8 * base_reward` ہے۔ وہ ویلیڈیٹرز جو نہ تو بلاک پروپوزر ہیں اور نہ ہی سنک کمیٹی میں ہیں، `64-8-2 / 64 * base_reward == 6.75/8 * base_reward` حاصل کر سکتے ہیں۔ + +تیزی سے تصدیقات کی ترغیب دینے کے لیے ایک اضافی انعام شامل کیا جاتا ہے۔ یہ `inclusion_delay_reward` ہے۔ اس کی قدر `base_reward` کو `1/delay` سے ضرب دینے کے برابر ہے، جہاں `delay` بلاک کی تجویز اور تصدیق کو الگ کرنے والے سلاٹس کی تعداد ہے۔ مثال کے طور پر، اگر تصدیق بلاک کی تجویز کے ایک سلاٹ کے اندر جمع کی جاتی ہے تو تصدیق کنندہ `base_reward * 1/1 == base_reward` حاصل کرتا ہے۔ اگر تصدیق اگلے سلاٹ میں آتی ہے، تو تصدیق کنندہ `base_reward * 1/2` حاصل کرتا ہے اور اسی طرح۔ + +بلاک پروپوزرز کو بلاک میں شامل **ہر درست تصدیق** کے لیے `8 / 64 * base_reward` ملتا ہے، لہذا انعام کی اصل قدر تصدیق کرنے والے ویلیڈیٹرز کی تعداد کے ساتھ اسکیل ہوتی ہے۔ بلاک پروپوزرز اپنے مجوزہ بلاک میں دوسرے ویلیڈیٹرز کی بدسلوکی کے ثبوت شامل کر کے بھی اپنے انعام میں اضافہ کر سکتے ہیں۔ یہ انعامات وہ "ترغیبات" ہیں جو ویلیڈیٹر کی ایمانداری کی حوصلہ افزائی کرتی ہیں۔ ایک بلاک پروپوزر جو سلیشنگ کو شامل کرتا ہے اسے `slashed_validators_effective_balance / 512` سے نوازا جائے گا۔ + +### سزائیں {#penalties} + +اب تک ہم نے بالکل اچھے برتاؤ والے ویلیڈیٹرز پر غور کیا ہے، لیکن ان ویلیڈیٹرز کا کیا ہوگا جو بروقت ہیڈ، سورس اور ٹارگٹ ووٹ نہیں دیتے یا آہستہ آہستہ ایسا کرتے ہیں؟ + +ٹارگٹ اور سورس ووٹوں سے محروم ہونے کی سزائیں ان انعامات کے برابر ہیں جو تصدیق کنندہ کو ملتے اگر وہ انہیں جمع کرتے۔ اس کا مطلب ہے کہ ان کے بیلنس میں انعام شامل ہونے کے بجائے، ان کے بیلنس سے اتنی ہی قیمت ہٹا دی جاتی ہے۔ ہیڈ ووٹ سے محروم ہونے پر کوئی سزا نہیں ہے (یعنی ہیڈ ووٹوں پر صرف انعام دیا جاتا ہے، کبھی سزا نہیں دی جاتی)۔ `inclusion_delay` کے ساتھ کوئی سزا منسلک نہیں ہے - انعام کو صرف ویلیڈیٹر کے بیلنس میں شامل نہیں کیا جائے گا۔ بلاک کی تجویز دینے میں ناکام ہونے پر بھی کوئی سزا نہیں ہے۔ + +[کنسینسس اسپیکس](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md) میں انعامات اور سزاؤں کے بارے میں مزید پڑھیں۔ Bellatrix اپ گریڈ میں انعامات اور سزاؤں کو ایڈجسٹ کیا گیا تھا - اس [Peep an EIP ویڈیو](https://www.youtube.com/watch?v=iaAEGs1DMgQ) میں ڈینی ریان اور وائٹلک کو اس پر تبادلہ خیال کرتے ہوئے دیکھیں۔ + +## سلیشنگ {#slashing} + +سلیشنگ ایک زیادہ سنگین کارروائی ہے جس کے نتیجے میں ایک ویلیڈیٹر کو نیٹ ورک سے زبردستی ہٹا دیا جاتا ہے اور ان کے اسٹیک شدہ ایتھر کا متعلقہ نقصان ہوتا ہے۔ ایک ویلیڈیٹر کو سلیش کرنے کے تین طریقے ہیں، جن سب کا نتیجہ بلاکس کی بے ایمانی سے تجویز یا تصدیق کی صورت میں نکلتا ہے: + +- ایک ہی سلاٹ کے لیے دو مختلف بلاکس کی تجویز اور ان پر دستخط کر کے +- ایک ایسے بلاک کی تصدیق کر کے جو دوسرے کو "گھیرتا" ہے (مؤثر طریقے سے تاریخ کو تبدیل کرنا) +- ایک ہی بلاک کے لیے دو امیدواروں کی تصدیق کر کے "ڈبل ووٹنگ" کرنا + +اگر ان کارروائیوں کا پتہ چل جاتا ہے، تو ویلیڈیٹر کو سلیش کر دیا جاتا ہے۔ اس کا مطلب ہے کہ 32 ETH والے ویلیڈیٹر کے لیے 0.0078125 کو فوری طور پر برن کر دیا جاتا ہے (فعال بیلنس کے ساتھ لینیئرلی اسکیل کیا جاتا ہے)، پھر 36 دن کا ہٹانے کا دورانیہ شروع ہوتا ہے۔ اس ہٹانے کی مدت کے دوران ویلیڈیٹر کا اسٹیک آہستہ آہستہ ختم ہو جاتا ہے۔ وسط نقطہ پر (دن 18) ایک اضافی سزا لاگو کی جاتی ہے جس کی شدت سلیشنگ ایونٹ سے پہلے کے 36 دنوں میں تمام سلیش کیے گئے ویلیڈیٹرز کے کل اسٹیک شدہ ایتھر کے ساتھ اسکیل ہوتی ہے۔ اس کا مطلب ہے کہ جب زیادہ ویلیڈیٹرز کو سلیش کیا جاتا ہے، تو سلیش کی شدت بڑھ جاتی ہے۔ زیادہ سے زیادہ سلیش تمام سلیش کیے گئے ویلیڈیٹرز کا مکمل مؤثر بیلنس ہے (یعنی، اگر بہت سے ویلیڈیٹرز کو سلیش کیا جا رہا ہے تو وہ اپنا پورا اسٹیک کھو سکتے ہیں)۔ دوسری طرف، ایک واحد، الگ تھلگ سلیشنگ ایونٹ ویلیڈیٹر کے اسٹیک کا صرف ایک چھوٹا سا حصہ جلاتا ہے۔ یہ وسط نقطہ کی سزا جو سلیش کیے گئے ویلیڈیٹرز کی تعداد کے ساتھ اسکیل ہوتی ہے، اسے "کوریلیشن پینلٹی" کہا جاتا ہے۔ + +## غیرفعالیت لیک {#inactivity-leak} + +اگر کنسینسس لیئر کو فائنلائز کیے بغیر چار سے زیادہ ایپوک گزر چکے ہیں، تو "غیرفعالیت لیک" نامی ایک ہنگامی پروٹوکول فعال ہو جاتا ہے۔ غیرفعالیت لیک کا حتمی مقصد ان حالات کو پیدا کرنا ہے جن کی چین کو فائنلٹی بحال کرنے کے لیے ضرورت ہوتی ہے۔ جیسا کہ اوپر بیان کیا گیا ہے، فائنلٹی کے لیے سورس اور ٹارگٹ چیک پوائنٹس پر متفق ہونے کے لیے کل اسٹیک شدہ ایتھر کی 2/3 اکثریت کی ضرورت ہوتی ہے۔ اگر کل ویلیڈیٹرز کے 1/3 سے زیادہ کی نمائندگی کرنے والے ویلیڈیٹرز آف لائن ہو جاتے ہیں یا درست تصدیقات جمع کرنے میں ناکام رہتے ہیں تو 2/3 کی سپر میجارٹی کے لیے چیک پوائنٹس کو فائنلائز کرنا ممکن نہیں ہے۔ غیرفعالیت لیک غیر فعال ویلیڈیٹرز سے تعلق رکھنے والے اسٹیک کو آہستہ آہستہ ختم ہونے دیتا ہے جب تک کہ وہ کل اسٹیک کے 1/3 سے کم کو کنٹرول نہ کر لیں، جس سے باقی فعال ویلیڈیٹرز چین کو فائنلائز کر سکتے ہیں۔ غیر فعال ویلیڈیٹرز کا پول کتنا ہی بڑا کیوں نہ ہو، باقی فعال ویلیڈیٹرز بالآخر اسٹیک کے 2/3 سے زیادہ کو کنٹرول کریں گے۔ اسٹیک کا نقصان غیر فعال ویلیڈیٹرز کے لیے جلد از جلد دوبارہ فعال ہونے کی ایک مضبوط ترغیب ہے! Medalla ٹیسٹ نیٹ پر ایک غیرفعالیت لیک کا منظر نامہ اس وقت پیش آیا جب 66% سے کم فعال ویلیڈیٹرز بلاک چین کے موجودہ ہیڈ پر اتفاق رائے پر پہنچ سکے۔ غیرفعالیت لیک کو فعال کیا گیا اور آخر کار فائنلٹی دوبارہ حاصل کر لی گئی! + +کنسینسس میکانزم کا انعام، سزا اور سلیشنگ کا ڈیزائن انفرادی ویلیڈیٹرز کو صحیح طریقے سے برتاؤ کرنے کی ترغیب دیتا ہے۔ تاہم، ان ڈیزائن کے انتخاب سے ایک ایسا نظام ابھرتا ہے جو متعدد کلائنٹس میں ویلیڈیٹرز کی مساوی تقسیم کی بھرپور ترغیب دیتا ہے، اور اسے سنگل-کلائنٹ کے غلبے کی سختی سے حوصلہ شکنی کرنی چاہیے۔ + +## مزید پڑھیں {#further-reading} + +- [Ethereum کو اپ گریڈ کرنا: ترغیبی لیئر](https://eth2book.info/altair/part2/incentives) +- [Ethereum کے ہائبرڈ کیسپر پروٹوکول میں ترغیبات](https://arxiv.org/pdf/1903.04205.pdf) +- [Vitalik کی تشریح شدہ اسپیک](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Eth2 سلیشنگ سے بچاؤ کے ٹپس](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [EIP-7251 کے تحت سلیشنگ سزاؤں کا تجزیہ](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_ذرائع_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..3c8becd944c --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "کمزور موضوعیت" +description: "کمزور موضوعیت کی وضاحت اور PoS Ethereum میں اس کا کردار۔" +lang: ur-in +--- + +بلاک چینز میں موضوعیت سے مراد موجودہ اسٹیٹ پر متفق ہونے کے لیے سماجی معلومات پر انحصار کرنا ہے۔ نیٹ ورک پر دیگر پیئرز سے جمع کی گئی معلومات کے مطابق متعدد درست فورکس ہو سکتے ہیں جن میں سے انتخاب کیا جاتا ہے۔ اس کے برعکس معروضیت ہے جس سے مراد وہ چینز ہیں جہاں صرف ایک ممکنہ درست چین ہوتی ہے جس پر تمام نوڈس اپنے کوڈ کردہ اصولوں کو لاگو کرکے لازمی طور پر متفق ہوں گے۔ ایک تیسری اسٹیٹ بھی ہے، جسے کمزور موضوعیت کہا جاتا ہے۔ اس سے مراد ایک ایسی چین ہے جو سماجی طور پر کچھ ابتدائی معلومات حاصل کرنے کے بعد معروضی طور پر آگے بڑھ سکتی ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو سمجھنے کے لیے پہلے [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) کے بنیادی اصولوں کو سمجھنا ضروری ہے۔ + +## کمزور موضوعیت کن مسائل کو حل کرتی ہے؟ {#problems-ws-solves} + +پروف آف اسٹیک بلاک چینز میں موضوعیت فطری ہے کیونکہ متعدد فورکس میں سے درست چین کا انتخاب تاریخی ووٹس کی گنتی کرکے کیا جاتا ہے۔ یہ بلاک چین کو کئی حملوں کے خطرات سے دوچار کرتا ہے، بشمول طویل مدتی حملے جن میں وہ نوڈس جو چین میں بہت شروع میں حصہ لے چکے تھے، ایک متبادل فورک کو برقرار رکھتے ہیں جسے وہ بہت بعد میں اپنے فائدے کے لیے جاری کرتے ہیں۔ متبادل کے طور پر، اگر 33% ویلیڈیٹرز اپنا اسٹیک واپس لے لیں لیکن تصدیق کرنا اور بلاکس بنانا جاری رکھیں، تو وہ ایک متبادل فورک بنا سکتے ہیں جو کینونیکل چین سے متصادم ہو۔ نئے نوڈس یا وہ نوڈس جو طویل عرصے سے آف لائن ہیں شاید اس بات سے واقف نہ ہوں کہ ان حملہ آور ویلیڈیٹرز نے اپنے فنڈز واپس لے لیے ہیں، لہذا حملہ آور انہیں غلط چین کی پیروی کرنے کے لیے دھوکہ دے سکتے ہیں۔ Ethereum ان حملوں کے خطرات کو ایسی پابندیاں لگا کر حل کر سکتا ہے جو میکانزم کے موضوعی پہلوؤں کو — اور اس وجہ سے اعتماد کے مفروضوں کو — کم سے کم کر دیتی ہیں۔ + +## کمزور موضوعیت کے چیک پوائنٹس {#ws-checkpoints} + +پروف آف اسٹیک Ethereum میں کمزور موضوعیت کو "کمزور موضوعیت کے چیک پوائنٹس" کا استعمال کرکے لاگو کیا جاتا ہے۔ یہ اسٹیٹ روٹس ہیں جن پر نیٹ ورک کے تمام نوڈس متفق ہیں کہ وہ کینونیکل چین سے تعلق رکھتے ہیں۔ یہ جینیسس بلاکس کی طرح "آفاقی سچائی" کا مقصد پورا کرتے ہیں، سوائے اس کے کہ وہ بلاک چین میں جینیسس پوزیشن پر نہیں ہوتے۔ فورک چوائس الگورتھم اس بات پر بھروسہ کرتا ہے کہ اس چیک پوائنٹ میں بیان کردہ بلاک چین اسٹیٹ درست ہے اور یہ اس مقام سے آگے چین کی آزادانہ اور معروضی طور پر تصدیق کرتا ہے۔ چیک پوائنٹس "ریورٹ لمٹس" کے طور پر کام کرتے ہیں کیونکہ کمزور موضوعیت کے چیک پوائنٹس سے پہلے موجود بلاکس کو تبدیل نہیں کیا جا سکتا۔ یہ میکانزم ڈیزائن کے حصے کے طور پر طویل مدتی فورکس کو غلط قرار دے کر طویل مدتی حملوں کو کمزور کرتا ہے۔ یہ یقینی بنانا کہ کمزور موضوعیت کے چیک پوائنٹس ویلیڈیٹر کے انخلا کی مدت سے کم فاصلے پر ہوں، اس بات کو یقینی بناتا ہے کہ ایک ویلیڈیٹر جو چین کو فورک کرتا ہے، اسے اپنا اسٹیک واپس لینے سے پہلے کم از کم ایک حد تک کی رقم پر سلیش کیا جائے اور یہ کہ نئے داخل ہونے والوں کو ان ویلیڈیٹرز کے ذریعے غلط فورکس میں دھوکہ نہ دیا جا سکے جن کا اسٹیک واپس لے لیا گیا ہے۔ + +## کمزور موضوعیت کے چیک پوائنٹس اور حتمی شکل دیے گئے بلاکس کے درمیان فرق {#difference-between-ws-and-finalized-blocks} + +حتمی شکل دیے گئے بلاکس اور کمزور موضوعیت کے چیک پوائنٹس کے ساتھ Ethereum نوڈس مختلف طریقے سے برتاؤ کرتے ہیں۔ اگر کوئی نوڈ دو مسابقتی حتمی شکل دیے گئے بلاکس سے آگاہ ہو جاتا ہے، تو وہ دونوں کے درمیان پھنس جاتا ہے - اس کے پاس خود بخود یہ شناخت کرنے کا کوئی طریقہ نہیں ہوتا کہ کینونیکل فورک کون سا ہے۔ یہ اتفاق رائے کی ناکامی کی علامت ہے۔ اس کے برعکس، ایک نوڈ کسی بھی ایسے بلاک کو مسترد کر دیتا ہے جو اس کے کمزور موضوعیت کے چیک پوائنٹ سے متصادم ہو۔ نوڈ کے نقطہ نظر سے، کمزور موضوعیت کا چیک پوائنٹ ایک مطلق سچائی کی نمائندگی کرتا ہے جسے اس کے پیئرز سے حاصل ہونے والے نئے علم سے کمزور نہیں کیا جا سکتا۔ + +## کمزور کتنا کمزور ہے؟ {#how-weak-is-weak} + +Ethereum کے پروف آف اسٹیک کا موضوعی پہلو ایک قابل اعتماد ذریعہ سے حالیہ اسٹیٹ (کمزور موضوعیت کا چیک پوائنٹ) کی ضرورت ہے تاکہ اس سے مطابقت پذیری کی جا سکے۔ خراب کمزور موضوعیت کا چیک پوائنٹ حاصل کرنے کا خطرہ بہت کم ہے کیونکہ انہیں کئی آزاد عوامی ذرائع جیسے کہ بلاک ایکسپلوررز یا متعدد نوڈس کے خلاف چیک کیا جا سکتا ہے۔ تاہم، کسی بھی سافٹ ویئر ایپلیکیشن کو چلانے کے لیے ہمیشہ کچھ حد تک اعتماد کی ضرورت ہوتی ہے، مثال کے طور پر، یہ بھروسہ کرنا کہ سافٹ ویئر ڈویلپرز نے ایماندار سافٹ ویئر تیار کیا ہے۔ + +ایک کمزور موضوعیت کا چیک پوائنٹ کلائنٹ سافٹ ویئر کے حصے کے طور پر بھی آ سکتا ہے۔ یقیناً ایک حملہ آور سافٹ ویئر میں چیک پوائنٹ کو خراب کر سکتا ہے اور اتنی ہی آسانی سے خود سافٹ ویئر کو بھی خراب کر سکتا ہے۔ اس مسئلے کا کوئی حقیقی کرپٹو-اقتصادی حل نہیں ہے، لیکن Ethereum میں ناقابل اعتبار ڈویلپرز کے اثرات کو متعدد آزاد کلائنٹ ٹیمیں رکھ کر کم کیا جاتا ہے، جن میں سے ہر ایک مختلف زبانوں میں مساوی سافٹ ویئر بناتی ہے، اور سب کا ایک ایماندار چین کو برقرار رکھنے میں گہرا مفاد ہوتا ہے۔ بلاک ایکسپلوررز کمزور موضوعیت کے چیک پوائنٹس بھی فراہم کر سکتے ہیں یا کہیں اور سے حاصل کردہ چیک پوائنٹس کا ایک اضافی ذریعہ سے موازنہ کرنے کا طریقہ بھی فراہم کر سکتے ہیں۔ + +آخر میں، چیک پوائنٹس دوسرے نوڈس سے بھی درخواست کیے جا سکتے ہیں؛ شاید کوئی دوسرا Ethereum صارف جو ایک مکمل نوڈ چلاتا ہے، ایک چیک پوائنٹ فراہم کر سکتا ہے جسے ویلیڈیٹرز پھر بلاک ایکسپلورر کے ڈیٹا سے تصدیق کر سکتے ہیں۔ مجموعی طور پر، کمزور موضوعیت کے چیک پوائنٹ فراہم کرنے والے پر بھروسہ کرنا اتنا ہی مشکل سمجھا جا سکتا ہے جتنا کلائنٹ ڈویلپرز پر بھروسہ کرنا۔ مجموعی طور پر درکار اعتماد کم ہے۔ یہ نوٹ کرنا ضروری ہے کہ یہ تحفظات صرف اس انتہائی غیر متوقع صورت میں اہم ہو جاتے ہیں جب ویلیڈیٹرز کی اکثریت بلاک چین کا ایک متبادل فورک بنانے کی سازش کرے۔ کسی بھی دوسرے حالات میں، انتخاب کے لیے صرف ایک ہی Ethereum چین ہوتی ہے۔ + +## مزید مطالعہ {#further-reading} + +- [Eth2 میں کمزور موضوعیت](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik: میں نے کمزور موضوعیت سے محبت کرنا کیسے سیکھا](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [کمزور موضوعیت (Teku دستاویزات)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [فیز-0 کمزور موضوعیت گائیڈ](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Ethereum 2.0 میں کمزور موضوعیت کا تجزیہ](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..d44ed0934d5 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "وڈرال کریڈینشلز" +description: "توثیق کار کے رقم نکالنے کے کریڈنشیل کی اقسام (0x00، 0x01، 0x02) کی وضاحت اور Ethereum اسٹیکرز کے لیے ان کے مضمرات۔" +lang: ur-in +--- + +ہر توثیق کار کے پاس ایک **رقم نکالنے کا کریڈنشیل** ہوتا ہے جو یہ تعین کرتا ہے کہ ان کے اسٹیک شدہ ETH اور انعامات کیسے اور کہاں سے نکالے جا سکتے ہیں۔ کریڈنشیل کی قسم پہلے بائٹ سے ظاہر کی جاتی ہے: `0x00`، `0x01`، یا `0x02`۔ اپنے اسٹیک کا انتظام کرنے والے توثیق کاروں کے لیے ان اقسام کو سمجھنا اہم ہے۔ + +## 0x00: Shapella سے پہلے کے کریڈنشیلز {#0x00-credentials} + +`0x00` قسم Shapella اپ گریڈ (اپریل 2023) سے پہلے کا اصل رقم نکالنے کے کریڈنشیل کا فارمیٹ ہے۔ اس کریڈنشیل قسم والے توثیق کاروں کے پاس کوئی ایگزیکیوشن لیئر رقم نکالنے کا پتہ سیٹ نہیں ہوتا ہے، یعنی ان کے فنڈز کنسینسس لیئر پر لاک رہتے ہیں۔ اگر آپ کے پاس اب بھی `0x00` کریڈنشیلز ہیں، تو کوئی بھی رقم نکالنے سے پہلے آپ کو `0x01` یا `0x02` پر اپ گریڈ کرنا لازمی ہے۔ + +## 0x01: میراثی رقم نکالنے کے کریڈنشیلز {#0x01-credentials} + +`0x01` قسم Shapella اپ گریڈ کے ساتھ متعارف کرائی گئی تھی اور ان توثیق کاروں کے لیے معیار بن گئی جو ایگزیکیوشن لیئر رقم نکالنے کا پتہ سیٹ کرنا چاہتے تھے۔ `0x01` کریڈنشیلز کے ساتھ: + +- 32 ETH سے اوپر کا کوئی بھی بیلنس **خود بخود منتقل ہو کر** آپ کے رقم نکالنے کے پتے پر چلا جاتا ہے۔ +- مکمل اخراج معیاری اخراج کی قطار سے گزرتا ہے۔ +- 32 ETH سے اوپر کے انعامات کمپاؤنڈ نہیں ہو سکتے—انہیں وقتاً فوقتاً نکال دیا جاتا ہے۔ + +**کچھ توثیق کار اب بھی 0x01 کیوں استعمال کرتے ہیں:** یہ آسان اور جانا پہچانا ہے۔ بہت سے توثیق کاروں نے Shapella کے بعد جمع کیا اور ان کے پاس پہلے سے ہی یہ قسم ہے، اور یہ ان لوگوں کے لیے ٹھیک کام کرتا ہے جو اضافی بیلنس کی خودکار رقم نکالنا چاہتے ہیں۔ + +**اس کی سفارش کیوں نہیں کی جاتی:** `0x01` کے ساتھ، آپ 32 ETH سے اوپر کے انعامات کو کمپاؤنڈ کرنے کی صلاحیت کھو دیتے ہیں۔ ہر اضافی حصہ خود بخود نکال دیا جاتا ہے، جو آپ کے توثیق کار کی کمائی کی صلاحیت کو محدود کرتا ہے اور نکالی گئی رقم کو الگ سے منظم کرنے کی ضرورت ہوتی ہے۔ + +## 0x02: کمپاؤنڈنگ رقم نکالنے کے کریڈنشیلز {#0x02-credentials} + +`0x02` قسم Pectra اپ گریڈ کے ساتھ متعارف کرائی گئی تھی اور آج توثیق کاروں کے لیے **تجویز کردہ انتخاب** ہے۔ `0x02` کریڈنشیلز والے توثیق کاروں کو کبھی کبھی "کمپاؤنڈنگ توثیق کار" کہا جاتا ہے۔ + +`0x02` کریڈنشیلز کے ساتھ: + +- 32 ETH سے اوپر کے انعامات 1 ETH کے اضافے میں 2048 ETH کے زیادہ سے زیادہ مؤثر بیلنس تک **کمپاؤنڈ** ہوتے ہیں۔ +- جزوی رقم نکالنے کی درخواست دستی طور پر کی جانی چاہیے (خودکار منتقلی صرف 2048 ETH کی حد سے اوپر ہوتی ہے) +- توثیق کار متعدد 32 ETH والے توثیق کاروں کو یکجا کر کے ایک ہی زیادہ بیلنس والا توثیق کار بنا سکتے ہیں۔ +- مکمل اخراج اب بھی معیاری اخراج کی قطار کے ذریعے سپورٹ کیے جاتے ہیں۔ + +جزوی رقم نکالنے اور یکجا کرنے، دونوں کام [Launchpad Validator Actions](https://launchpad.ethereum.org/en/validator-actions) کے ذریعے کیے جا سکتے ہیں۔ + +**توثیق کاروں کو 0x02 کو کیوں ترجیح دینی چاہیے:** یہ کمپاؤنڈنگ کے ذریعے بہتر سرمائے کی کارکردگی پیش کرتا ہے، رقم کب نکالی جائے اس پر زیادہ کنٹرول دیتا ہے، اور توثیق کار کو یکجا کرنے کو سپورٹ کرتا ہے۔ ان سولو اسٹیکرز کے لیے جو وقت کے ساتھ انعامات جمع کرتے ہیں، اس کا مطلب ہے کہ ان کا مؤثر بیلنس—اور اس طرح ان کے انعامات—بغیر کسی دستی مداخلت کے 32 ETH سے آگے بڑھ سکتے ہیں۔ + +**اہم:** ایک بار جب آپ `0x01` سے `0x02` میں تبدیل ہو جاتے ہیں، تو آپ واپس نہیں جا سکتے۔ + +ٹائپ 2 کریڈنشیلز میں تبدیل کرنے اور MaxEB فیچر پر ایک تفصیلی گائیڈ کے لیے، [MaxEB explainer page](/roadmap/pectra/maxeb/) دیکھیں۔ + +## مجھے کیا چننا چاہیے؟ {#what-should-i-pick} + +- **نئے توثیق کار:** `0x02` منتخب کریں۔ یہ بہتر کمپاؤنڈنگ اور لچک کے ساتھ جدید معیار ہے۔ +- **موجودہ 0x01 توثیق کار:** `0x02` میں تبدیل کرنے پر غور کریں اگر آپ چاہتے ہیں کہ انعامات 32 ETH سے اوپر کمپاؤنڈ ہوں یا توثیق کاروں کو یکجا کرنے کا ارادہ رکھتے ہیں۔ +- **موجودہ 0x00 توثیق کار:** فوراً اپ گریڈ کریں—آپ اپنے کریڈنشیلز کو اپ ڈیٹ کیے بغیر رقم نہیں نکال سکتے۔ آپ کو پہلے `0x01` میں تبدیل کرنا ہوگا، پھر آپ `0x02` میں تبدیل کر سکتے ہیں۔ + +## رقم نکالنے کے کریڈنشیلز کا انتظام کرنے کے ٹولز {#withdrawal-credential-tools} + +کئی ٹولز کریڈنشیل کی اقسام کے درمیان انتخاب کرنے یا تبدیل کرنے کو سپورٹ کرتے ہیں: + +- **[Ethereum Staking Launchpad](https://launchpad.ethereum.org/en/validator-actions)** - ڈیپازٹس اور توثیق کار کے انتظام کے لیے آفیشل ٹول، بشمول کریڈنشیل کی تبدیلیوں اور یکجا کرنے کے۔ +- **[Pectra Staking Manager](https://pectrastaking.com)** - تبدیلیوں اور یکجا کرنے کے لیے والیٹ-کنیکٹ سپورٹ کے ساتھ ویب UI +- **[Pectra Validator Ops CLI Tool](https://github.com/Luganodes/Pectra-Batch-Contract)** - بیچ کی تبدیلیوں کے لیے کمانڈ لائن ٹول +- **[Ethereal](https://github.com/wealdtech/ethereal)** - Ethereum آپریشنز کے لیے CLI ٹول، بشمول توثیق کار کے انتظام کے + +یکجا کرنے کے ٹولز کی مکمل فہرست اور تفصیلی تبدیلی کی ہدایات کے لیے، [MaxEB consolidation tooling](/roadmap/pectra/maxeb/#consolidation-tooling) دیکھیں۔ + +## مزید پڑھیں {#further-reading} + +- [پروف-آف-اسٹیک Ethereum میں کیز](/developers/docs/consensus-mechanisms/pos/keys/) - توثیق کار کیز اور وہ رقم نکالنے کے کریڈنشیلز سے کیسے تعلق رکھتی ہیں، اس کے بارے میں جانیں۔ +- [MaxEB](/roadmap/pectra/maxeb/) - Pectra اپ گریڈ اور زیادہ سے زیادہ مؤثر بیلنس فیچر پر تفصیلی گائیڈ۔ diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..5e30f2fa460 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: "کام کا ثبوت (PoW)" +description: "کام کے ثبوت پر مبنی اتفاق رائے پروٹوکول اور Ethereum میں اس کے کردار کی وضاحت۔" +lang: ur-in +--- + +Ethereum نیٹ ورک نے ایک اتفاق رائے کے طریقہ کار کا استعمال کرتے ہوئے شروع کیا جس میں **[کام کا ثبوت (PoW)](/developers/docs/consensus-mechanisms/pow)** شامل تھا۔ اس نے Ethereum نیٹ ورک کے نوڈس کو Ethereum بلاک چین پر ریکارڈ کی گئی تمام معلومات کی حالت پر متفق ہونے کی اجازت دی اور کچھ قسم کے معاشی حملوں کو روکا۔ تاہم، Ethereum نے 2022 میں کام کے ثبوت کو بند کر دیا اور اس کے بجائے [اسٹیک کا ثبوت](/developers/docs/consensus-mechanisms/pos) استعمال کرنا شروع کر دیا۔ + + + + + + کام کا ثبوت اب متروک ہو چکا ہے۔ Ethereum اب اپنے اتفاق رائے کے طریقہ کار کے حصے کے طور پر کام کے ثبوت کا استعمال نہیں کرتا۔ اس کے بجائے، یہ اسٹیک کے ثبوت کا استعمال کرتا ہے۔ [اسٹیک کے ثبوت](/developers/docs/consensus-mechanisms/pos/) اور [اسٹیکنگ](/staking/) پر مزید پڑھیں۔ + + + + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ٹرانزیکشنز](/developers/docs/transactions/)، [بلاکس](/developers/docs/blocks/)، اور [اتفاق رائے کے طریقہ کار](/developers/docs/consensus-mechanisms/) کے بارے میں پڑھیں۔ + +## کام کا ثبوت (PoW) کیا ہے؟ {#what-is-pow} + +ناکاموٹو اتفاق رائے، جو کام کے ثبوت کا استعمال کرتا ہے، وہ طریقہ کار ہے جس نے ایک بار غیر مرکزی Ethereum نیٹ ورک کو اکاؤنٹ بیلنس اور ٹرانزیکشنز کی ترتیب جیسی چیزوں پر اتفاق رائے (یعنی، تمام نوڈس متفق ہیں) پر آنے کی اجازت دی تھی۔ اس نے صارفین کو اپنے سکوں کی "ڈبل اسپینڈنگ" سے روکا اور یہ یقینی بنایا کہ Ethereum چین پر حملہ کرنا یا اس میں ہیرا پھیری کرنا انتہائی مشکل تھا۔ یہ حفاظتی خصوصیات اب [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) کے نام سے جانے جانے والے اتفاق رائے کے طریقہ کار کا استعمال کرتے ہوئے اسٹیک کے ثبوت سے آتی ہیں۔ + +## کام کا ثبوت اور مائننگ {#pow-and-mining} + +کام کا ثبوت وہ بنیادی الگورتھم ہے جو کام کے ثبوت والے بلاک چینز پر مائنرز کے کام کے لیے مشکل اور اصول طے کرتا ہے۔ مائننگ خود "کام" ہے۔ یہ چین میں درست بلاکس شامل کرنے کا عمل ہے۔ یہ اہم ہے کیونکہ چین کی لمبائی نیٹ ورک کو بلاک چین کے صحیح فورک کو فالو کرنے میں مدد کرتی ہے۔ جتنا زیادہ "کام" کیا جائے گا، چین اتنی ہی لمبی ہوگی، اور بلاک نمبر جتنا زیادہ ہوگا، نیٹ ورک چیزوں کی موجودہ حالت کے بارے میں اتنا ہی زیادہ یقینی ہو سکتا ہے۔ + +[مائننگ پر مزید](/developers/docs/consensus-mechanisms/pow/mining/) + +## Ethereum کا کام کا ثبوت کیسے کام کرتا تھا؟ {#how-it-works} + +Ethereum ٹرانزیکشنز کو بلاکس میں پراسیس کیا جاتا ہے۔ اب متروک کام کے ثبوت والے Ethereum میں، ہر بلاک میں شامل تھا: + +- بلاک کی مشکل – مثال کے طور پر: 3,324,092,183,262,715 +- mixHash – مثال کے طور پر: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce – مثال کے طور پر: `0xd3ee432b4fb3d26b` + +یہ بلاک ڈیٹا براہ راست کام کے ثبوت سے متعلق تھا۔ + +### کام کے ثبوت میں کام {#the-work} + +کام کے ثبوت کا پروٹوکول، Ethash، مائنرز سے تقاضا کرتا تھا کہ وہ ایک بلاک کے لیے نانس (nonce) تلاش کرنے کے لیے آزمائش اور غلطی کی ایک شدید دوڑ سے گزریں۔ صرف ایک درست نانس (nonce) والے بلاکس کو ہی چین میں شامل کیا جا سکتا تھا۔ + +ایک بلاک بنانے کی دوڑ میں، ایک مائنر بار بار ایک ڈیٹاسیٹ، جو صرف پوری چین کو ڈاؤن لوڈ اور چلا کر حاصل کیا जा सकता था (جیسا کہ ایک مائنر کرتا ہے)، کو ایک ریاضیاتی فنکشن کے ذریعے ڈالتا تھا۔ ڈیٹاسیٹ کا استعمال ایک ایسے ہدف سے نیچے ایک mixHash پیدا کرنے کے لیے کیا جاتا تھا جو بلاک کی مشکل سے طے ہوتا ہے۔ ایسا کرنے کا بہترین طریقہ آزمائش اور غلطی ہے۔ + +مشکل نے ہیش کے لیے ہدف کا تعین کیا۔ ہدف جتنا کم ہوگا، درست ہیشز کا سیٹ اتنا ہی چھوٹا ہوگا۔ ایک بار پیدا ہونے کے بعد، دوسرے مائنرز اور کلائنٹس کے لیے اس کی تصدیق کرنا ناقابل یقین حد تک آسان تھا۔ اگر ایک ٹرانزیکشن بھی بدل جائے، تو ہیش بالکل مختلف ہو جائے گا، جو دھوکہ دہی کا اشارہ دے گا۔ + +ہیشنگ دھوکہ دہی کو پکڑنا آسان بناتی ہے۔ لیکن ایک عمل کے طور پر کام کا ثبوت بھی چین پر حملہ کرنے میں ایک بڑی رکاوٹ تھا۔ + +### کام کا ثبوت اور سیکیورٹی {#security} + +مائنرز کو مرکزی Ethereum چین پر یہ کام کرنے کی ترغیب دی گئی تھی۔ مائنرز کے ایک ذیلی سیٹ کے لیے اپنی چین شروع کرنے کی بہت کم ترغیب تھی — یہ نظام کو کمزور کرتا ہے۔ بلاک چینز سچائی کے ذریعہ کے طور پر ایک واحد حالت رکھنے پر انحصار کرتے ہیں۔ + +کام کے ثبوت کا مقصد چین کو بڑھانا تھا۔ سب سے لمبی چین سب سے زیادہ قابل اعتبار تھی کیونکہ اسے پیدا کرنے کے لیے سب سے زیادہ کمپیوٹیشنل کام کیا گیا تھا۔ Ethereum کے PoW نظام کے اندر، ایسے نئے بلاکس بنانا جو ٹرانزیکشنز کو مٹا دیں، جعلی بنائیں، یا دوسری چین کو برقرار رکھیں، تقریبا ناممکن تھا۔ اس کی وجہ یہ ہے کہ ایک بدنیتی پر مبنی مائنر کو باقی سب سے تیز ہمیشہ بلاک نانس (nonce) حل کرنے کی ضرورت ہوتی۔ + +مسلسل بدنیتی پر مبنی لیکن درست بلاکس بنانے کے لیے، ایک بدنیتی پر مبنی مائنر کو باقی سب کو شکست دینے کے لیے نیٹ ورک کی 51% سے زیادہ مائننگ پاور کی ضرورت ہوتی۔ اس مقدار کے "کام" کے لیے بہت زیادہ مہنگی کمپیوٹنگ پاور کی ضرورت ہوتی ہے اور خرچ کی گئی توانائی حملے میں حاصل ہونے والے فوائد سے بھی زیادہ ہو سکتی تھی۔ + +### کام کے ثبوت کی معاشیات {#economics} + +کام کا ثبوت سسٹم میں نئی کرنسی جاری کرنے اور مائنرز کو کام کرنے کی ترغیب دینے کا بھی ذمہ دار تھا۔ + +[Constantinople اپ گریڈ](/ethereum-forks/#constantinople) کے بعد سے، کامیابی سے ایک بلاک بنانے والے مائنرز کو دو نئے بنائے گئے ETH اور ٹرانزیکشن فیس کا ایک حصہ انعام میں دیا جاتا تھا۔ اومر بلاکس نے بھی 1.75 ETH کا معاوضہ دیا۔ اومر بلاکس درست بلاکس تھے جو ایک مائنر نے عملی طور پر اسی وقت بنائے تھے جب دوسرے مائنر نے کینونیکل بلاک بنایا تھا، جس کا تعین بالآخر اس بات سے ہوتا تھا کہ کون سی چین پہلے بنائی گئی تھی۔ اومر بلاکس عام طور پر نیٹ ورک کی تاخیر کی وجہ سے ہوتے تھے۔ + +## حتمیت {#finality} + +Ethereum پر ایک ٹرانزیکشن میں "حتمیت" ہوتی ہے جب وہ ایک ایسے بلاک کا حصہ ہو جو بدل نہیں سکتا۔ + +چونکہ مائنرز ایک غیر مرکزی طریقے سے کام کرتے تھے، ایک ہی وقت میں دو درست بلاکس مائن کیے جا سکتے تھے۔ یہ ایک عارضی فورک بناتا ہے۔ بالآخر، ان میں سے ایک چین بعد کے بلاکس کے مائن ہونے اور اس میں شامل ہونے کے بعد قبول شدہ چین بن گئی، جس سے وہ لمبی ہو گئی۔ + +معاملات کو مزید پیچیدہ بنانے کے لیے، عارضی فورک پر مسترد کی گئی ٹرانزیکشنز شاید قبول شدہ چین میں شامل نہ ہوئی ہوں۔ اس کا مطلب ہے کہ اسے الٹا کیا جا سکتا ہے۔ لہذا حتمیت اس وقت کا حوالہ دیتی ہے جس کا آپ کو کسی ٹرانزیکشن کو ناقابل واپسی سمجھنے سے پہلے انتظار کرنا چاہئے۔ پچھلے کام کے ثبوت والے Ethereum کے تحت، ایک مخصوص بلاک `N` کے اوپر جتنے زیادہ بلاکس مائن کیے جاتے، اتنا ہی زیادہ اعتماد ہوتا کہ `N` میں ٹرانزیکشنز کامیاب تھیں اور انہیں واپس نہیں کیا جائے گا۔ اب، اسٹیک کے ثبوت کے ساتھ، حتمی شکل دینا ایک بلاک کی امکانی خاصیت کے بجائے ایک واضح خاصیت ہے۔ + +## کام کے ثبوت کا توانائی کا استعمال {#energy} + +کام کے ثبوت پر ایک بڑی تنقید توانائی کی وہ مقدار ہے جو نیٹ ورک کو محفوظ رکھنے کے لیے درکار ہوتی ہے۔ سیکیورٹی اور غیر مرکزیت کو برقرار رکھنے کے لیے، کام کے ثبوت پر Ethereum نے بڑی مقدار میں توانائی استعمال کی۔ اسٹیک کے ثبوت پر سوئچ کرنے سے کچھ دیر پہلے، Ethereum کے مائنرز اجتماعی طور پر تقریبا 70 TWh/yr (تقریبا چیک جمہوریہ کے برابر - [digiconomist](https://digiconomist.net/) کے مطابق 18-جولائی-2022 کو) استعمال کر رہے تھے۔ + +## فائدے اور نقصانات {#pros-and-cons} + +| فوائد | نقصانات | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| کام کا ثبوت غیر جانبدار ہے۔ شروع کرنے کے لیے آپ کو ETH کی ضرورت نہیں ہے اور بلاک انعامات آپ کو 0ETH سے مثبت بیلنس تک جانے کی اجازت دیتے ہیں۔ [اسٹیک کے ثبوت](/developers/docs/consensus-mechanisms/pos/) کے ساتھ آپ کو شروع کرنے کے لیے ETH کی ضرورت ہے۔ | کام کا ثبوت اتنی زیادہ توانائی استعمال کرتا ہے کہ یہ ماحول کے لیے برا ہے۔ | +| کام کا ثبوت ایک آزمایا ہوا اور پرکھا ہوا اتفاق رائے کا طریقہ کار ہے جس نے کئی سالوں تک Bitcoin اور Ethereum کو محفوظ اور غیر مرکزی رکھا ہے۔ | اگر آپ مائننگ کرنا چاہتے ہیں، تو آپ کو ایسے خصوصی آلات کی ضرورت ہے کہ شروع کرنا ایک بڑی سرمایہ کاری ہے۔ | +| اسٹیک کے ثبوت کے مقابلے میں اسے نافذ کرنا نسبتاً آسان ہے۔ | بڑھتی ہوئی کمپیوٹیشن کی ضرورت کی وجہ سے، مائننگ پولز ممکنہ طور پر مائننگ کے کھیل پر غلبہ حاصل کر سکتے ہیں، جو مرکزیت اور سیکیورٹی کے خطرات کا باعث بنتا ہے۔ | + +## اسٹیک کے ثبوت کے مقابلے میں {#compared-to-pos} + +اعلی سطح پر، اسٹیک کے ثبوت کا وہی آخری مقصد ہے جو کام کے ثبوت کا ہے: غیر مرکزی نیٹ ورک کو محفوظ طریقے سے اتفاق رائے تک پہنچنے میں مدد کرنا۔ لیکن اس کے عمل اور اہلکاروں میں کچھ فرق ہیں: + +- اسٹیک کا ثبوت کمپیوٹیشنل پاور کی اہمیت کو اسٹیک شدہ ETH سے بدل دیتا ہے۔ +- اسٹیک کا ثبوت مائنرز کو ویلیڈیٹرز سے بدل دیتا ہے۔ ویلیڈیٹرز نئے بلاکس بنانے کی صلاحیت کو فعال کرنے کے لیے اپنے ETH کو اسٹیک کرتے ہیں۔ +- ویلیڈیٹرز بلاکس بنانے کے لیے مقابلہ نہیں کرتے ہیں، اس کے بجائے انہیں ایک الگورتھم کے ذریعے تصادفی طور پر منتخب کیا جاتا ہے۔ +- حتمیت زیادہ واضح ہے: کچھ مخصوص چیک پوائنٹس پر، اگر 2/3 ویلیڈیٹرز بلاک کی حالت پر متفق ہوں تو اسے حتمی سمجھا جاتا ہے۔ ویلیڈیٹرز کو اس پر اپنا پورا اسٹیک داؤ پر لگانا ہوگا، لہذا اگر وہ بعد میں ملی بھگت کرنے کی کوشش کرتے ہیں، تو وہ اپنا پورا اسٹیک کھو دیں گے۔ + +[اسٹیک کے ثبوت پر مزید](/developers/docs/consensus-mechanisms/pos/) + +## کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + + + +## مزید مطالعہ {#further-reading} + +- [اکثریتی حملہ](https://en.bitcoin.it/wiki/Majority_attack) +- [سیٹلمنٹ کی حتمیت پر](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### ویڈیوز {#videos} + +- [کام کے ثبوت پروٹوکولز کی تکنیکی وضاحت](https://youtu.be/9V1bipPkCTU) + +## متعلقہ موضوعات {#related-topics} + +- [مائننگ](/developers/docs/consensus-mechanisms/pow/mining/) +- [ثبوتِ حصص (Proof-of-stake)](/developers/docs/consensus-mechanisms/pos/) +- [ثبوتِ اختیار (Proof-of-authority)](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..d8f0de8ba8f --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "کان کنی" +description: "ایتھریم پر کان کنی کیسے کام کرتی تھی اس کی وضاحت۔" +lang: ur-in +--- + + + + + +کام کا ثبوت اب ایتھریم کے اتفاق رائے کے طریقہ کار کی بنیاد نہیں ہے، جس کا مطلب ہے کہ کان کنی کو بند کر دیا گیا ہے۔ اس کے بجائے، ایتھریم کو توثیق کنندگان کے ذریعے محفوظ کیا جاتا ہے جو ETH کو اسٹیک کرتے ہیں۔ آپ آج ہی اپنے ETH کو اسٹیک کرنا شروع کر سکتے ہیں۔ مرج، حصص کے ثبوت، اور اسٹیکنگ پر مزید پڑھیں۔ یہ صفحہ صرف تاریخی دلچسپی کے لیے ہے۔ + + + + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [لین دین](/developers/docs/transactions/)، [بلاکس](/developers/docs/blocks/) اور [کام کا ثبوت](/developers/docs/consensus-mechanisms/pow/) کے بارے میں پڑھیں۔ + +## ایتھریم کان کنی کیا ہے؟ {#what-is-ethereum-mining} + +کان کنی ایتھریم کے اب متروک کام کے ثبوت کے فن تعمیر میں ایتھریم بلاک چین میں شامل کیے جانے والے لین دین کا ایک بلاک بنانے کا عمل ہے۔ + +کان کنی کا لفظ کرپٹو کرنسیوں کے لیے سونے کی مثال کے تناظر میں شروع ہوا ہے۔ سونا یا قیمتی دھاتیں نایاب ہیں، اسی طرح ڈیجیٹل ٹوکن بھی ہیں، اور کام کا ثبوت والے نظام میں کل حجم کو بڑھانے کا واحد طریقہ کان کنی کے ذریعے ہے۔ کام کا ثبوت والے ایتھریم میں، اجراء کا واحد طریقہ کان کنی کے ذریعے تھا۔ تاہم، سونے یا قیمتی دھاتوں کے برعکس، ایتھریم کان کنی بلاک چین میں بلاکس بنا کر، تصدیق کر کے، شائع کر کے اور پھیلا کر نیٹ ورک کو محفوظ بنانے کا بھی ایک طریقہ تھا۔ + +ایتھر کی کان کنی = نیٹ ورک کو محفوظ بنانا + +کان کنی کسی بھی کام کا ثبوت والے بلاک چین کی جان ہے۔ ایتھریم کان کن - سافٹ ویئر چلانے والے کمپیوٹر - نے حصص کے ثبوت میں منتقلی سے پہلے لین دین پر کارروائی کرنے اور بلاکس تیار کرنے کے لیے اپنا وقت اور کمپیوٹیشنل طاقت استعمال کی۔ + +## کان کن کیوں موجود ہیں؟ {#why-do-miners-exist} + +ایتھریم جیسے غیر مرکزی نظاموں میں، ہمیں یہ یقینی بنانے کی ضرورت ہے کہ ہر کوئی لین دین کی ترتیب پر متفق ہو۔ کان کنوں نے بلاکس تیار کرنے کے لیے حسابی طور پر مشکل پہیلیاں حل کرکے، نیٹ ورک کو حملوں سے محفوظ بنا کر ایسا کرنے میں مدد کی۔ + +[کام کے ثبوت پر مزید](/developers/docs/consensus-mechanisms/pow/) + +پہلے کوئی بھی اپنے کمپیوٹر کا استعمال کرکے ایتھریم نیٹ ورک پر کان کنی کرنے کے قابل تھا۔ تاہم، ہر کوئی منافع بخش طریقے سے ایتھر (ETH) کی کان کنی نہیں کر سکتا تھا۔ زیادہ تر معاملات میں، کان کنوں کو مخصوص کمپیوٹر ہارڈویئر خریدنا پڑتا تھا، اور سستے توانائی کے ذرائع تک رسائی حاصل کرنی پڑتی تھی۔ اوسط کمپیوٹر کے کان کنی سے وابستہ اخراجات کو پورا کرنے کے لیے کافی بلاک انعامات حاصل کرنے کا امکان نہیں تھا۔ + +### کان کنی کی لاگت {#cost-of-mining} + +- کان کنی کی رگ بنانے اور اسے برقرار رکھنے کے لیے ضروری ہارڈویئر کی ممکنہ لاگت +- کان کنی کی رگ کو بجلی فراہم کرنے کی برقی لاگت +- اگر آپ کسی پول میں کان کنی کر رہے تھے، تو یہ پول عام طور پر پول کے ذریعے پیدا ہونے والے ہر بلاک کی ایک فلیٹ % فیس وصول کرتے تھے +- کان کنی کی رگ کو سپورٹ کرنے کے لیے آلات کی ممکنہ لاگت (وینٹیلیشن، توانائی کی نگرانی، بجلی کی وائرنگ، وغیرہ۔) + +کان کنی کے منافع کو مزید دریافت کرنے کے لیے، کان کنی کیلکولیٹر کا استعمال کریں، جیسا کہ [Etherscan](https://etherscan.io/ether-mining-calculator) فراہم کرتا ہے۔ + +## ایتھریم لین دین کی کان کنی کیسے کی گئی {#how-ethereum-transactions-were-mined} + +درج ذیل اس بات کا ایک جائزہ فراہم کرتا ہے کہ ایتھریم کام کے ثبوت میں لین دین کی کان کنی کیسے کی جاتی تھی۔ ایتھریم حصص کے ثبوت کے لیے اس عمل کی ایک مشابہ وضاحت [یہاں](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) مل سکتی ہے۔ + +1. ایک صارف کسی [اکاؤنٹ](/developers/docs/accounts/) کی نجی کلید کے ساتھ [لین دین](/developers/docs/transactions/) کی درخواست لکھتا اور اس پر دستخط کرتا ہے۔ +2. صارف کسی [نوڈ](/developers/docs/nodes-and-clients/) سے پورے ایتھریم نیٹ ورک پر لین دین کی درخواست کو نشر کرتا ہے۔ +3. نئی لین دین کی درخواست کے بارے میں سننے پر، ایتھریم نیٹ ورک کا ہر نوڈ درخواست کو اپنے مقامی میمپول میں شامل کرتا ہے، جو ان تمام لین دین کی درخواستوں کی ایک فہرست ہے جن کے بارے میں انہوں نے سنا ہے جو ابھی تک کسی بلاک میں بلاک چین کے لیے پرعزم نہیں ہیں۔ +4. کچھ موقع پر، ایک کان کنی نوڈ کئی درجن یا سو لین دین کی درخواستوں کو ایک ممکنہ [بلاک](/developers/docs/blocks/) میں جمع کرتا ہے، اس طرح سے کہ وہ [لین دین کی فیس](/developers/docs/gas/) کو زیادہ سے زیادہ کرتا ہے جو وہ بلاک گیس کی حد کے اندر رہتے ہوئے کماتے ہیں۔ پھر کان کنی نوڈ: + 1. ہر لین دین کی درخواست کی صداقت کی تصدیق کرتا ہے (یعنی، کوئی بھی ایسے اکاؤنٹ سے ایتھر منتقل کرنے کی کوشش نہیں کر رہا ہے جس کے لیے انہوں نے دستخط نہیں کیے ہیں، درخواست غلط نہیں ہے، وغیرہ)، اور پھر درخواست کے کوڈ پر عمل کرتا ہے، EVM کی اپنی مقامی کاپی کی حالت کو تبدیل کرتا ہے۔ کان کن ہر ایسی لین دین کی درخواست کے لیے لین دین کی فیس اپنے اکاؤنٹ میں دیتا ہے۔ + 2. ممکنہ بلاک کے لیے کام کے ثبوت کا "جائز ہونے کا سرٹیفکیٹ" بنانے کا عمل شروع کرتا ہے، ایک بار جب بلاک میں تمام لین دین کی درخواستوں کی تصدیق ہو جاتی ہے اور مقامی EVM کاپی پر عمل درآمد ہو جاتا ہے۔ +5. بالآخر، ایک کان کن ایک ایسے بلاک کے لیے سرٹیفکیٹ بنانا ختم کر دے گا جس میں ہماری مخصوص لین دین کی درخواست شامل ہے۔ پھر کان کن مکمل شدہ بلاک کو نشر کرتا ہے، جس میں سرٹیفکیٹ اور دعوی کردہ نئی EVM حالت کا ایک چیکسم شامل ہوتا ہے۔ +6. دوسرے نوڈز نئے بلاک کے بارے میں سنتے ہیں۔ وہ سرٹیفکیٹ کی تصدیق کرتے ہیں، بلاک پر تمام لین دین خود انجام دیتے ہیں (بشمول ہمارے صارف کے ذریعہ اصل میں نشر کردہ لین دین)، اور تصدیق کرتے ہیں کہ تمام لین دین کے عمل کے بعد ان کی نئی EVM حالت کا چیکسم کان کن کے بلاک کے ذریعہ دعوی کردہ حالت کے چیکسم سے میل کھاتا ہے۔ تب ہی یہ نوڈز اس بلاک کو اپنے بلاک چین کے آخر میں جوڑتے ہیں، اور نئی EVM حالت کو کینونیکل حالت کے طور پر قبول کرتے ہیں۔ +7. ہر نوڈ نئے بلاک میں تمام لین دین کو اپنے مقامی میمپول سے نامکمل لین دین کی درخواستوں سے ہٹا دیتا ہے۔ +8. نیٹ ورک میں شامل ہونے والے نئے نوڈز ترتیب میں تمام بلاکس ڈاؤن لوڈ کرتے ہیں، بشمول وہ بلاک جس میں ہماری دلچسپی کا لین دین ہوتا ہے۔ وہ ایک مقامی EVM کاپی شروع کرتے ہیں (جو ایک خالی حالت EVM کے طور پر شروع ہوتی ہے)، اور پھر اپنی مقامی EVM کاپی کے اوپر ہر بلاک میں ہر لین دین کو انجام دینے کے عمل سے گزرتے ہیں، راستے میں ہر بلاک پر حالت کے چیکسم کی تصدیق کرتے ہیں۔ + +ہر لین دین کی ایک بار کان کنی کی جاتی ہے (ایک نئے بلاک میں شامل کیا جاتا ہے اور پہلی بار پھیلایا جاتا ہے)، لیکن کینونیکل EVM حالت کو آگے بڑھانے کے عمل میں ہر شریک کے ذریعہ اس پر عمل کیا جاتا ہے اور اس کی تصدیق کی جاتی ہے۔ یہ بلاک چین کے مرکزی منتروں میں سے ایک کو اجاگر کرتا ہے: **بھروسہ نہ کریں، تصدیق کریں**۔ + +## اومر (انکل) بلاکس {#ommer-blocks} + +کام کے ثبوت پر بلاک کان کنی امکانی تھی، یعنی کبھی کبھی نیٹ ورک کی تاخیر کی وجہ سے دو درست بلاکس بیک وقت شائع ہو جاتے تھے۔ اس معاملے میں، پروٹوکول کو سب سے لمبی (اور اس لیے سب سے زیادہ "درست") چین کا تعین کرنا پڑا جبکہ کان کنوں کے ساتھ انصاف کو یقینی بناتے ہوئے غیر شامل درست بلاک کو جزوی طور پر انعام دیا گیا۔ اس نے نیٹ ورک کو مزید غیر مرکزی بنانے کی حوصلہ افزائی کی کیونکہ چھوٹے کان کن، جنہیں زیادہ تاخیر کا سامنا کرنا پڑ سکتا ہے، وہ اب بھی [اومر](/glossary/#ommer) بلاک انعامات کے ذریعے منافع کما سکتے ہیں۔ + +اصطلاح "اومر" ایک پیرنٹ بلاک کے بہن بھائی کے لیے ترجیحی صنفی غیر جانبدار اصطلاح ہے، لیکن اسے کبھی کبھی "انکل" بھی کہا جاتا ہے۔ **ایتھریم کے حصص کے ثبوت کی طرف منتقلی کے بعد سے، اومر بلاکس کی مزید کان کنی نہیں کی جاتی ہے** کیونکہ ہر سلاٹ میں صرف ایک تجویز کنندہ منتخب کیا جاتا ہے۔ آپ یہ تبدیلی کان کنی کیے گئے اومر بلاکس کے [تاریخی چارٹ](https://ycharts.com/indicators/ethereum_uncle_rate) کو دیکھ کر دیکھ سکتے ہیں۔ + +## ایک بصری ڈیمو {#a-visual-demo} + +آسٹن کو کان کنی اور کام کے ثبوت والے بلاک چین کے بارے میں بتاتے ہوئے دیکھیں۔ + + + +## کان کنی کا الگورتھم {#mining-algorithm} + +ایتھریم مین نیٹ نے صرف ایک کان کنی الگورتھم کا استعمال کیا - ['ایتھیش'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)۔ ایتھیش ایک اصل R&D الگورتھم کا جانشین تھا جسے ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) کے نام سے جانا جاتا ہے۔ + +[کان کنی کے الگورتھم پر مزید](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/)۔ + +## متعلقہ موضوعات {#related-topics} + +- [گیس](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [ثبوتِ کار (Proof-of-work)](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..8b393c5d5f6 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,330 @@ +--- +title: Dagger-Hashimoto +description: "Dagger-Hashimoto الگورتھم پر ایک تفصیلی نظر۔" +lang: ur-in +--- + +Dagger-Hashimoto Ethereum کے مائننگ الگورتھم کے لیے اصل تحقیقی نفاذ اور تفصیلات تھیں۔ [Ethash](#ethash) نے Dagger-Hashimoto کی جگہ لے لی۔ 15 ستمبر 2022 کو [The Merge](/roadmap/merge/) پر مائننگ مکمل طور پر بند کر دی گئی تھی۔ تب سے، Ethereum کو اس کے بجائے [proof-of-stake](/developers/docs/consensus-mechanisms/pos) میکانزم کا استعمال کرکے محفوظ کیا گیا ہے۔ یہ صفحہ تاریخی دلچسپی کے لیے ہے - یہاں دی گئی معلومات The Merge کے بعد کے Ethereum کے لیے اب متعلقہ نہیں ہیں۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [proof-of-work consensus](/developers/docs/consensus-mechanisms/pow)، [مائننگ](/developers/docs/consensus-mechanisms/pow/mining)، اور [مائننگ الگورتھم](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) کے بارے میں پڑھیں۔ + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto کا مقصد دو اہداف کو پورا کرنا ہے: + +1. **ASIC-مزاحمت**: الگورتھم کے لیے خصوصی ہارڈ ویئر بنانے سے فائدہ ہر ممکن حد تک کم ہونا چاہیے۔ +2. **لائٹ کلائنٹ کی تصدیق کی اہلیت**: ایک بلاک کی لائٹ کلائنٹ کے ذریعے مؤثر طریقے سے تصدیق کی جانی چاہیے۔ + +ایک اضافی ترمیم کے ساتھ، ہم یہ بھی بتاتے ہیں کہ اگر چاہیں تو تیسرے مقصد کو کیسے پورا کیا جائے، لیکن اضافی پیچیدگی کی قیمت پر: + +**مکمل چین اسٹوریج**: مائننگ کے لیے مکمل بلاک چین اسٹیٹ کے اسٹوریج کی ضرورت ہونی چاہیے (Ethereum اسٹیٹ ٹرائی کی بے قاعدہ ساخت کی وجہ سے، ہم توقع کرتے ہیں کہ کچھ کانٹ چھانٹ ممکن ہو گی، خاص طور پر کچھ اکثر استعمال ہونے والے معاہدوں کی، لیکن ہم اسے کم سے کم کرنا چاہتے ہیں)۔ + +## DAG جنریشن {#dag-generation} + +الگورتھم کا کوڈ ذیل میں Python میں بیان کیا جائے گا۔ سب سے پہلے، ہم مخصوص درستگی کے غیر دستخط شدہ انٹس کو سٹرنگز میں مارشل کرنے کے لیے `encode_int` دیتے ہیں۔ اس کا الٹا بھی دیا گیا ہے: + +```python +NUM_BITS = 512 + +def encode_int(x): + "ایک big-endian اسکیم کا استعمال کرتے ہوئے ایک انٹیجر x کو 64 حروف کی ایک سٹرنگ کے طور پر انکوڈ کریں" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "ایک big-endian اسکیم کا استعمال کرتے ہوئے ایک سٹرنگ سے ایک انٹیجر x کو انکوڈ کریں" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +ہم آگے یہ فرض کرتے ہیں کہ `sha3` ایک فنکشن ہے جو ایک انٹیجر لیتا ہے اور ایک انٹیجر آؤٹ پٹ کرتا ہے، اور `dbl_sha3` ایک ڈبل-sha3 فنکشن ہے؛ اگر اس حوالہ جاتی کوڈ کو نفاذ میں تبدیل کر رہے ہیں تو استعمال کریں: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### پیرامیٹرز {#parameters} + +الگورتھم کے لیے استعمال ہونے والے پیرامیٹرز یہ ہیں: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # 2**512 سے کم سب سے بڑا سیف پرائم + +params = { + "n": 4000055296 * 8 // NUM_BITS, # ڈیٹاسیٹ کا سائز (4 گیگا بائٹس)؛ 65536 کا ملٹیپل ہونا چاہیے + "n_inc": 65536, # فی مدت n کی قدر میں اضافہ؛ 65536 کا ملٹیپل ہونا چاہیے + # epochtime=20000 کے ساتھ فی سال 882 MB کی نمو دیتا ہے + "cache_size": 2500, # لائٹ کلائنٹ کے کیشے کا سائز (لائٹ کے ذریعے منتخب کیا جا سکتا ہے + # کلائنٹ؛ الگورتھم کی تفصیلات کا حصہ نہیں) + "diff": 2**14, # مشکل (بلاک کی تشخیص کے دوران ایڈجسٹ کی گئی) + "epochtime": 100000, # بلاکس میں ایک ایپوک کی لمبائی (ڈیٹاسیٹ کتنی بار اپ ڈیٹ ہوتا ہے) + "k": 1, # ایک نوڈ کے والدین کی تعداد + "w": w, # ماڈیولر ایکسپونینشن ہیشنگ کے لیے استعمال کیا جاتا ہے + "accesses": 200, # ہاشیموٹو کے دوران ڈیٹاسیٹ تک رسائی کی تعداد + "P": SAFE_PRIME_512 # ہیشنگ اور بے ترتیب نمبر بنانے کے لیے سیف پرائم +} +``` + +اس معاملے میں `P` ایک پرائم ہے جسے اس طرح منتخب کیا گیا ہے کہ `log₂(P)` 512 سے تھوڑا کم ہے، جو ان 512 بٹس سے مطابقت رکھتا ہے جنہیں ہم اپنے نمبروں کی نمائندگی کے لیے استعمال کر رہے ہیں۔ نوٹ کریں کہ اصل میں DAG کے صرف آخری نصف کو ذخیرہ کرنے کی ضرورت ہے، لہذا ڈی-فیکٹو RAM کی ضرورت 1 GB سے شروع ہوتی ہے اور فی سال 441 MB بڑھتی ہے۔ + +### Dagger گراف بنانا {#dagger-graph-building} + +Dagger گراف بنانے کا پرمیٹیو مندرجہ ذیل طور پر بیان کیا گیا ہے: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +بنیادی طور پر، یہ ایک گراف کو ایک واحد نوڈ، `sha3(seed)` کے طور پر شروع کرتا ہے، اور وہاں سے بے ترتیب پچھلے نوڈز کی بنیاد پر ترتیب وار دوسرے نوڈز کو شامل کرنا شروع کرتا ہے۔ جب ایک نیا نوڈ بنایا جاتا ہے، تو `i` سے کم کچھ انڈیکس کو بے ترتیب طور پر منتخب کرنے کے لیے سیڈ کی ایک ماڈیولر پاور کا حساب لگایا جاتا ہے (اوپر `x % i` کا استعمال کرتے ہوئے)، اور ان انڈیکس پر نوڈز کی قدروں کو `x` کے لیے ایک نئی قدر پیدا کرنے کے لیے ایک حساب میں استعمال کیا جاتا ہے، جسے پھر ایک چھوٹے پروف آف ورک فنکشن (XOR پر مبنی) میں فیڈ کیا جاتا ہے تاکہ آخر کار انڈیکس `i` پر گراف کی قدر پیدا کی جا سکے۔ اس خاص ڈیزائن کے پیچھے استدلال DAG کی ترتیب وار رسائی کو مجبور کرنا ہے؛ DAG کی اگلی قدر جس تک رسائی حاصل کی جائے گی اس کا تعین اس وقت تک نہیں کیا جا سکتا جب تک کہ موجودہ قدر معلوم نہ ہو۔ آخر میں، ماڈیولر ایکسپونینشن نتیجے کو مزید ہیش کرتا ہے۔ + +یہ الگورتھم نمبر تھیوری کے کئی نتائج پر انحصار کرتا ہے۔ بحث کے لیے نیچے ضمیمہ دیکھیں۔ + +## لائٹ کلائنٹ کی تشخیص {#light-client-evaluation} + +مذکورہ بالا گراف کی تعمیر کا مقصد گراف میں ہر نوڈ کو صرف چند نوڈز کے سب ٹری کا حساب لگا کر دوبارہ تعمیر کرنے کی اجازت دینا ہے اور صرف تھوڑی مقدار میں معاون میموری کی ضرورت ہوتی ہے۔ نوٹ کریں کہ k=1 کے ساتھ، سب ٹری صرف DAG میں پہلے عنصر تک جانے والی قدروں کا ایک سلسلہ ہے۔ + +DAG کے لیے لائٹ کلائنٹ کمپیوٹنگ فنکشن مندرجہ ذیل طور پر کام کرتا ہے: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +بنیادی طور پر، یہ صرف مذکورہ بالا الگورتھم کی دوبارہ تحریر ہے جو پورے DAG کے لیے قدروں کا حساب لگانے کے لوپ کو ہٹاتا ہے اور پہلے والے نوڈ لک اپ کو ریکرسیو کال یا کیشے لک اپ سے بدل دیتا ہے۔ نوٹ کریں کہ `k=1` کے لیے کیشے غیر ضروری ہے، حالانکہ مزید اصلاح اصل میں DAG کی پہلی چند ہزار قدروں کا پہلے سے حساب لگاتی ہے اور اسے حساب کے لیے ایک جامد کیشے کے طور پر رکھتی ہے؛ اس کے کوڈ کے نفاذ کے لیے ضمیمہ دیکھیں۔ + +## DAGs کا ڈبل بفر {#double-buffer} + +ایک مکمل کلائنٹ میں، مذکورہ بالا فارمولے سے تیار کردہ 2 DAGs کا ایک [_ڈبل بفر_](https://wikipedia.org/wiki/Multiple_buffering) استعمال کیا جاتا ہے۔ خیال یہ ہے کہ DAGs مذکورہ بالا پیرامیٹرز کے مطابق ہر `epochtime` تعداد کے بلاکس پر تیار کیے جاتے ہیں۔ کلائنٹ تازہ ترین تیار کردہ DAG استعمال کرنے کے بجائے، پچھلا والا استعمال کرتا ہے۔ اس کا فائدہ یہ ہے کہ یہ DAGs کو وقت کے ساتھ تبدیل کرنے کی اجازت دیتا ہے بغیر کسی ایسے قدم کو شامل کرنے کی ضرورت کے جہاں مائنرز کو اچانک تمام ڈیٹا کا دوبارہ حساب لگانا پڑے۔ بصورت دیگر، باقاعدہ وقفوں پر چین پروسیسنگ میں اچانک عارضی سست روی اور مرکزیت میں ڈرامائی طور پر اضافہ ہونے کا امکان ہے۔ اس طرح تمام ڈیٹا کا دوبارہ حساب لگانے سے پہلے ان چند منٹوں کے اندر 51% حملے کا خطرہ ہوتا ہے۔ + +ایک بلاک کے لیے کام کا حساب لگانے کے لیے استعمال ہونے والے DAGs کا سیٹ بنانے کے لیے استعمال ہونے والا الگورتھم مندرجہ ذیل ہے: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # No back buffer is possible, just make front buffer + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +اصل Hashimoto کے پیچھے خیال یہ ہے کہ بلاک چین کو بطور ڈیٹاسیٹ استعمال کیا جائے، ایک ایسا حساب انجام دیا جائے جو بلاک چین سے N انڈیکس منتخب کرتا ہے، ان انڈیکس پر ٹرانزیکشنز کو جمع کرتا ہے، اس ڈیٹا کا XOR انجام دیتا ہے، اور نتیجے کا ہیش واپس کرتا ہے۔ تھڈیئس ڈرائجا کا اصل الگورتھم، مطابقت کے لیے Python میں ترجمہ کیا گیا، مندرجہ ذیل ہے: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +بدقسمتی سے، جبکہ Hashimoto کو RAM ہارڈ سمجھا جاتا ہے، یہ 256 بٹ ریاضی پر انحصار کرتا ہے، جس میں کافی کمپیوٹیشنل اوور ہیڈ ہوتا ہے۔ تاہم، Dagger-Hashimoto اس مسئلے کو حل کرنے کے لیے اپنے ڈیٹاسیٹ کو انڈیکس کرتے وقت صرف سب سے کم اہم 64 بٹس کا استعمال کرتا ہے۔ + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +ڈبل SHA3 کا استعمال صفر-ڈیٹا، قریب-فوری پری-ویریفکیشن کی ایک شکل کی اجازت دیتا ہے، صرف اس بات کی تصدیق کرتا ہے کہ ایک درست درمیانی قدر فراہم کی گئی تھی۔ پروف آف ورک کی یہ بیرونی تہہ انتہائی ASIC-فرینڈلی اور کافی کمزور ہے، لیکن DDoS کو مزید مشکل بنانے کے لیے موجود ہے کیونکہ ایک ایسا بلاک بنانے کے لیے کام کی وہ چھوٹی سی مقدار کرنا ضروری ہے جسے فوری طور پر مسترد نہیں کیا جائے گا۔ یہاں لائٹ کلائنٹ ورژن ہے: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## مائننگ اور تصدیق {#mining-and-verifying} + +اب، آئیے اس سب کو مائننگ الگورتھم میں ایک ساتھ رکھتے ہیں: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +یہاں تصدیقی الگورتھم ہے: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +لائٹ کلائنٹ فرینڈلی تصدیق: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +نیز، نوٹ کریں کہ Dagger-Hashimoto بلاک ہیڈر پر اضافی تقاضے عائد کرتا ہے: + +- دو-تہہ کی تصدیق کے کام کرنے کے لیے، ایک بلاک ہیڈر میں نونس اور درمیانی قدر دونوں پری-sha3 ہونی چاہئیں۔ +- کہیں، ایک بلاک ہیڈر کو موجودہ سیڈ سیٹ کا sha3 ذخیرہ کرنا چاہیے۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## ضمیمہ {#appendix} + +جیسا کہ اوپر ذکر کیا گیا ہے، DAG جنریشن کے لیے استعمال ہونے والا RNG نمبر تھیوری کے کچھ نتائج پر انحصار کرتا ہے۔ سب سے پہلے، ہم یہ یقین دہانی فراہم کرتے ہیں کہ Lehmer RNG جو `picker` متغیر کی بنیاد ہے اس کا ایک وسیع دور ہے۔ دوسرا، ہم دکھاتے ہیں کہ `pow(x,3,P)`، `x` کو `1` یا `P-1` پر میپ نہیں کرے گا بشرطیکہ شروع کرنے کے لیے `x ∈ [2,P-2]` ہو۔ آخر میں، ہم دکھاتے ہیں کہ جب ہیشنگ فنکشن کے طور پر علاج کیا جاتا ہے تو `pow(x,3,P)` کی تصادم کی شرح کم ہوتی ہے۔ + +### Lehmer رینڈم نمبر جنریٹر {#lehmer-random-number} + +جبکہ `produce_dag` فنکشن کو غیر جانبدارانہ بے ترتیب نمبر تیار کرنے کی ضرورت نہیں ہے، ایک ممکنہ خطرہ یہ ہے کہ `seed**i % P` صرف مٹھی بھر قدریں لیتا ہے۔ یہ ان مائنرز کو فائدہ فراہم کر سکتا ہے جو پیٹرن کو پہچانتے ہیں ان لوگوں پر جو نہیں پہچانتے ہیں۔ + +اس سے بچنے کے لیے، نمبر تھیوری کے ایک نتیجے کی اپیل کی جاتی ہے۔ ایک [_سیف پرائم_](https://en.wikipedia.org/wiki/Safe_prime) کو ایک پرائم `P` کے طور پر بیان کیا گیا ہے جیسے `(P-1)/2` بھی پرائم ہے۔ [ضرب گروپ](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` کے ایک رکن `x` کا _آرڈر_ کم سے کم `m` کے طور پر بیان کیا گیا ہے جیسے کہ
xᵐ mod P ≡ 1
+ان تعریفوں کو دیکھتے ہوئے، ہمارے پاس ہے: + +> مشاہدہ 1۔ `x` کو ایک سیف پرائم `P` کے لیے ضرب گروپ `ℤ/Pℤ` کا رکن ہونے دیں۔ اگر `x mod P ≠ 1 mod P` اور `x mod P ≠ P-1 mod P`، تو `x` کا آرڈر یا تو `P-1` ہے یا `(P-1)/2`۔ + +_ثبوت_۔ چونکہ `P` ایک سیف پرائم ہے، تب [Lagrange کے تھیورم][lagrange] کے ذریعے ہمارے پاس یہ ہے کہ `x` کا آرڈر یا تو `1`، `2`، `(P-1)/2`، یا `P-1` ہے۔ + +`x` کا آرڈر `1` نہیں ہو سکتا، چونکہ فرما کے چھوٹے تھیورم کے ذریعے ہمارے پاس ہے: + +
xP-1 mod P ≡ 1
+ +لہذا `x` کو `ℤ/nℤ` کی ایک ضربی شناخت ہونا چاہیے، جو کہ منفرد ہے۔ چونکہ ہم نے مفروضے کے مطابق یہ فرض کیا ہے کہ `x ≠ 1` ہے، یہ ممکن نہیں ہے۔ + +`x` کا آرڈر `2` نہیں ہو سکتا جب تک کہ `x = P-1` نہ ہو، چونکہ یہ اس بات کی خلاف ورزی کرے گا کہ `P` پرائم ہے۔ + +مذکورہ بالا تجویز سے، ہم یہ پہچان سکتے ہیں کہ `(picker * init) % P` کو دہرانے سے سائیکل کی لمبائی کم از کم `(P-1)/2` ہو گی۔ اس کی وجہ یہ ہے کہ ہم نے `P` کو دو کی اعلی طاقت کے تقریباً برابر ایک سیف پرائم کے طور پر منتخب کیا ہے، اور `init` وقفہ `[2,2**256+1]` میں ہے۔ `P` کی شدت کو دیکھتے ہوئے، ہمیں ماڈیولر ایکسپونینشن سے کبھی بھی سائیکل کی توقع نہیں کرنی چاہیے۔ + +جب ہم DAG میں پہلا سیل تفویض کر رہے ہیں (متغیر جس پر `init` کا لیبل لگا ہوا ہے)، ہم `pow(sha3(seed) + 2, 3, P)` کا حساب لگاتے ہیں۔ پہلی نظر میں، یہ اس بات کی ضمانت نہیں دیتا کہ نتیجہ نہ تو `1` ہے اور نہ ہی `P-1`۔ تاہم، چونکہ `P-1` ایک سیف پرائم ہے، ہمارے پاس مندرجہ ذیل اضافی یقین دہانی ہے، جو مشاہدہ 1 کا نتیجہ ہے: + +> مشاہدہ 2۔ `x` کو ایک سیف پرائم `P` کے لیے ضرب گروپ `ℤ/Pℤ` کا رکن ہونے دیں، اور `w` کو ایک قدرتی عدد ہونے دیں۔ اگر `x mod P ≠ 1 mod P` اور `x mod P ≠ P-1 mod P`، نیز `w mod P ≠ P-1 mod P` اور `w mod P ≠ 0 mod P`، تو `xʷ mod P ≠ 1 mod P` اور `xʷ mod P ≠ P-1 mod P` + +### ماڈیولر ایکسپونینشن بطور ہیش فنکشن {#modular-exponentiation} + +`P` اور `w` کی کچھ قدروں کے لیے، فنکشن `pow(x, w, P)` میں بہت سے تصادم ہو سکتے ہیں۔ مثال کے طور پر، `pow(x,9,19)` صرف `{1,18}` کی قدریں لیتا ہے۔ + +یہ دیکھتے ہوئے کہ `P` پرائم ہے، تب ایک ماڈیولر ایکسپونینشن ہیشنگ فنکشن کے لیے ایک مناسب `w` مندرجہ ذیل نتیجے کا استعمال کرتے ہوئے منتخب کیا جا سکتا ہے: + +> مشاہدہ 3۔ `P` کو ایک پرائم ہونے دیں؛ `w` اور `P-1` نسبتاً پرائم ہیں اگر اور صرف اگر `ℤ/Pℤ` میں تمام `a` اور `b` کے لیے:
`aʷ mod P ≡ bʷ mod P` اگر اور صرف اگر `a mod P ≡ b mod P`
+ +اس طرح، یہ دیکھتے ہوئے کہ `P` پرائم ہے اور `w` نسبتاً `P-1` کے پرائم ہے، ہمارے پاس یہ ہے کہ `|{pow(x, w, P) : x ∈ ℤ}| = P`، جس کا مطلب ہے کہ ہیشنگ فنکشن میں تصادم کی کم سے کم ممکنہ شرح ہے۔ + +خاص صورت میں کہ `P` ایک سیف پرائم ہے جیسا کہ ہم نے منتخب کیا ہے، تب `P-1` کے صرف عوامل 1، 2، `(P-1)/2` اور `P-1` ہیں۔ چونکہ `P` > 7، ہم جانتے ہیں کہ 3 نسبتاً `P-1` کے پرائم ہے، لہذا `w=3` مذکورہ بالا تجویز کو پورا کرتا ہے۔ + +## زیادہ موثر کیشے پر مبنی تشخیصی الگورتھم {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..bd5a268ae70 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1019 @@ +--- +title: Ethash +description: "ایتھ ہیش الگورتھم پر ایک تفصیلی نظر۔" +lang: ur-in +--- + + + + + + Ethash ایتھیریم کا پروف آف ورک مائننگ الگورتھم تھا۔ پروف آف ورک کو اب **مکمل طور پر بند** کر دیا گیا ہے اور ایتھیریم کو اب اس کے بجائے [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) کا استعمال کرکے محفوظ کیا گیا ہے۔ [دی مرج](/roadmap/merge/)، [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) اور [اسٹیکنگ](/staking/) کے بارے میں مزید پڑھیں۔ یہ صفحہ تاریخی دلچسپی کے لیے ہے! + + + + +ایتھ ہیش [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) الگورتھم کا ایک ترمیم شدہ ورژن ہے۔ ایتھ ہیش پروف-آف-ورک [میموری ہارڈ](https://wikipedia.org/wiki/Memory-hard_function) ہے، جس کے بارے میں سوچا گیا تھا کہ یہ الگورتھم کو ASIC مزاحم بناتا ہے۔ ایتھ ہیش ASICs آخرکار تیار ہو گئے تھے لیکن GPU مائننگ اس وقت تک ایک قابل عمل آپشن تھا جب تک کہ پروف-آف-ورک کو بند نہیں کر دیا گیا۔ ایتھ ہیش اب بھی دیگر غیر-ایتھیریم پروف-آف-ورک نیٹ ورکس پر دوسرے کوائنز کو مائن کرنے کے لئے استعمال کیا جاتا ہے۔ + +## ایتھ ہیش کیسے کام کرتا ہے؟ {#how-does-ethash-work} + +میموری ہارڈنس ایک پروف آف ورک الگورتھم کے ساتھ حاصل کی جاتی ہے جس کے لئے نانس اور بلاک ہیڈر پر منحصر ایک مقررہ وسیلہ کے سب سیٹ کو منتخب کرنے کی ضرورت ہوتی ہے۔ اس وسیلہ (کچھ گیگا بائٹس سائز میں) کو DAG کہا جاتا ہے۔ DAG ہر 30000 بلاکس پر تبدیل ہوتا ہے، ایک ~125 گھنٹے کی ونڈو جسے ایپوک کہا جاتا ہے (تقریباً 5.2 دن) اور اسے جنریٹ ہونے میں کچھ وقت لگتا ہے۔ چونکہ DAG صرف بلاک کی اونچائی پر منحصر ہے، اسے پہلے سے جنریٹ کیا جا سکتا ہے، لیکن اگر ایسا نہیں ہے تو کلائنٹ کو بلاک بنانے کے لئے اس عمل کے اختتام تک انتظار کرنے کی ضرورت ہے۔ اگر کلائنٹس وقت سے پہلے DAGs کو پہلے سے جنریٹ اور کیش نہیں کرتے ہیں تو نیٹ ورک کو ہر ایپوک کی منتقلی پر بڑے پیمانے پر بلاک میں تاخیر کا سامنا کرنا پڑ سکتا ہے۔ نوٹ کریں کہ پروف-آف-ورک کی تصدیق کے لئے DAG کو جنریٹ کرنے کی ضرورت نہیں ہے جو بنیادی طور پر کم CPU اور چھوٹی میموری دونوں کے ساتھ تصدیق کی اجازت دیتا ہے۔ + +الگورتھم جو عمومی راستہ اختیار کرتا ہے وہ حسب ذیل ہے: + +1. ایک **سیڈ** موجود ہے جسے اس وقت تک بلاک ہیڈرز کو اسکین کرکے ہر بلاک کے لئے شمار کیا جاسکتا ہے۔ +2. سیڈ سے، کوئی **16 MB کا سیوڈو رینڈم کیش** شمار کر سکتا ہے۔ لائٹ کلائنٹس کیش کو اسٹور کرتے ہیں۔ +3. کیش سے، ہم ایک **1 GB ڈیٹاسیٹ** جنریٹ کر سکتے ہیں، اس خصوصیت کے ساتھ کہ ڈیٹاسیٹ میں ہر آئٹم کیش سے صرف چند آئٹمز پر منحصر ہے۔ فل کلائنٹس اور مائنرز ڈیٹاسیٹ کو اسٹور کرتے ہیں۔ ڈیٹاسیٹ وقت کے ساتھ خطی طور پر بڑھتا ہے۔ +4. مائننگ میں ڈیٹاسیٹ کے بے ترتیب سلائسز کو پکڑنا اور انہیں ایک ساتھ ہیش کرنا شامل ہے۔ کیش کا استعمال کرکے کم میموری کے ساتھ تصدیق کی جا سکتی ہے تاکہ ڈیٹاسیٹ کے ان مخصوص ٹکڑوں کو دوبارہ جنریٹ کیا جا سکے جن کی آپ کو ضرورت ہے، لہذا آپ کو صرف کیش کو اسٹور کرنے کی ضرورت ہے۔ + +بڑا ڈیٹاسیٹ ہر 30000 بلاکس میں ایک بار اپ ڈیٹ ہوتا ہے، لہذا ایک مائنر کی زیادہ تر کوشش ڈیٹاسیٹ کو پڑھنے کی ہوگی، نہ کہ اس میں تبدیلیاں کرنے کی۔ + +## تعریفیں {#definitions} + +ہم مندرجہ ذیل تعریفیں استعمال کرتے ہیں: + +``` +WORD_BYTES = 4 # لفظ میں بائٹس +DATASET_BYTES_INIT = 2**30 # جینیسس پر ڈیٹاسیٹ میں بائٹس +DATASET_BYTES_GROWTH = 2**23 # فی ایپوک ڈیٹاسیٹ کی بڑھوتری +CACHE_BYTES_INIT = 2**24 # جینیسس پر کیش میں بائٹس +CACHE_BYTES_GROWTH = 2**17 # فی ایپوک کیش کی بڑھوتری +CACHE_MULTIPLIER=1024 # کیش کے مقابلے میں DAG کا سائز +EPOCH_LENGTH = 30000 # فی ایپوک بلاکس +MIX_BYTES = 128 # مکس کی چوڑائی +HASH_BYTES = 64 # بائٹس میں ہیش کی لمبائی +DATASET_PARENTS = 256 # ہر ڈیٹاسیٹ عنصر کے پیرنٹس کی تعداد +CACHE_ROUNDS = 3 # کیش پروڈکشن میں راؤنڈز کی تعداد +ACCESSES = 64 # ہاشیموٹو لوپ میں رسائیوں کی تعداد +``` + +### 'SHA3' کا استعمال {#sha3} + +ایتھیریم کی ڈیولپمنٹ SHA3 اسٹینڈرڈ کی ڈیولپمنٹ کے ساتھ موافق تھی، اور اسٹینڈرڈز کے عمل نے حتمی ہیش الگورتھم کی پیڈنگ میں دیر سے تبدیلی کی، تاکہ ایتھیریم کے "sha3_256" اور "sha3_512" ہیشز معیاری sha3 ہیشز نہیں ہیں، بلکہ ایک متغیر ہیں جسے اکثر دوسرے سیاق و سباق میں "Keccak-256" اور "Keccak-512" کہا جاتا ہے۔ بحث دیکھیں، مثال کے طور پر، [یہاں](https://eips.ethereum.org/EIPS/eip-1803)، [یہاں](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)، یا [یہاں](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)۔ + +براہ کرم اس بات کو ذہن میں رکھیں کیونکہ ذیل میں الگورتھم کی تفصیل میں "sha3" ہیشز کا حوالہ دیا گیا ہے۔ + +## پیرامیٹرز {#parameters} + +ایتھ ہیش کے کیش اور ڈیٹاسیٹ کے پیرامیٹرز بلاک نمبر پر منحصر ہیں۔ کیش کا سائز اور ڈیٹاسیٹ کا سائز دونوں خطی طور پر بڑھتے ہیں؛ تاہم، ہم ہمیشہ خطی طور پر بڑھتی ہوئی حد سے نیچے سب سے زیادہ پرائم لیتے ہیں تاکہ چکری رویے کی طرف لے جانے والی حادثاتی باقاعدگیوں کے خطرے کو کم کیا جا سکے۔ + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +ڈیٹاسیٹ اور کیش سائز کی قدروں کی جدولیں ضمیمہ میں فراہم کی گئی ہیں۔ + +## کیش جنریشن {#cache-generation} + +اب، ہم کیش تیار کرنے کے لئے فنکشن کی وضاحت کرتے ہیں: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # ترتیب وار ابتدائی ڈیٹاسیٹ تیار کریں + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # randmemohash کا کم راؤنڈ والا ورژن استعمال کریں + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +کیش پروڈکشن کے عمل میں پہلے ترتیب وار 32 MB میموری کو بھرنا شامل ہے، پھر سرجیو ڈیمین لرنر کے [_اسٹرکٹ میموری ہارڈ ہیشنگ فنکشنز_ (2014)](http://www.hashcash.org/papers/memohash.pdf) سے _RandMemoHash_ الگورتھم کے دو پاسز انجام دینا شامل ہے۔ آؤٹ پٹ 524288 64-بائٹ قدروں کا ایک سیٹ ہے۔ + +## ڈیٹا ایگریگیشن فنکشن {#date-aggregation-function} + +ہم کچھ معاملات میں XOR کے غیر-ایسوسی ایٹیو متبادل کے طور پر [FNV ہیش](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) سے متاثر ایک الگورتھم استعمال کرتے ہیں۔ نوٹ کریں کہ ہم پرائم کو پورے 32-بٹ ان پٹ سے ضرب دیتے ہیں، FNV-1 اسپیک کے برعکس جو پرائم کو باری باری ایک بائٹ (آکٹیٹ) سے ضرب دیتا ہے۔ + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +براہ کرم نوٹ کریں، یہاں تک کہ یلو پیپر بھی fnv کو v1\*(FNV_PRIME ^ v2) کے طور پر بیان کرتا ہے، تمام موجودہ نفاذات مستقل طور پر اوپر دی گئی تعریف کا استعمال کرتے ہیں۔ + +## مکمل ڈیٹاسیٹ کا حساب {#full-dataset-calculation} + +مکمل 1 GB ڈیٹاسیٹ میں ہر 64 بائٹ کا آئٹم اس طرح شمار کیا جاتا ہے: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # مکس کو شروع کریں + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # اسے i پر مبنی بہت سے بے ترتیب کیش نوڈز کے ساتھ fnv کریں + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +بنیادی طور پر، ہم 256 سیوڈو رینڈملی منتخب کیش نوڈز سے ڈیٹا کو یکجا کرتے ہیں، اور اسے ڈیٹاسیٹ نوڈ کا حساب لگانے کے لئے ہیش کرتے ہیں۔ پھر پورا ڈیٹاسیٹ اس کے ذریعہ تیار کیا جاتا ہے: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## مین لوپ {#main-loop} + +اب، ہم مرکزی "ہاشیموٹو" جیسے لوپ کی وضاحت کرتے ہیں، جہاں ہم ایک خاص ہیڈر اور نانس کے لئے اپنی حتمی قدر پیدا کرنے کے لئے مکمل ڈیٹاسیٹ سے ڈیٹا جمع کرتے ہیں۔ نیچے دیے گئے کوڈ میں، `header` ایک _چھوٹے_ بلاک ہیڈر کی RLP نمائندگی کے SHA3-256 _ہیش_ کی نمائندگی کرتا ہے، یعنی، ایک ہیڈر جس میں **mixHash** اور **nonce** کے فیلڈز شامل نہیں ہیں۔ `nonce` ایک 64 بٹ غیر سائن شدہ انٹیجر کے آٹھ بائٹس ہیں جو بگ-اینڈین ترتیب میں ہیں۔ لہذا `nonce[::-1]` اس قدر کی آٹھ بائٹ کی لٹل-اینڈین نمائندگی ہے: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # 64 بائٹ سیڈ میں ہیڈر+نانس کو یکجا کریں + s = sha3_512(header + nonce[::-1]) + # نقل شدہ s کے ساتھ مکس شروع کریں + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # بے ترتیب ڈیٹاسیٹ نوڈز میں مکس کریں + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # مکس کو کمپریس کریں + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +بنیادی طور پر، ہم 128 بائٹس چوڑا ایک "مکس" برقرار رکھتے ہیں، اور بار بار ترتیب وار مکمل ڈیٹاسیٹ سے 128 بائٹس حاصل کرتے ہیں اور اسے مکس کے ساتھ یکجا کرنے کے لئے `fnv` فنکشن کا استعمال کرتے ہیں۔ ترتیب وار رسائی کے 128 بائٹس استعمال کیے جاتے ہیں تاکہ الگورتھم کا ہر راؤنڈ ہمیشہ RAM سے ایک پورا صفحہ حاصل کرے، ٹرانسلیشن لوک اسائیڈ بفر مسز کو کم سے کم کرتا ہے جس سے ASICs نظریاتی طور پر بچنے کے قابل ہوں گے۔ + +اگر اس الگورتھم کا آؤٹ پٹ مطلوبہ ہدف سے کم ہے، تو نانس درست ہے۔ نوٹ کریں کہ آخر میں `sha3_256` کا اضافی اطلاق اس بات کو یقینی بناتا ہے کہ ایک درمیانی نانس موجود ہے جسے یہ ثابت کرنے کے لئے فراہم کیا جا سکتا ہے کہ کم از کم تھوڑا سا کام کیا گیا تھا؛ اس فوری بیرونی PoW تصدیق کو اینٹی-DDoS مقاصد کے لئے استعمال کیا جا سکتا ہے۔ یہ اس بات کی شماریاتی یقین دہانی فراہم کرنے کا بھی کام کرتا ہے کہ نتیجہ ایک غیر جانبدار، 256 بٹ نمبر ہے۔ + +## مائننگ {#mining} + +مائننگ الگورتھم کی تعریف اس طرح کی گئی ہے: + +```python +def mine(full_size, dataset, header, difficulty): + # ہیش کے ساتھ اسی ہندسے پر موازنہ کرنے کے لئے ہدف کو صفر-پیڈ کریں + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## سیڈ ہیش کی تعریف کرنا {#seed-hash} + +کسی دیے گئے بلاک کے اوپر مائن کرنے کے لئے استعمال ہونے والے سیڈ ہیش کا حساب لگانے کے لئے، ہم مندرجہ ذیل الگورتھم کا استعمال کرتے ہیں: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +نوٹ کریں کہ ہموار مائننگ اور تصدیق کے لئے، ہم مستقبل کے سیڈ ہیشز اور ڈیٹاسیٹس کو ایک الگ تھریڈ میں پہلے سے شمار کرنے کی تجویز دیتے ہیں۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## ضمیمہ {#appendix} + +اگر آپ اوپر دیے گئے پائتھن اسپیک کو کوڈ کے طور پر چلانے میں دلچسپی رکھتے ہیں تو مندرجہ ذیل کوڈ کو پہلے شامل کیا جانا چاہئے۔ + +```python +import sha3, copy + +# لٹل اینڈین بٹ آرڈرنگ فرض کرتا ہے (انٹیل آرکیٹیکچرز کی طرح) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# sha3 ہیش فنکشن، 64 بائٹس آؤٹ پٹ کرتا ہے +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### ڈیٹا سائزز {#data-sizes} + +مندرجہ ذیل لک اپ ٹیبلز ڈیٹا سائزز اور کیش سائزز کے تقریباً 2048 ٹیبولیٹڈ ایپوکس فراہم کرتی ہیں۔ + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 26777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..b27918625bb --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "مائننگ الگورتھم" +description: "Ethereum مائننگ کے لیے استعمال ہونے والے الگورتھم پر ایک تفصیلی نظر۔" +lang: ur-in +--- + + + + + +کام کا ثبوت اب ایتھریم کے اتفاق رائے کے طریقہ کار کی بنیاد نہیں ہے، جس کا مطلب ہے کہ کان کنی کو بند کر دیا گیا ہے۔ اس کے بجائے، ایتھریم کو توثیق کنندگان کے ذریعے محفوظ کیا جاتا ہے جو ETH کو اسٹیک کرتے ہیں۔ آپ آج ہی اپنے ETH کو اسٹیک کرنا شروع کر سکتے ہیں۔ مرج، حصص کے ثبوت، اور اسٹیکنگ پر مزید پڑھیں۔ یہ صفحہ صرف تاریخی دلچسپی کے لیے ہے۔ + + + + +Ethereum مائننگ میں Ethash نامی ایک الگورتھم کا استعمال کیا گیا تھا۔ اس الگورتھم کا بنیادی خیال یہ ہے کہ ایک مائنر بروٹ فورس کمپیوٹیشن کا استعمال کرتے ہوئے ایک نانس ان پٹ تلاش کرنے کی کوشش کرتا ہے تاکہ نتیجہ خیز ہیش حسابی مشکل سے طے شدہ حد سے چھوٹا ہو۔ اس مشکل کی سطح کو متحرک طور پر ایڈجسٹ کیا جا سکتا ہے، جس سے بلاک کی پیداوار ایک باقاعدہ وقفے پر ہو سکتی ہے۔ + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [پروف-آف-ورک اتفاق رائے](/developers/docs/consensus-mechanisms/pow) اور [مائننگ](/developers/docs/consensus-mechanisms/pow/mining) کے بارے میں پڑھیں۔ + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto Ethereum مائننگ کے لیے ایک پیشرو تحقیقی الگورتھم تھا جسے Ethash نے پیچھے چھوڑ دیا۔ یہ دو مختلف الگورتھم کا امتزاج تھا: Dagger اور Hashimoto۔ یہ صرف ایک تحقیقی نفاذ تھا اور Ethereum Mainnet کے لانچ ہونے تک اسے Ethash نے پیچھے چھوڑ دیا تھا۔ + +[Dagger](http://www.hashcash.org/papers/dagger.html) میں ایک [ڈائریکٹڈ ایسائکلک گراف](https://en.wikipedia.org/wiki/Directed_acyclic_graph) کی تخلیق شامل ہے، جس کے بے ترتیب سلائسز کو ایک ساتھ ہیش کیا جاتا ہے۔ بنیادی اصول یہ ہے کہ ہر نانس کو ایک بڑے کل ڈیٹا ٹری کے صرف ایک چھوٹے سے حصے کی ضرورت ہوتی ہے۔ ہر نانس کے لیے سب ٹری کو دوبارہ کمپیوٹ کرنا مائننگ کے لیے ممنوع ہے - اس لیے ٹری کو اسٹور کرنے کی ضرورت ہے - لیکن ایک نانس کی تصدیق کے لیے یہ ٹھیک ہے۔ Dagger کو Scrypt جیسے موجودہ الگورتھم کے متبادل کے طور پر ڈیزائن کیا گیا تھا، جو میموری-ہارڈ ہیں لیکن جب ان کی میموری-ہارڈنیس واقعی محفوظ سطح تک بڑھ جاتی ہے تو ان کی تصدیق کرنا مشکل ہو جاتا ہے۔ تاہم، Dagger مشترکہ میموری ہارڈویئر ایکسلریشن کے لیے کمزور تھا اور تحقیق کے دیگر راستوں کے حق میں اسے چھوڑ دیا گیا۔ + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) ایک الگورتھم ہے جو I/O باؤنڈ ہو کر ASIC-مزاحمت میں اضافہ کرتا ہے (یعنی، میموری ریڈز مائننگ کے عمل میں محدود عنصر ہیں)۔ نظریہ یہ ہے کہ RAM کمپیوٹیشن سے زیادہ دستیاب ہے؛ اربوں ڈالر کی تحقیق نے پہلے ہی مختلف استعمال کے معاملات کے لیے RAM کو بہتر بنانے کی تحقیقات کی ہیں، جن میں اکثر قریب-بے ترتیب رسائی کے پیٹرن شامل ہوتے ہیں (اسی لیے "رینڈم ایکسیس میموری")۔ نتیجے کے طور پر، موجودہ RAM الگورتھم کا جائزہ لینے کے لیے معتدل طور پر بہترین کے قریب ہونے کا امکان ہے۔ Hashimoto بلاک چین کو ڈیٹا کے ذریعہ کے طور پر استعمال کرتا ہے، بیک وقت اوپر (1) اور (3) کو پورا کرتا ہے۔ + +Dagger-Hashimoto نے Dagger اور Hashimoto الگورتھم کے ترمیم شدہ ورژن استعمال کیے۔ Dagger Hashimoto اور Hashimoto کے درمیان فرق یہ ہے کہ بلاک چین کو ڈیٹا کے ذریعہ کے طور پر استعمال کرنے کے بجائے، Dagger Hashimoto ایک حسب ضرورت تیار کردہ ڈیٹا سیٹ استعمال کرتا ہے، جو ہر N بلاکس پر بلاک ڈیٹا کی بنیاد پر اپ ڈیٹ ہوتا ہے۔ ڈیٹا سیٹ Dagger الگورتھم کا استعمال کرتے ہوئے تیار کیا جاتا ہے، جو لائٹ کلائنٹ تصدیقی الگورتھم کے لیے ہر نانس کے لیے مخصوص سب سیٹ کا موثر طریقے سے حساب لگانے کی اجازت دیتا ہے۔ Dagger Hashimoto اور Dagger کے درمیان فرق یہ ہے کہ، اصل Dagger کے برعکس، بلاک کو استفسار کرنے کے لیے استعمال ہونے والا ڈیٹا سیٹ نیم مستقل ہوتا ہے، جو صرف کبھی کبھار وقفوں پر اپ ڈیٹ ہوتا ہے (مثلاً، ہفتے میں ایک بار)۔ اس کا مطلب یہ ہے کہ ڈیٹاسیٹ بنانے کی کوشش کا حصہ صفر کے قریب ہے، اس لیے مشترکہ میموری کی رفتار بڑھانے کے بارے میں سرجیو لرنر کے دلائل نہ ہونے کے برابر ہو جاتے ہیں۔ + +[Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) پر مزید۔ + +## Ethash {#ethash} + +Ethash وہ مائننگ الگورتھم تھا جو اصل میں Ethereum Mainnet پر اب متروک پروف-آف-ورک آرکیٹیکچر کے تحت استعمال کیا گیا تھا۔ Ethash مؤثر طریقے سے Dagger-Hashimoto کے ایک مخصوص ورژن کو دیا گیا ایک نیا نام تھا جب الگورتھم کو نمایاں طور پر اپ ڈیٹ کیا گیا، جبکہ اب بھی اپنے پیشرو کے بنیادی اصولوں کو وراثت میں مل رہا تھا۔ Ethereum Mainnet نے ہمیشہ صرف Ethash کا استعمال کیا - Dagger Hashimoto مائننگ الگورتھم کا ایک R&D ورژن تھا جسے Ethereum Mainnet پر مائننگ شروع ہونے سے پہلے ہی پیچھے چھوڑ دیا گیا تھا۔ + +[Ethash پر مزید](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash)۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/dapps/index.md b/public/content/translations/ur/developers/docs/dapps/index.md new file mode 100644 index 00000000000..bdf0941cb59 --- /dev/null +++ b/public/content/translations/ur/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "Dapps کا تکنیکی تعارف" +description: +lang: ur-in +--- + +ایک وکندریقرت ایپلیکیشن (dapp) ایک وکندریقرت نیٹ ورک پر بنائی گئی ایک ایپلیکیشن ہے جو ایک [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) اور ایک فرنٹ اینڈ یوزر انٹرفیس کو یکجا کرتی ہے۔ Ethereum پر، اسمارٹ کنٹریکٹس قابل رسائی اور شفاف ہیں – کھلے APIs کی طرح – لہذا آپ کی dapp میں کسی اور کا لکھا ہوا اسمارٹ کنٹریکٹ بھی شامل ہو سکتا ہے۔ + +## شرائط {#prerequisites} + +dapps کے بارے میں جاننے سے پہلے، آپ کو [بلاک چین کی بنیادی باتوں](/developers/docs/intro-to-ethereum/) کا احاطہ کرنا چاہئے اور Ethereum نیٹ ورک اور یہ کیسے وکندریقرت ہے اس کے بارے میں پڑھنا چاہئے۔ + +## ایک dapp کی تعریف {#definition-of-a-dapp} + +ایک dapp کا بیک اینڈ کوڈ ایک وکندریقرت پیئر-ٹو-پیئر نیٹ ورک پر چلتا ہے۔ اس کا موازنہ ایک ایسی ایپ سے کریں جہاں بیک اینڈ کوڈ مرکزی سرورز پر چل رہا ہو۔ + +ایک dapp میں کسی بھی زبان میں لکھا فرنٹ اینڈ کوڈ اور یوزر انٹرفیس ہو سکتے ہیں (بالکل ایک ایپ کی طرح) تاکہ اس کے بیک اینڈ پر کال کی جا سکے۔ مزید یہ کہ، اس کے فرنٹ اینڈ کو [IPFS](https://ipfs.io/) جیسے وکندریقرت اسٹوریج پر ہوسٹ کیا جا سکتا ہے۔ + +- **وکندریقرت** - dapps، Ethereum پر کام کرتی ہیں، ایک کھلا عوامی وکندریقرت پلیٹ فارم جہاں کسی ایک شخص یا گروہ کا کنٹرول نہیں ہوتا +- **ڈیٹرمنسٹک** - dapps اس ماحول سے قطع نظر ایک ہی فنکشن انجام دیتی ہیں جس میں انہیں عمل میں لایا جاتا ہے +- **ٹیورنگ کمپلیٹ** - dapps مطلوبہ وسائل دیے جانے پر کوئی بھی کارروائی انجام دے سکتی ہیں +- **الگ تھلگ** - dapps کو ایک ورچوئل ماحول میں عمل میں لایا جاتا ہے جسے Ethereum ورچوئل مشین کہا جاتا ہے تاکہ اگر اسمارٹ کنٹریکٹ میں کوئی بگ ہو تو یہ بلاک چین نیٹ ورک کے معمول کے کام میں رکاوٹ نہ ڈالے + +### اسمارٹ کنٹریکٹس پر {#on-smart-contracts} + +dapps کا تعارف کرانے کے لیے، ہمیں اسمارٹ کنٹریکٹس کا تعارف کرانے کی ضرورت ہے – بہتر اصطلاح کی کمی کی وجہ سے ایک dapp کا بیک اینڈ۔ تفصیلی جائزہ کے لیے، [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) پر ہمارے سیکشن پر جائیں۔ + +ایک اسمارٹ کنٹریکٹ کوڈ ہے جو Ethereum بلاک چین پر رہتا ہے اور بالکل اسی طرح چلتا ہے جیسا کہ پروگرام کیا گیا ہے۔ ایک بار جب اسمارٹ کنٹریکٹس نیٹ ورک پر تعینات ہو جاتے ہیں تو آپ انہیں تبدیل نہیں کر سکتے۔ Dapps کو وکندریقرت کیا جا سکتا ہے کیونکہ وہ کسی فرد یا کمپنی کے بجائے کنٹریکٹ میں لکھی گئی منطق کے ذریعے کنٹرول ہوتے ہیں۔ اس کا یہ بھی مطلب ہے کہ آپ کو اپنے کنٹریکٹس کو بہت احتیاط سے ڈیزائن کرنے اور انہیں اچھی طرح سے ٹیسٹ کرنے کی ضرورت ہے۔ + +## dapp ڈیولپمنٹ کے فوائد {#benefits-of-dapp-development} + +- **زیرو ڈاؤن ٹائم** – ایک بار جب اسمارٹ کنٹریکٹ بلاک چین پر تعینات ہو جاتا ہے، تو نیٹ ورک بحیثیت مجموعی ہمیشہ ان کلائنٹس کی خدمت کرنے کے قابل ہوگا جو کنٹریکٹ کے ساتھ تعامل کرنا چاہتے ہیں۔ لہذا، بدنیتی پر مبنی اداکار انفرادی dapps کو نشانہ بناتے ہوئے سروس سے انکار (denial-of-service) حملے شروع نہیں کر سکتے ہیں۔ +- **رازداری** – آپ کو ایک dapp کو تعینات کرنے یا اس کے ساتھ تعامل کرنے کے لیے حقیقی دنیا کی شناخت فراہم کرنے کی ضرورت نہیں ہے۔ +- **سنسرشپ کے خلاف مزاحمت** – نیٹ ورک پر کوئی بھی واحد ادارہ صارفین کو ٹرانزیکشنز جمع کرنے، dapps تعینات کرنے، یا بلاک چین سے ڈیٹا پڑھنے سے نہیں روک سکتا۔ +- **ڈیٹا کی مکمل سالمیت** – بلاک چین پر ذخیرہ شدہ ڈیٹا کرپٹوگرافک پریمیٹیوز کی بدولت ناقابل تغیر اور ناقابل تردید ہے۔ بدنیتی پر مبنی اداکار ان ٹرانزیکشنز یا دیگر ڈیٹا کو جعلی نہیں بنا سکتے جو پہلے ہی عوامی کر دیا گیا ہو۔ +- **بے اعتماد شمار/قابل تصدیق رویہ** – اسمارٹ کنٹریکٹس کا تجزیہ کیا جا سکتا ہے اور ان کی پیش قیاسی طریقوں سے عمل درآمد کی ضمانت دی جاتی ہے، بغیر کسی مرکزی اتھارٹی پر بھروسہ کرنے کی ضرورت کے۔ روایتی ماڈلز میں یہ سچ نہیں ہے؛ مثال کے طور پر، جب ہم آن لائن بینکنگ سسٹم استعمال کرتے ہیں، تو ہمیں یہ بھروسہ کرنا پڑتا ہے کہ مالیاتی ادارے ہمارے مالیاتی ڈیٹا کا غلط استعمال نہیں کریں گے، ریکارڈز میں چھیڑ چھاڑ نہیں کریں گے، یا ہیک نہیں ہوں گے۔ + +## dapp ڈیولپمنٹ کے نقصانات {#drawbacks-of-dapp-development} + +- **دیکھ بھال** – Dapps کی دیکھ بھال کرنا مشکل ہو سکتا ہے کیونکہ بلاک چین پر شائع کردہ کوڈ اور ڈیٹا میں ترمیم کرنا مشکل ہوتا ہے۔ ڈیولپرز کے لیے ایک بار تعینات ہونے کے بعد اپنی dapps (یا ایک dapp کے ذریعے ذخیرہ کردہ بنیادی ڈیٹا) میں اپ ڈیٹس کرنا مشکل ہوتا ہے، چاہے پرانے ورژن میں بگز یا سیکیورٹی خطرات کی نشاندہی ہی کیوں نہ کی گئی ہو۔ +- **کارکردگی کا اوورہیڈ** – کارکردگی کا ایک بہت بڑا اوورہیڈ ہے، اور اسکیلنگ واقعی مشکل ہے۔ سیکیورٹی، سالمیت، شفافیت، اور بھروسے کی وہ سطح حاصل کرنے کے لیے جس کی Ethereum خواہش کرتا ہے، ہر نوڈ ہر ٹرانزیکشن کو چلاتا اور ذخیرہ کرتا ہے۔ اس کے علاوہ، پروف-آف-اسٹیک اتفاق رائے میں بھی وقت لگتا ہے۔ +- **نیٹ ورک کی بھیڑ** – جب ایک dapp بہت زیادہ حسابی وسائل استعمال کرتی ہے، تو پورا نیٹ ورک بیک اپ ہو جاتا ہے۔ فی الحال، نیٹ ورک فی سیکنڈ صرف 10-15 ٹرانزیکشنز پر کارروائی کر سکتا ہے؛ اگر ٹرانزیکشنز اس سے زیادہ تیزی سے بھیجی جا رہی ہیں، تو غیر تصدیق شدہ ٹرانزیکشنز کا پول تیزی سے بڑھ سکتا ہے۔ +- **صارف کا تجربہ** – صارف دوست تجربات کو انجینئر کرنا زیادہ مشکل ہو سکتا ہے کیونکہ اوسط آخری صارف کو بلاک چین کے ساتھ واقعی محفوظ طریقے سے تعامل کرنے کے لیے ضروری ٹول اسٹیک قائم کرنا بہت مشکل لگ سکتا ہے۔ +- **مرکزیت** – صارف دوست اور ڈیولپر دوست حل جو Ethereum کی بنیادی تہہ کے اوپر بنائے گئے ہیں وہ بالآخر مرکزی خدمات کی طرح ہی نظر آ سکتے ہیں۔ مثال کے طور پر، ایسی خدمات سرور سائیڈ پر کیز یا دیگر حساس معلومات کو ذخیرہ کر سکتی ہیں، ایک مرکزی سرور کا استعمال کرتے ہوئے ایک فرنٹ اینڈ پیش کر سکتی ہیں، یا بلاک چین پر لکھنے سے پہلے ایک مرکزی سرور پر اہم کاروباری منطق چلا سکتی ہیں۔ مرکزیت بلاک چین کے روایتی ماڈل پر حاصل بہت سے (اگر تمام نہیں تو) فوائد کو ختم کر دیتی ہے۔ + +## کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + + + +## dapps بنانے کے لیے ٹولز {#dapp-tools} + +**Scaffold-ETH _- ایک ایسے فرنٹ اینڈ کا استعمال کرتے ہوئے Solidity کے ساتھ تیزی سے تجربہ کریں جو آپ کے اسمارٹ کنٹریکٹ کے مطابق ہو۔_** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [مثالی dapp](https://punkwallet.io/) + +**Create Eth App _- ایک کمانڈ سے Ethereum سے چلنے والی ایپس بنائیں۔_** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- ایک [ABI](/glossary/#abi) سے dapp فرنٹ اینڈ بنانے کے لیے FOSS ٹول۔_** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _- Ethereum ڈیولپرز کے لیے اپنے نوڈ کو ٹیسٹ کرنے، اور براؤزر سے RPC کالز کمپوز اور ڈیبگ کرنے کے لیے FOSS ٹول۔_** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- ہر زبان میں SDKs، اسمارٹ کنٹریکٹس، ٹولز، اور web3 ڈیولپمنٹ کے لیے انفراسٹرکچر۔_** + +- [ہوم پیج](https://thirdweb.com/) +- [ڈاکومینٹیشن](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- اسمارٹ کنٹریکٹس تعینات کرنے، کریڈٹ کارڈ اور کراس چین ادائیگیوں کو فعال کرنے، اور NFTs بنانے، تقسیم کرنے، بیچنے، ذخیرہ کرنے، اور ترمیم کرنے کے لیے APIs استعمال کرنے کے لیے انٹرپرائز-گریڈ web3 ڈیولپمنٹ پلیٹ فارم۔_** + +- [crossmint.com](https://www.crossmint.com) +- [ڈاکومینٹیشن](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## مزید پڑھیں {#further-reading} + +- [dapps کو دریافت کریں](/apps) +- [The Architecture of a Web 3.0 application](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [وکندریقرت ایپلیکیشنز کے لیے 2021 کی گائیڈ](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [وکندریقرت ایپس کیا ہیں؟](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [مشہور dapps](https://www.alchemy.com/dapps) - _Alchemy_ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [Ethereum اسٹیک کا تعارف](/developers/docs/ethereum-stack/) +- [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) diff --git a/public/content/translations/ur/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/ur/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..90cbc4c5421 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "بلاک ایکسپلوررز" +description: "بلاک ایکسپلوررز کا تعارف، بلاک چین ڈیٹا کی دنیا میں آپ کا پورٹل، جہاں آپ ٹرانزیکشنز، اکاؤنٹس، کانٹریکٹس، اور مزید کے بارے میں معلومات حاصل کر سکتے ہیں۔" +lang: ur-in +sidebarDepth: 3 +--- + +بلاک ایکسپلوررز Ethereum کے ڈیٹا تک آپ کا پورٹل ہیں۔ آپ ان کا استعمال بلاکس، ٹرانزیکشنز، ویلیڈیٹرز، اکاؤنٹس، اور دیگر آن چین سرگرمیوں پر ریئل ٹائم ڈیٹا دیکھنے کے لیے کر سکتے ہیں۔ + +## شرائط {#prerequisites} + +آپ کو Ethereum کے بنیادی تصورات کو سمجھنا چاہئے تاکہ آپ اس ڈیٹا کو سمجھ سکیں جو ایک بلاک ایکسپلورر آپ کو دیتا ہے۔ [Ethereum کے تعارف](/developers/docs/intro-to-ethereum/) کے ساتھ شروع کریں۔ + +## خدمات {#services} + +- [Etherscan](https://etherscan.io/) -_چینی، کوریائی، روسی اور جاپانی زبانوں میں بھی دستیاب ہے_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_ہسپانوی، فرانسیسی، اطالوی، ڈچ، پرتگالی، روسی، چینی، اور فارسی میں بھی دستیاب ہے_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [DexGuru Block Explorer](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_چینی، ہسپانوی، فرانسیسی، ترکی، روسی، کوریائی اور ویتنامی زبانوں میں بھی دستیاب ہے_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## اوپن سورس ٹولز {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## ڈیٹا {#data} + +Ethereum ڈیزائن کے لحاظ سے شفاف ہے لہذا ہر چیز قابل تصدیق ہے۔ بلاک ایکسپلوررز اس معلومات کو حاصل کرنے کے لیے ایک انٹرفیس فراہم کرتے ہیں۔ اور یہ مرکزی Ethereum نیٹ ورک اور ٹیسٹ نیٹ دونوں کے لیے ہے، اگر آپ کو اس ڈیٹا کی ضرورت ہو۔ ڈیٹا کو ایکزیکیوشن ڈیٹا اور کنسینسس ڈیٹا میں تقسیم کیا گیا ہے۔ ایگزیکیوشن ڈیٹا سے مراد وہ ٹرانزیکشنز ہیں جو کسی مخصوص بلاک میں انجام دی گئی ہیں۔ کنسینسس ڈیٹا خود بلاکس اور ان کو تجویز کرنے والے ویلیڈیٹرز سے متعلق ہے۔ + +یہاں اس قسم کے ڈیٹا کا خلاصہ ہے جو آپ بلاک ایکسپلورر سے حاصل کر سکتے ہیں۔ + +### ایگزیکیوشن ڈیٹا {#execution-data} + +ہر 12 سیکنڈ میں Ethereum میں نئے بلاکس شامل کیے جاتے ہیں (جب تک کہ کوئی بلاک پروپوزر اپنی باری سے محروم نہ ہو جائے)، لہذا بلاک ایکسپلوررز میں ڈیٹا کا تقریبا مستقل سلسلہ شامل ہوتا رہتا ہے۔ بلاکس میں بہت سا اہم ڈیٹا ہوتا ہے جو آپ کے لیے کارآمد ہو سکتا ہے: + +**معیاری ڈیٹا** + +- بلاک کی اونچائی - موجودہ بلاک کی تخلیق پر بلاک نمبر اور بلاک چین کی لمبائی (بلاکس میں) +- ٹائم اسٹیمپ - وہ وقت جب ایک بلاک تجویز کیا گیا تھا +- ٹرانزیکشنز - بلاک کے اندر شامل ٹرانزیکشنز کی تعداد +- فیس وصول کنندہ - وہ ایڈریس جس نے ٹرانزیکشنز سے گیس فیس ٹپس وصول کیں +- بلاک کا انعام - بلاک تجویز کرنے والے ویلیڈیٹر کو دی گئی ETH کی رقم +- سائز - بلاک کے اندر ڈیٹا کا سائز (بائٹس میں ماپا جاتا ہے) +- استعمال شدہ گیس - بلاک میں ٹرانزیکشنز کے ذریعے استعمال ہونے والی گیس کی کل اکائیاں +- گیس کی حد - بلاک میں ٹرانزیکشنز کے ذریعے مقرر کردہ گیس کی کل حدیں +- فی گیس بنیادی فیس - کسی ٹرانزیکشن کو بلاک میں شامل کرنے کے لیے درکار کم از کم ملٹی پلائر +- جلائی گئی فیس - بلاک میں کتنی ETH جلائی جاتی ہے +- اضافی ڈیٹا - کوئی بھی اضافی ڈیٹا جو بلڈر نے بلاک میں شامل کیا ہے + +**ایڈوانسڈ ڈیٹا** + +- ہیش - کرپٹوگرافک ہیش جو بلاک ہیڈر کی نمائندگی کرتا ہے (بلاک کا منفرد شناخت کنندہ) +- پیرنٹ ہیش - موجودہ بلاک سے پہلے آنے والے بلاک کا ہیش +- اسٹیٹ روٹ - مرکل ٹرائی کا روٹ ہیش جو سسٹم کی پوری حالت کو اسٹور کرتا ہے + +### گیس {#gas} + +بلاک ایکسپلوررز نہ صرف آپ کو ٹرانزیکشنز اور بلاکس میں گیس کے استعمال کے بارے میں ڈیٹا دیں گے، بلکہ کچھ آپ کو نیٹ ورک کی موجودہ گیس کی قیمتوں کے بارے میں بھی معلومات دیں گے۔ اس سے آپ کو نیٹ ورک کے استعمال کو سمجھنے، محفوظ ٹرانزیکشنز جمع کرانے اور گیس پر زیادہ خرچ نہ کرنے میں مدد ملے گی۔ ایسے APIs تلاش کریں جو آپ کو یہ معلومات اپنے پروڈکٹ کے انٹرفیس میں حاصل کرنے میں مدد دے سکیں۔ گیس سے متعلق ڈیٹا میں شامل ہیں: + +- ایک محفوظ لیکن سست ٹرانزیکشن کے لیے درکار گیس کی تخمینی اکائیاں (+ تخمینی قیمت اور مدت) +- ایک اوسط ٹرانزیکشن کے لیے درکار گیس کی تخمینی اکائیاں (+ تخمینی قیمت اور مدت) +- ایک تیز ٹرانزیکشن کے لیے درکار گیس کی تخمینی اکائیاں (+ تخمینی قیمت اور مدت) +- گیس کی قیمت پر مبنی اوسط تصدیقی وقت +- وہ کانٹریکٹس جو گیس استعمال کر رہے ہیں - دوسرے الفاظ میں، مقبول پروڈکٹس جو نیٹ ورک پر بہت زیادہ استعمال ہو رہے ہیں +- وہ اکاؤنٹس جو گیس خرچ کر رہے ہیں - دوسرے الفاظ میں، نیٹ ورک کے بار بار استعمال کرنے والے + +### ٹرانزیکشنز {#transactions} + +بلاک ایکسپلوررز لوگوں کے لیے اپنے ٹرانزیکشنز کی پیشرفت کو ٹریک کرنے کے لیے ایک عام جگہ بن گئے ہیں۔ اس کی وجہ یہ ہے کہ آپ جو تفصیل حاصل کر سکتے ہیں وہ اضافی یقین دہانی فراہم کرتی ہے۔ ٹرانزیکشن ڈیٹا میں شامل ہیں: + +**معیاری ڈیٹا** + +- ٹرانزیکشن ہیش - ایک ہیش جو ٹرانزیکشن جمع کرانے پر تیار ہوتا ہے +- اسٹیٹس - اس بات کا اشارہ کہ ٹرانزیکشن زیر التوا، ناکام یا کامیاب ہے +- بلاک - وہ بلاک جس میں ٹرانزیکشن شامل کیا گیا ہے +- ٹائم اسٹیمپ - وہ وقت جب ایک ویلیڈیٹر کے ذریعہ تجویز کردہ بلاک میں ایک ٹرانزیکشن شامل کیا گیا تھا +- منجانب - ٹرانزیکشن جمع کرانے والے اکاؤنٹ کا ایڈریس +- بنام - وصول کنندہ یا اسمارٹ کانٹریکٹ کا ایڈریس جس کے ساتھ ٹرانزیکشن تعامل کرتا ہے +- منتقل شدہ ٹوکنز - ٹرانزیکشن کے حصے کے طور پر منتقل کیے گئے ٹوکنز کی فہرست +- ویلیو - منتقل کی جانے والی کل ETH ویلیو +- ٹرانزیکشن فیس - ٹرانزیکشن پر کارروائی کرنے کے لیے ویلیڈیٹر کو ادا کی گئی رقم (گیس کی قیمت\*استعمال شدہ گیس سے حساب کی جاتی ہے) + +**ایڈوانسڈ ڈیٹا** + +- گیس کی حد - گیس کی اکائیوں کی زیادہ سے زیادہ تعداد جو یہ ٹرانزیکشن استعمال کر سکتی ہے +- استعمال شدہ گیس - ٹرانزیکشن کے ذریعہ استعمال شدہ گیس کی اکائیوں کی اصل رقم +- گیس کی قیمت - فی گیس یونٹ مقرر کردہ قیمت +- نونس - `from` ایڈریس کے لیے ٹرانزیکشن نمبر (یاد رکھیں کہ یہ 0 سے شروع ہوتا ہے لہذا `100` کا نونس دراصل اس اکاؤنٹ کے ذریعہ جمع کرایا گیا 101 واں ٹرانزیکشن ہوگا) +- ان پٹ ڈیٹا - ٹرانزیکشن کے لیے درکار کوئی بھی اضافی معلومات + +### اکاؤنٹس {#accounts} + +ایک اکاؤنٹ کے بارے میں بہت سا ڈیٹا ہے جس تک آپ رسائی حاصل کر سکتے ہیں۔ یہی وجہ ہے کہ اکثر متعدد اکاؤنٹس استعمال کرنے کی سفارش کی جاتی ہے تاکہ آپ کے اثاثوں اور قدر کو آسانی سے ٹریک نہ کیا جا سکے۔ ٹرانزیکشنز اور اکاؤنٹ کی سرگرمی کو مزید نجی بنانے کے لیے کچھ حل بھی تیار کیے جا رہے ہیں۔ لیکن یہاں وہ ڈیٹا ہے جو اکاؤنٹس کے لیے دستیاب ہے: + +**صارف کے اکاؤنٹس** + +- اکاؤنٹ ایڈریس - وہ پبلک ایڈریس جسے آپ فنڈز بھیجنے کے لیے استعمال کر سکتے ہیں +- ETH بیلنس - اس اکاؤنٹ سے وابستہ ETH کی رقم +- کل ETH ویلیو - ETH کی ویلیو +- ٹوکنز - اکاؤنٹ سے وابستہ ٹوکنز اور ان کی قدر +- ٹرانزیکشن کی سرگزشت - ان تمام ٹرانزیکشنز کی ایک فہرست جہاں یہ اکاؤنٹ یا تو بھیجنے والا تھا یا وصول کنندہ + +**اسمارٹ معاہدات** + +اسمارٹ کانٹریکٹ اکاؤنٹس میں وہ تمام ڈیٹا ہوتا ہے جو صارف کے اکاؤنٹ میں ہوتا ہے، لیکن کچھ بلاک ایکسپلوررز کچھ کوڈ کی معلومات بھی دکھاتے ہیں۔ مثالوں میں شامل ہیں: + +- کانٹریکٹ بنانے والا - وہ ایڈریس جس نے کانٹریکٹ کو مین نیٹ پر تعینات کیا +- تخلیقی ٹرانزیکشن - وہ ٹرانزیکشن جس میں مین نیٹ پر تعیناتی شامل تھی +- سورس کوڈ - اسمارٹ کانٹریکٹ کا Solidity یا Vyper کوڈ +- کانٹریکٹ ABI - کانٹریکٹ کا ایپلیکیشن بائنری انٹرفیس — وہ کالز جو کانٹریکٹ کرتا ہے اور موصول شدہ ڈیٹا +- کانٹریکٹ تخلیق کوڈ - اسمارٹ کانٹریکٹ کا کمپائلڈ بائٹ کوڈ — جب آپ Solidity یا Vyper وغیرہ میں لکھے گئے اسمارٹ کانٹریکٹ کو کمپائل کرتے ہیں تو بنایا جاتا ہے۔ +- کانٹریکٹ ایونٹس - اسمارٹ کانٹریکٹ میں کال کیے گئے طریقوں کی سرگزشت — بنیادی طور پر یہ دیکھنے کا ایک طریقہ کہ کانٹریکٹ کا استعمال کیسے کیا جا رہا ہے اور کتنی بار + +### ٹوکنز {#tokens} + +ٹوکنز ایک قسم کا کانٹریکٹ ہیں لہذا ان کے پاس اسمارٹ کانٹریکٹ جیسا ہی ڈیٹا ہوگا۔ لیکن چونکہ ان کی قدر ہوتی ہے اور ان کی تجارت کی جا سکتی ہے اس لیے ان کے پاس اضافی ڈیٹا پوائنٹس ہوتے ہیں: + +- قسم - چاہے وہ ERC-20، ERC-721 یا کوئی اور ٹوکن معیار ہوں +- قیمت - اگر وہ ERC-20 ہیں تو ان کی موجودہ مارکیٹ ویلیو ہوگی +- مارکیٹ کیپ - اگر وہ ERC-20 ہیں تو ان کا مارکیٹ کیپ ہوگا (قیمت\*کل سپلائی سے حساب کیا جاتا ہے) +- کل سپلائی - گردش میں موجود ٹوکنز کی تعداد +- ہولڈرز - ٹوکن رکھنے والے ایڈریسز کی تعداد +- منتقلی - ٹوکن کو اکاؤنٹس کے درمیان منتقل کیے جانے کی تعداد +- ٹرانزیکشن کی سرگزشت - ٹوکن سمیت تمام ٹرانزیکشنز کی سرگزشت +- کانٹریکٹ ایڈریس - ٹوکن کا ایڈریس جسے مین نیٹ پر تعینات کیا گیا تھا +- اعشاریے - ERC-20 ٹوکنز قابل تقسیم ہیں اور ان میں اعشاریہ کی جگہیں ہوتی ہیں + +### نیٹ ورک {#network} + +کچھ بلاک ڈیٹا Ethereum کی صحت کے بارے میں زیادہ جامع طور پر فکر مند ہے۔ + +- کل ٹرانزیکشنز - Ethereum کے بنائے جانے کے بعد سے ٹرانزیکشنز کی تعداد +- ٹرانزیکشنز فی سیکنڈ - ایک سیکنڈ میں قابل عمل ٹرانزیکشنز کی تعداد +- ETH کی قیمت - 1 ETH کی موجودہ قیمتیں +- کل ETH سپلائی - گردش میں ETH کی تعداد — یاد رکھیں کہ ہر بلاک کی تخلیق کے ساتھ بلاک انعامات کی شکل میں نیا ETH بنایا جاتا ہے +- مارکیٹ کیپ - قیمت\*سپلائی کا حساب + +## کنسینسس لیئر ڈیٹا {#consensus-layer-data} + +### ایپوک {#epoch} + +سیکورٹی وجوہات کی بنا پر، ہر ایپوک (ہر 6.4 منٹ) کے اختتام پر ویلیڈیٹرز کی بے ترتیب کمیٹیاں بنائی جاتی ہیں۔ ایپوک ڈیٹا میں شامل ہیں: + +- ایپوک نمبر +- حتمی حیثیت - آیا ایپوک کو حتمی شکل دی گئی ہے (ہاں/نہیں) +- وقت - وہ وقت جب ایپوک ختم ہوا +- تصدیقات - ایپوک میں تصدیقات کی تعداد (سلاٹس کے اندر بلاکس کے لیے ووٹ) +- ڈپازٹس - ایپوک میں شامل ETH ڈپازٹس کی تعداد (ویلیڈیٹرز کو ویلیڈیٹر بننے کے لیے ETH اسٹیک کرنا ضروری ہے) +- سلیشنگز - بلاکس یا تصدیق کنندگان کے پروپوزرز کو دی جانے والی سزاؤں کی تعداد +- ووٹنگ میں شرکت - بلاکس کی تصدیق کے لیے استعمال ہونے والی اسٹیک شدہ ETH کی رقم +- ویلیڈیٹرز - ایپوک کے لیے فعال ویلیڈیٹرز کی تعداد +- اوسط ویلیڈیٹر بیلنس - فعال ویلیڈیٹرز کا اوسط بیلنس +- سلاٹس - ایپوک میں شامل سلاٹس کی تعداد (سلاٹس میں ایک درست بلاک شامل ہے) + +### سلاٹ {#slot} + +سلاٹس بلاک کی تخلیق کے مواقع ہیں، ہر سلاٹ کے لیے دستیاب ڈیٹا میں شامل ہیں: + +- ایپوک - وہ ایپوک جس میں سلاٹ درست ہے +- سلاٹ نمبر +- اسٹیٹس - سلاٹ کا اسٹیٹس (تجویز کردہ/چھوٹ گیا) +- وقت - سلاٹ کا ٹائم اسٹیمپ +- پروپوزر - وہ ویلیڈیٹر جس نے سلاٹ کے لیے بلاک تجویز کیا +- بلاک روٹ - بیکن بلاک کا ہیش-ٹری-روٹ +- پیرنٹ روٹ - پہلے آنے والے بلاک کا ہیش +- اسٹیٹ روٹ - بیکن اسٹیٹ کا ہیش-ٹری-روٹ +- دستخط +- Randao ظاہر کرنا +- گریفیٹی - ایک بلاک پروپوزر اپنی بلاک تجویز میں 32 بائٹ طویل پیغام شامل کر سکتا ہے +- ایگزیکیوشن ڈیٹا + - بلاک ہیش + - ڈپازٹ کی گنتی + - ڈپازٹ روٹ +- تصدیقات - اس سلاٹ میں بلاک کے لیے تصدیقات کی تعداد +- ڈپازٹس - اس سلاٹ کے دوران ڈپازٹس کی تعداد +- رضاکارانہ اخراج - سلاٹ کے دوران چھوڑنے والے ویلیڈیٹرز کی تعداد +- سلیشنگز - بلاکس یا تصدیق کنندگان کے پروپوزرز کو دی جانے والی سزاؤں کی تعداد +- ووٹ - وہ ویلیڈیٹرز جنہوں نے اس سلاٹ میں بلاک کے لیے ووٹ دیا + +### بلاکس {#blocks-1} + +پروف آف اسٹیک وقت کو سلاٹس اور ایپوکس میں تقسیم کرتا ہے۔ تو اس کا مطلب ہے نیا ڈیٹا! + +- پروپوزر - وہ ویلیڈیٹر جسے نئے بلاک کی تجویز کے لیے الگورتھم کے طور پر منتخب کیا گیا تھا +- ایپوک - وہ ایپوک جس میں بلاک تجویز کیا گیا تھا +- سلاٹ - وہ سلاٹ جس میں بلاک تجویز کیا گیا تھا +- تصدیقات - سلاٹ میں شامل تصدیق کی تعداد — تصدیقات ووٹوں کی طرح ہیں جو اس بات کی نشاندہی کرتی ہیں کہ بلاک بیکن چین پر جانے کے لیے تیار ہے + +### ویلیڈیٹرز {#validators} + +ویلیڈیٹرز سلاٹس کے اندر بلاکس کی تجویز اور ان کی تصدیق کے ذمہ دار ہیں۔ + +- ویلیڈیٹر نمبر - منفرد نمبر جو ویلیڈیٹر کی نمائندگی کرتا ہے +- موجودہ بیلنس - ویلیڈیٹر کا بیلنس بشمول انعامات +- مؤثر بیلنس - ویلیڈیٹر کا بیلنس جو اسٹیکنگ کے لیے استعمال ہوتا ہے +- آمدنی - ویلیڈیٹر کے ذریعہ موصول ہونے والے انعامات یا جرمانے +- اسٹیٹس - آیا ویلیڈیٹر فی الحال آن لائن اور فعال ہے یا نہیں +- تصدیق کی تاثیر - ویلیڈیٹر کی تصدیقات کو چین میں شامل ہونے میں لگنے والا اوسط وقت +- فعالیت کے لیے اہلیت - تاریخ (اور ایپوک) جب ویلیڈیٹر تصدیق کے لیے دستیاب ہوا +- فعال ہونے کی تاریخ - تاریخ (اور ایپوک) جب ویلیڈیٹر فعال ہوا +- تجویز کردہ بلاکس - وہ بلاک جو ویلیڈیٹر نے تجویز کیا ہے +- تصدیقات - وہ تصدیقات جو ویلیڈیٹر نے فراہم کی ہیں +- ڈپازٹس - ویلیڈیٹر کے ذریعہ کیے گئے اسٹیکنگ ڈپازٹ کا منجانب ایڈریس، ٹرانزیکشن ہیش، بلاک نمبر، ٹائم اسٹیمپ، رقم اور اسٹیٹس + +### تصدیقات {#attestations} + +تصدیقات چین میں بلاکس کو شامل کرنے کے لیے "ہاں" ووٹ ہیں۔ ان کا ڈیٹا تصدیق کے ریکارڈ اور تصدیق کرنے والے ویلیڈیٹرز سے متعلق ہے + +- سلاٹ - وہ سلاٹ جس میں تصدیق ہوئی +- کمیٹی انڈیکس - دیے گئے سلاٹ پر کمیٹی کا انڈیکس +- ایگریگیشن بٹس - تصدیق میں حصہ لینے والے تمام ویلیڈیٹرز کی مجموعی تصدیق کی نمائندگی کرتا ہے +- ویلیڈیٹرز - وہ ویلیڈیٹرز جنہوں نے تصدیقات فراہم کیں +- بیکن بلاک روٹ - اس بلاک کی طرف اشارہ کرتا ہے جس کی ویلیڈیٹرز تصدیق کر رہے ہیں +- ماخذ - تازہ ترین جائز ایپوک کی طرف اشارہ کرتا ہے +- ہدف - تازہ ترین ایپوک کی حد کی طرف اشارہ کرتا ہے +- دستخط + +### نیٹ ورک {#network-1} + +کنسینسس لیئر کے اعلی سطحی ڈیٹا میں درج ذیل شامل ہیں: + +- موجودہ ایپوک +- موجودہ سلاٹ +- فعال ویلیڈیٹرز - فعال ویلیڈیٹرز کی تعداد +- زیر التوا ویلیڈیٹرز - فعال ہونے کے منتظر ویلیڈیٹرز کی تعداد +- اسٹیک شدہ ETH - نیٹ ورک میں اسٹیک شدہ ETH کی رقم +- اوسط بیلنس - ویلیڈیٹرز کا اوسط ETH بیلنس + +## بلاک ایکسپلوررز {#block-explorers} + +- [Etherscan](https://etherscan.io/) - ایک بلاک ایکسپلورر جسے آپ Ethereum مین نیٹ اور ٹیسٹ نیٹ کے لیے ڈیٹا حاصل کرنے کے لیے استعمال کر سکتے ہیں +- [3xpl](https://3xpl.com/ethereum) - ایک اشتہار سے پاک اوپن سورس Ethereum ایکسپلورر جو اپنے ڈیٹاسیٹس کو ڈاؤن لوڈ کرنے کی اجازت دیتا ہے +- [Beaconcha.in](https://beaconcha.in/) - Ethereum مین نیٹ اور ٹیسٹ نیٹ کے لیے ایک اوپن سورس بلاک ایکسپلورر +- [Blockchair](https://blockchair.com/ethereum) - سب سے نجی Ethereum ایکسپلورر۔ ڈیٹا کو ترتیب دینے اور فلٹر کرنے کے لیے بھی (mempool) +- [Etherchain](https://www.etherchain.org/) - Ethereum مین نیٹ کے لیے ایک بلاک ایکسپلورر +- [Ethplorer](https://ethplorer.io/) - Ethereum مین نیٹ اور کوون ٹیسٹ نیٹ کے لیے ٹوکنز پر توجہ مرکوز کرنے والا ایک بلاک ایکسپلورر + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ٹرانزیکشنز](/developers/docs/transactions/) +- [اکاؤنٹس](/developers/docs/accounts/) +- [نیٹ ورکس](/developers/docs/networks/) diff --git a/public/content/translations/ur/developers/docs/data-and-analytics/index.md b/public/content/translations/ur/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..cf7098ad84e --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "ڈیٹا اور تجزیات" +description: "اپنے dapps میں استعمال کے لیے آن چین تجزیات اور ڈیٹا کیسے حاصل کریں" +lang: ur-in +--- + +## تعارف {#Introduction} + +جیسے جیسے نیٹ ورک کا استعمال بڑھتا جا رہا ہے، آن چین ڈیٹا میں قیمتی معلومات کی مقدار میں اضافہ ہوتا جائے گا۔ جیسے جیسے ڈیٹا کا حجم تیزی سے بڑھتا ہے، اس معلومات کا حساب لگانا اور اسے جمع کرنا تاکہ اس پر رپورٹ کیا جا سکے یا کسی dapp کو چلایا جا سکے، ایک وقت طلب اور عمل طلب کام بن سکتا ہے۔ + +موجودہ ڈیٹا فراہم کنندگان سے فائدہ اٹھانے سے ڈیولپمنٹ میں تیزی آسکتی ہے، زیادہ درست نتائج پیدا ہوسکتے ہیں، اور جاری دیکھ بھال کی کوششوں کو کم کیا جاسکتا ہے۔ اس سے ایک ٹیم اس بنیادی فعالیت پر توجہ مرکوز کر سکے گی جو ان کا پروجیکٹ فراہم کرنے کی کوشش کر رہا ہے۔ + +## شرائط {#prerequisites} + +ڈیٹا تجزیات کے تناظر میں ان کے استعمال کو بہتر طور پر سمجھنے کے لیے آپ کو [بلاک ایکسپلوررز](/developers/docs/data-and-analytics/block-explorers/) کے بنیادی تصور کو سمجھنا چاہیے۔ اس کے علاوہ، سسٹم ڈیزائن میں ان کے فوائد کو سمجھنے کے لیے خود کو [انڈیکس](/glossary/#index) کے تصور سے واقف کریں۔ + +آرکیٹیکچرل بنیادی اصولوں کے لحاظ سے، یہ سمجھنا کہ [API](https://www.wikipedia.org/wiki/API) اور [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) کیا ہیں، چاہے نظریاتی طور پر ہی سہی۔ + +## بلاک ایکسپلوررز {#block-explorers} + +بہت سے [بلاک ایکسپلوررز](/developers/docs/data-and-analytics/block-explorers/) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) گیٹ وے پیش کرتے ہیں جو ڈیولپرز کو بلاکس، ٹرانزیکشنز، ویلیڈیٹرز، اکاؤنٹس، اور دیگر آن چین سرگرمیوں پر ریئل ٹائم ڈیٹا میں مرئیت فراہم کریں گے۔ + +ڈیولپرز پھر اس ڈیٹا پر کارروائی اور اسے تبدیل کر سکتے ہیں تاکہ اپنے صارفین کو [بلاک چین](/glossary/#blockchain) کے ساتھ منفرد بصیرت اور تعاملات فراہم کر سکیں۔ مثال کے طور پر، [Etherscan](https://etherscan.io) اور [Blockscout](https://eth.blockscout.com) ہر 12s سلاٹ کے لیے ایگزیکیوشن اور کنسنسس ڈیٹا فراہم کرتے ہیں۔ + +## دی گراف {#the-graph} + +[دی گراف](https://thegraph.com/) ایک انڈیکسنگ پروٹوکول ہے جو سب گراف کے نام سے معروف اوپن APIs کے ذریعے بلاک چین ڈیٹا کو استفسار کرنے کا ایک آسان طریقہ فراہم کرتا ہے۔ + +دی گراف کے ساتھ، ڈیولپرز اس سے فائدہ اٹھا سکتے ہیں: + +- غیر مرکزی انڈیکسنگ: متعدد انڈیکسرز کے ذریعے بلاک چین ڈیٹا کو انڈیکس کرنے کے قابل بناتا ہے، اس طرح ناکامی کے کسی بھی ایک نقطہ کو ختم کرتا ہے۔ +- GraphQL استفسارات: انڈیکس شدہ ڈیٹا سے استفسار کے لیے ایک طاقتور GraphQL انٹرفیس فراہم کرتا ہے، جس سے ڈیٹا کی بازیافت انتہائی آسان ہوجاتی ہے۔ +- کسٹمائزیشن: بلاک چین ڈیٹا کو تبدیل کرنے اور ذخیرہ کرنے کے لیے اپنی منطق کی وضاحت کریں، اور دی گراف نیٹ ورک پر دوسرے ڈیولپرز کے ذریعہ شائع کردہ سب گراف کو دوبارہ استعمال کریں۔ + +5 منٹ کے اندر ایک سب گراف بنانے، ڈیپلائے کرنے اور استفسار کرنے کے لیے اس [کوئیک اسٹارٹ](https://thegraph.com/docs/en/quick-start/) گائیڈ پر عمل کریں۔ + +## کلائنٹ کا تنوع {#client-diversity} + +[کلائنٹ کا تنوع](/developers/docs/nodes-and-clients/client-diversity/) ایتھیریم نیٹ ورک کی مجموعی صحت کے لیے اہم ہے کیونکہ یہ بگز اور ایکسپلائٹس کے خلاف لچک فراہم کرتا ہے۔ اب کلائنٹ کے تنوع کے کئی ڈیش بورڈز ہیں جن میں [clientdiversity.org](https://clientdiversity.org/)، [rated.network](https://www.rated.network)، [supermajority.info](https://supermajority.info//) اور [Ethernodes](https://ethernodes.org/) شامل ہیں۔ + +## ڈیون اینالیٹکس {#dune-analytics} + +[ڈیون اینالیٹکس](https://dune.com/) بلاک چین ڈیٹا کو ریلیشنل ڈیٹا بیس (DuneSQL) ٹیبلز میں پہلے سے پراسیس کرتا ہے، صارفین کو SQL کا استعمال کرتے ہوئے بلاک چین ڈیٹا سے استفسار کرنے اور استفسار کے نتائج کی بنیاد پر ڈیش بورڈ بنانے کی اجازت دیتا ہے۔ آن چین ڈیٹا کو 4 خام جدولوں میں منظم کیا گیا ہے: `blocks`، `transactions`، (ایونٹ) `logs` اور (کال) `traces`۔ مقبول معاہدوں اور پروٹوکولز کو ڈی کوڈ کیا گیا ہے، اور ہر ایک کے پاس ایونٹ اور کال ٹیبلز کا اپنا سیٹ ہوتا ہے۔ ان ایونٹ اور کال ٹیبلز پر مزید کارروائی کی جاتی ہے اور پروٹوکولز کی قسم کے مطابق تجریدی جدولوں میں منظم کیا جاتا ہے، مثال کے طور پر، dex، لینڈنگ، اسٹیبل کوائنز، وغیرہ۔ + +## SQD {#sqd} + +[SQD](https://sqd.dev/) ایک غیر مرکزی ہائپر-اسکیل ایبل ڈیٹا پلیٹ فارم ہے جو بڑی مقدار میں ڈیٹا تک موثر، بغیر اجازت کے رسائی فراہم کرنے کے لیے موزوں ہے۔ یہ فی الحال تاریخی آن چین ڈیٹا پیش کرتا ہے، بشمول ایونٹ لاگز، ٹرانزیکشن رسیدیں، ٹریسز، اور فی ٹرانزیکشن اسٹیٹ ڈفس۔ SQD کسٹم ڈیٹا نکالنے اور پروسیسنگ پائپ لائنز بنانے کے لیے ایک طاقتور ٹول کٹ پیش کرتا ہے، جو فی سیکنڈ 150k بلاکس تک کی انڈیکسنگ کی رفتار حاصل کرتا ہے۔ + +شروع کرنے کے لیے، [ڈاکومنٹیشن](https://docs.sqd.dev/) پر جائیں یا SQD کے ساتھ آپ کیا بنا سکتے ہیں اس کی [EVM مثالیں](https://github.com/subsquid-labs/squid-evm-examples) دیکھیں۔ + +## سب کوئری نیٹ ورک {#subquery-network} + +[SubQuery](https://subquery.network/) ایک سرکردہ ڈیٹا انڈیکسر ہے جو ڈیولپرز کو ان کے web3 پروجیکٹس کے لیے تیز، قابل اعتماد، غیر مرکزی، اور حسب ضرورت APIs فراہم کرتا ہے۔ SubQuery 165+ سے زیادہ ایکو سسٹمز (بشمول ایتھیریم) کے ڈیولپرز کو بھرپور انڈیکس شدہ ڈیٹا کے ساتھ بااختیار بناتا ہے تاکہ وہ اپنے صارفین کے لیے ایک بدیہی اور عمیق تجربات تخلیق کر سکیں۔ سب کوئری نیٹ ورک آپ کی نہ رکنے والی ایپس کو ایک لچکدار اور غیر مرکزی انفراسٹرکچر نیٹ ورک کے ساتھ طاقت دیتا ہے۔ ڈیٹا پروسیسنگ سرگرمیوں کے لیے کسٹم بیک اینڈ بنانے میں وقت صرف کیے بغیر، مستقبل کی web3 ایپلی کیشنز بنانے کے لیے SubQuery کے بلاک چین ڈیولپر ٹول کٹ کا استعمال کریں۔ + +شروع کرنے کے لیے، [ایتھیریم کوئیک اسٹارٹ گائیڈ](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) پر جائیں تاکہ [SubQuery کی مینیجڈ سروس](https://managedservice.subquery.network/) یا [SubQuery کے غیر مرکزی نیٹ ورک](https://app.subquery.network/dashboard) پر لائیو جانے سے پہلے ٹیسٹنگ کے لیے مقامی ڈوکر ماحول میں منٹوں میں ایتھیریم بلاک چین ڈیٹا کو انڈیکس کرنا شروع کریں۔ + +## EVM کوئری لینگویج {#evm-query-language} + +EVM کوئری لینگویج (EQL) ایک SQL جیسی زبان ہے جسے EVM (ایتھیریم ورچوئل مشین) چینز سے استفسار کرنے کے لیے ڈیزائن کیا گیا ہے۔ EQL کا حتمی مقصد EVM چین کے فرسٹ کلاس سٹیزنز (بلاکس، اکاؤنٹس، اور ٹرانزیکشنز) پر پیچیدہ ریلیشنل استفسارات کی حمایت کرنا ہے جبکہ ڈیولپرز اور محققین کو روزمرہ کے استعمال کے لیے ایک ارگونومک نحو فراہم کرنا ہے۔ EQL کے ساتھ، ڈیولپرز مانوس SQL جیسی نحو کا استعمال کرتے ہوئے بلاک چین ڈیٹا حاصل کر سکتے ہیں اور پیچیدہ بوائلر پلیٹ کوڈ کی ضرورت کو ختم کر سکتے ہیں۔ EQL معیاری بلاک چین ڈیٹا کی درخواستوں کی حمایت کرتا ہے (مثلاً، ایتھیریم پر کسی اکاؤنٹ کا نانس اور بیلنس بازیافت کرنا یا موجودہ بلاک کا سائز اور ٹائم اسٹیمپ حاصل کرنا) اور زیادہ پیچیدہ درخواستوں اور فیچر سیٹس کے لیے مسلسل حمایت شامل کر رہا ہے۔ + +## مزید مطالعہ {#further-reading} + +- [کرپٹو ڈیٹا کی کھوج I: ڈیٹا فلو آرکیٹیکچرز](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [گراف نیٹ ورک کا جائزہ](https://thegraph.com/docs/en/about/) +- [گراف کوئری پلے گراؤنڈ](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [EtherScan پر API کوڈ کی مثالیں](https://etherscan.io/apis#contracts) +- [Blockscout پر API ڈاکومنٹیشن](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in بیکن چین ایکسپلورر](https://beaconcha.in) +- [ڈیون کی بنیادی باتیں](https://docs.dune.com/#dune-basics) +- [سب کوئری ایتھیریم کوئیک اسٹارٹ گائیڈ](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [SQD نیٹ ورک کا جائزہ](https://docs.sqd.dev/) +- [EVM کوئری لینگویج](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/ur/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/ur/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..1a1d6edb05c --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "بلاک چین ڈیٹا اسٹوریج کی حکمت عملیاں" +description: "بلاک چین کا استعمال کرکے ڈیٹا کو اسٹور کرنے کے کئی طریقے ہیں۔ یہ مضمون مختلف حکمت عملیوں، ان کی لاگتوں اور ٹریڈ آفس، نیز اسے محفوظ طریقے سے استعمال کرنے کی ضروریات کا موازنہ کرے گا۔" +lang: ur-in +--- + +معلومات کو براہ راست بلاک چین پر، یا بلاک چین کے ذریعے محفوظ کردہ طریقے سے اسٹور کرنے کے متعدد طریقے ہیں: + +- EIP-4844 بلابز +- کال ڈیٹا +- L1 میکانزم کے ساتھ آف چین +- کنٹریکٹ "کوڈ" +- ایونٹس +- EVM اسٹوریج + +کون سا طریقہ استعمال کرنا ہے اس کا انتخاب کئی معیارات پر مبنی ہے: + +- معلومات کا ماخذ۔ کال ڈیٹا میں معلومات براہ راست خود بلاک چین سے نہیں آ سکتیں۔ +- معلومات کی منزل۔ کال ڈیٹا صرف اس ٹرانزیکشن میں دستیاب ہوتا ہے جس میں یہ شامل ہو۔ ایونٹس آن چین پر بالکل بھی قابل رسائی نہیں ہیں۔ +- کتنی پریشانی قابل قبول ہے؟ وہ کمپیوٹرز جو ایک مکمل نوڈ چلاتے ہیں، براؤزر میں چلنے والی ایپلیکیشن میں ایک لائٹ کلائنٹ سے زیادہ پروسیسنگ انجام دے سکتے ہیں۔ +- کیا ہر نوڈ سے معلومات تک آسان رسائی کو آسان بنانا ضروری ہے؟ +- سیکورٹی کی ضروریات۔ + +## سیکورٹی کی ضروریات {#security-requirements} + +عام طور پر، معلومات کی سیکورٹی تین خصوصیات پر مشتمل ہوتی ہے: + +- _رازداری_، غیر مجاز اداروں کو معلومات پڑھنے کی اجازت نہیں ہے۔ یہ بہت سے معاملات میں اہم ہے، لیکن یہاں نہیں۔ _بلاک چین پر کوئی راز نہیں ہوتے_۔ بلاک چینز کام کرتے ہیں کیونکہ کوئی بھی اسٹیٹ کی منتقلی کی تصدیق کر سکتا ہے، لہذا ان کا استعمال براہ راست رازوں کو اسٹور کرنے کے لیے کرنا ناممکن ہے۔ بلاک چین پر خفیہ معلومات کو اسٹور کرنے کے طریقے ہیں، لیکن وہ سب کم از کم ایک 'کی' (key) کو اسٹور کرنے کے لیے کسی آف چین جزو پر انحصار کرتے ہیں۔ + +- _سالمیت_، معلومات درست ہے، اسے غیر مجاز اداروں کے ذریعے، یا غیر مجاز طریقوں سے تبدیل نہیں کیا جا سکتا (مثال کے طور پر، `Transfer` ایونٹ کے بغیر [ERC-20 ٹوکنز](https://eips.ethereum.org/EIPS/eip-20#events) منتقل کرنا)۔ بلاک چین پر، ہر نوڈ ہر اسٹیٹ کی تبدیلی کی تصدیق کرتا ہے، جو سالمیت کو یقینی بناتا ہے۔ + +- _دستیابی_، معلومات کسی بھی مجاز ادارے کے لیے دستیاب ہے۔ بلاک چین پر، یہ عام طور پر ہر [مکمل نوڈ](https://ethereum.org/developers/docs/nodes-and-clients#full-node) پر معلومات کو دستیاب کر کے حاصل کیا جاتا ہے۔ + +یہاں کے تمام مختلف حلوں میں بہترین سالمیت ہے، کیونکہ ہیشز L1 پر پوسٹ کیے جاتے ہیں۔ تاہم، ان کی دستیابی کی ضمانتیں مختلف ہیں۔ + +## شرائط {#prerequisites} + +آپ کو [بلاک چین کی بنیادی باتوں](/developers/docs/intro-to-ethereum/) کی اچھی سمجھ ہونی چاہیے۔ یہ صفحہ یہ بھی فرض کرتا ہے کہ قاری [بلاکس](/developers/docs/blocks/)، [ٹرانزیکشنز](/developers/docs/transactions/)، اور دیگر متعلقہ موضوعات سے واقف ہے۔ + +## EIP-4844 بلابز {#eip-4844-blobs} + +[Dencun ہارڈفورک](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) سے شروع ہو کر، ایتھیریم بلاک چین میں [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) شامل ہے، جو ایتھیریم میں محدود عمر والے ڈیٹا بلابز کو شامل کرتا ہے (ابتدائی طور پر تقریباً [18 دن](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration))۔ ان بلابز کی قیمت [ایگزیکیوشن گیس](/developers/docs/gas) سے الگ ہے، حالانکہ ایک اسی طرح کا میکانزم استعمال ہوتا ہے۔ یہ عارضی ڈیٹا پوسٹ کرنے کا ایک سستا طریقہ ہے۔ + +EIP-4844 بلابز کا بنیادی استعمال رول اپس کے لیے اپنے ٹرانزیکشنز کو شائع کرنا ہے۔ [آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups) کو اپنے بلاک چینز پر ٹرانزیکشنز شائع کرنے کی ضرورت ہوتی ہے۔ ان ٹرانزیکشنز کو [چیلنج پیریڈ](https://docs.optimism.io/connect/resources/glossary#challenge-period) کے دوران کسی کے لیے بھی دستیاب ہونا چاہیے تاکہ [ویلیڈیٹرز](https://docs.optimism.io/connect/resources/glossary#validator) کو غلطی ٹھیک کرنے کے قابل بنایا جا سکے اگر رول اپ کا [سیکوینسر](https://docs.optimism.io/connect/resources/glossary#sequencer) غلط اسٹیٹ روٹ پوسٹ کرتا ہے۔ + +تاہم، ایک بار جب چیلنج پیریڈ گزر جاتا ہے اور اسٹیٹ روٹ کو حتمی شکل دے دی جاتی ہے، تو ان ٹرانزیکشنز کو جاننے کا باقی مقصد چین کی موجودہ اسٹیٹ کو نقل کرنا ہوتا ہے۔ یہ اسٹیٹ چین نوڈز سے بھی دستیاب ہے، جس میں بہت کم پروسیسنگ کی ضرورت ہوتی ہے۔ لہذا ٹرانزیکشن کی معلومات کو اب بھی کچھ جگہوں پر محفوظ کیا جانا چاہیے، جیسے کہ [بلاک ایکسپلوررز](/developers/docs/data-and-analytics/block-explorers)، لیکن ایتھیریم کی فراہم کردہ سنسر شپ مزاحمت کی سطح کے لیے ادائیگی کرنے کی کوئی ضرورت نہیں ہے۔ + +[زیرو نالج رول اپس](/developers/docs/scaling/zk-rollups/#data-availability) بھی اپنے ٹرانزیکشن ڈیٹا کو پوسٹ کرتے ہیں تاکہ دوسرے نوڈز موجودہ اسٹیٹ کو نقل کر سکیں اور ویلیڈیٹی پروفس کی تصدیق کر سکیں، لیکن پھر یہ ایک قلیل مدتی ضرورت ہے۔ + +لکھنے کے وقت EIP-4844 پر پوسٹ کرنے کی لاگت ایک wei (10-18 ETH) فی بائٹ ہے، جو [21,000 ایگزیکیوشن گیس جو کسی بھی ٹرانزیکشن، بشمول وہ جو بلابز پوسٹ کرتا ہے، کی لاگت ہے](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index) کے مقابلے میں نہ ہونے کے برابر ہے۔ آپ موجودہ EIP-4844 قیمت [blobscan.com](https://blobscan.com/blocks) پر دیکھ سکتے ہیں۔ + +کچھ مشہور رول اپس کے ذریعے پوسٹ کیے گئے بلابز کو دیکھنے کے لیے یہاں ایڈریسز دیے گئے ہیں۔ + +| رول اپ | میل باکس ایڈریس | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## کال ڈیٹا {#calldata} + +کال ڈیٹا ان بائٹس سے مراد ہے جو ٹرانزیکشن کے حصے کے طور پر بھیجی جاتی ہیں۔ اسے بلاک چین کے مستقل ریکارڈ کے حصے کے طور پر اس بلاک میں اسٹور کیا جاتا ہے جس میں وہ ٹرانزیکشن شامل ہوتا ہے۔ + +یہ بلاک چین میں مستقل طور پر ڈیٹا ڈالنے کا سب سے سستا طریقہ ہے۔ فی بائٹ لاگت یا تو 4 ایگزیکیوشن گیس ہے (اگر بائٹ صفر ہے) یا 16 گیس (کوئی دوسری ویلیو)۔ اگر ڈیٹا کمپریس کیا جاتا ہے، جو کہ ایک معیاری عمل ہے، تو ہر بائٹ ویلیو کے مساوی طور پر ممکن ہونے کا امکان ہے، لہذا اوسط لاگت تقریباً 15.95 گیس فی بائٹ ہے۔ + +لکھنے کے وقت، قیمتیں 12 gwei/gas اور 2300 $/ETH ہیں، جس کا مطلب ہے کہ لاگت تقریباً 45 سینٹ فی کلو بائٹ ہے۔ چونکہ یہ EIP-4844 سے پہلے سب سے سستا طریقہ تھا، یہ وہ طریقہ ہے جسے رول اپس ٹرانزیکشن کی معلومات کو اسٹور کرنے کے لیے استعمال کرتے تھے، جنہیں [فالٹ چیلنجز](https://docs.optimism.io/stack/protocol/overview#fault-proofs) کے لیے دستیاب ہونے کی ضرورت ہوتی ہے، لیکن انہیں براہ راست آن چین پر قابل رسائی ہونے کی ضرورت نہیں ہوتی۔ + +کچھ مشہور رول اپس کے ذریعے پوسٹ کیے گئے ٹرانزیکشنز کو دیکھنے کے لیے یہاں ایڈریسز دیے گئے ہیں۔ + +| رول اپ | میل باکس ایڈریس | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## L1 میکانزم کے ساتھ آف چین {#offchain-with-l1-mechs} + +آپ کے سیکورٹی ٹریڈ آفس پر منحصر ہے، معلومات کو کہیں اور رکھنا اور ایک ایسا میکانزم استعمال کرنا قابل قبول ہو سکتا ہے جو اس بات کو یقینی بنائے کہ ڈیٹا ضرورت پڑنے پر دستیاب ہو۔ اس کے کام کرنے کے لیے دو ضروریات ہیں: + +1. بلاک چین پر ڈیٹا کا ایک [ہیش](https://en.wikipedia.org/wiki/Cryptographic_hash_function) پوسٹ کریں، جسے _ان پٹ کمٹمنٹ_ کہا جاتا ہے۔ یہ ایک واحد 32 بائٹ کا لفظ ہو سکتا ہے، لہذا یہ مہنگا نہیں ہے۔ جب تک ان پٹ کمٹمنٹ دستیاب ہے، سالمیت کی یقین دہانی کرائی جاتی ہے کیونکہ کوئی دوسرا ڈیٹا تلاش کرنا ممکن نہیں ہے جو اسی ویلیو پر ہیش کرے۔ لہذا اگر غلط ڈیٹا فراہم کیا جاتا ہے، تو اس کا پتہ لگایا جا سکتا ہے۔ + +2. ایک ایسا میکانزم رکھیں جو دستیابی کو یقینی بنائے۔ مثال کے طور پر، [Redstone](https://redstone.xyz/docs/what-is-redstone) میں کوئی بھی نوڈ دستیابی کا چیلنج جمع کرا سکتا ہے۔ اگر سیکوینسر ڈیڈ لائن تک آن چین پر جواب نہیں دیتا ہے، تو ان پٹ کمٹمنٹ کو مسترد کر دیا جاتا ہے، لہذا معلومات کو کبھی پوسٹ نہ کیا گیا سمجھا جاتا ہے۔ + +یہ ایک آپٹیمسٹک رول اپ کے لیے قابل قبول ہے کیونکہ ہم پہلے ہی اسٹیٹ روٹ کے لیے کم از کم ایک ایماندار تصدیق کنندہ پر انحصار کر رہے ہیں۔ ایسا ایماندار تصدیق کنندہ یہ بھی یقینی بنائے گا کہ اس کے پاس بلاکس پر کارروائی کرنے کے لیے ڈیٹا ہے، اور اگر معلومات آف چین دستیاب نہیں ہے تو دستیابی کا چیلنج جاری کرے گا۔ اس قسم کے آپٹیمسٹک رول اپ کو [پلازما](/developers/docs/scaling/plasma/) کہا جاتا ہے۔ + +## کنٹریکٹ کوڈ {#contract-code} + +وہ معلومات جسے صرف ایک بار لکھنے کی ضرورت ہے، کبھی اوور رائٹ نہیں ہوتی، اور آن چین پر دستیاب ہونے کی ضرورت ہے، اسے کنٹریکٹ کوڈ کے طور پر اسٹور کیا جا سکتا ہے۔ اس کا مطلب ہے کہ ہم ڈیٹا کے ساتھ ایک "اسمارٹ کنٹریکٹ" بناتے ہیں اور پھر معلومات کو پڑھنے کے لیے [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) کا استعمال کرتے ہیں۔ فائدہ یہ ہے کہ کوڈ کاپی کرنا نسبتاً سستا ہے۔ + +میموری کی توسیع کی لاگت کے علاوہ، `EXTCODECOPY` کی لاگت ایک کنٹریکٹ تک پہلی رسائی (جب یہ "کولڈ" ہو) کے لیے 2600 گیس اور اسی کنٹریکٹ سے بعد کی کاپیوں کے لیے 100 گیس کے علاوہ 3 گیس فی 32 بائٹ ورڈ ہے۔ کال ڈیٹا کے مقابلے میں، جس کی لاگت 15.95 فی بائٹ ہے، یہ تقریباً 200 بائٹس سے شروع ہو کر سستا ہے۔ [میموری کی توسیع کی لاگت کے فارمولے](https://www.evm.codes/about#memoryexpansion) کی بنیاد پر، جب تک آپ کو 4MB سے زیادہ میموری کی ضرورت نہیں ہے، میموری کی توسیع کی لاگت کال ڈیٹا شامل کرنے کی لاگت سے کم ہے۔ + +یقیناً، یہ صرف ڈیٹا کو _پڑھنے_ کی لاگت ہے۔ کنٹریکٹ بنانے کی لاگت تقریباً 32,000 گیس + 200 گیس/بائٹ ہے۔ یہ طریقہ صرف اس وقت اقتصادی ہے جب ایک ہی معلومات کو مختلف ٹرانزیکشنز میں کئی بار پڑھنے کی ضرورت ہو۔ + +کنٹریکٹ کوڈ بے معنی ہو سکتا ہے، جب تک کہ یہ `0xEF` سے شروع نہ ہو۔ جو کنٹریکٹس `0xEF` سے شروع ہوتے ہیں ان کی تشریح [ایتھیریم آبجیکٹ فارمیٹ](https://notes.ethereum.org/@ipsilon/evm-object-format-overview) کے طور پر کی جاتی ہے، جس کی بہت سخت ضروریات ہیں۔ + +## ایونٹس {#events} + +[ایونٹس](https://docs.alchemy.com/docs/solidity-events) اسمارٹ کنٹریکٹس کے ذریعے خارج کیے جاتے ہیں، اور آف چین سافٹ ویئر کے ذریعے پڑھے جاتے ہیں۔ +ان کا فائدہ یہ ہے کہ آف چین کوڈ ایونٹس کو سن سکتا ہے۔ لاگت [گیس](https://www.evm.codes/#a0?fork=cancun)، 375 کے علاوہ 8 گیس فی بائٹ ڈیٹا ہے۔ 12 gwei/gas اور 2300 $/ETH پر، یہ ایک سینٹ کے علاوہ 22 سینٹ فی کلو بائٹ میں ترجمہ کرتا ہے۔ + +## اسٹوریج {#storage} + +اسمارٹ کنٹریکٹس کو [مستقل اسٹوریج](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) تک رسائی حاصل ہوتی ہے۔ تاہم، یہ بہت مہنگا ہے۔ ایک پہلے سے خالی اسٹوریج سلاٹ میں 32 بائٹ کا لفظ لکھنے پر [22,100 گیس لاگت](https://www.evm.codes/#55?fork=cancun) آ سکتی ہے۔ 12 gwei/gas اور 2300 $/ETH پر، یہ تقریباً 61 سینٹ فی رائٹ آپریشن، یا 19.5$ فی کلو بائٹ ہے۔ + +یہ ایتھیریم میں اسٹوریج کی سب سے مہنگی شکل ہے۔ + +## خلاصہ {#summary} + +یہ جدول مختلف آپشنز، ان کے فوائد اور نقصانات کا خلاصہ کرتا ہے۔ + +| اسٹوریج کی قسم | ڈیٹا کا ماخذ | دستیابی کی ضمانت | آن چین دستیابی | اضافی حدود | +| ------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------- | +| EIP-4844 بلابز | آف چین | [~18 دن](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) کے لیے ایتھیریم کی ضمانت | صرف ہیش دستیاب ہے | | +| کال ڈیٹا | آف چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ) | صرف اس صورت میں دستیاب ہے جب کسی کنٹریکٹ میں لکھا جائے، اور اس ٹرانزیکشن پر | | +| L1 میکانزم کے ساتھ آف چین | آف چین | چیلنج پیریڈ کے دوران "ایک ایماندار تصدیق کنندہ" کی ضمانت | صرف ہیش | چیلنج میکانزم کے ذریعے ضمانت دی گئی، صرف چیلنج پیریڈ کے دوران | +| کنٹریکٹ کوڈ | آن چین یا آف چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ) | جی ہاں | ایک "بے ترتیب" ایڈریس پر لکھا گیا، `0xEF` سے شروع نہیں ہو سکتا | +| ایونٹس | آن چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ) | نہیں | | +| اسٹوریج | آن چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ اور موجودہ اسٹیٹ جب تک کہ اوور رائٹ نہ ہو جائے) | جی ہاں | | diff --git a/public/content/translations/ur/developers/docs/data-availability/index.md b/public/content/translations/ur/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..43db076952d --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "ڈیٹا کی دستیابی" +description: "ایتھیریم میں ڈیٹا کی دستیابی سے متعلق مسائل اور حل کا ایک جائزہ" +lang: ur-in +--- + +"بھروسہ نہ کریں، تصدیق کریں" ایتھیریم میں ایک عام کہاوت ہے۔ خیال یہ ہے کہ آپ کا نوڈ ان بلاکس میں موجود تمام ٹرانزیکشنز کو انجام دے کر آزادانہ طور پر اس بات کی تصدیق کر سکتا ہے کہ اسے موصول ہونے والی معلومات درست ہیں، یہ یقینی بنانے کے لیے کہ تجویز کردہ تبدیلیاں بالکل ان سے ملتی ہیں جو نوڈ کے ذریعے آزادانہ طور پر شمار کی گئی ہیں۔ اس کا مطلب ہے کہ نوڈس کو اس بات پر بھروسہ کرنے کی ضرورت نہیں ہے کہ بلاک کے بھیجنے والے ایماندار ہیں۔ اگر ڈیٹا غائب ہو تو یہ ممکن نہیں ہے۔ + +**ڈیٹا کی دستیابی** سے مراد وہ اعتماد ہے جو ایک صارف اس بات پر کر سکتا ہے کہ کسی بلاک کی تصدیق کے لیے درکار ڈیٹا واقعی تمام نیٹ ورک شرکاء کے لیے دستیاب ہے۔ ایتھیریم لیئر 1 پر مکمل نوڈس کے لیے یہ نسبتاً آسان ہے؛ مکمل نوڈ ہر بلاک میں تمام ڈیٹا کی ایک کاپی ڈاؤن لوڈ کرتا ہے - ڈاؤن لوڈنگ کو ممکن بنانے کے لیے ڈیٹا کا دستیاب ہونا _ضروری_ ہے۔ غائب ڈیٹا والے بلاک کو بلاک چین میں شامل کرنے کے بجائے مسترد کر دیا جائے گا۔ یہ "آن چین ڈیٹا کی دستیابی" ہے اور یہ مونو لیتھک بلاک چینز کی ایک خصوصیت ہے۔ مکمل نوڈس کو غلط ٹرانزیکشنز قبول کرنے کے لیے دھوکہ نہیں دیا جا سکتا کیونکہ وہ ہر ٹرانزیکشن کو خود ڈاؤن لوڈ اور انجام دیتے ہیں۔ تاہم، ماڈیولر بلاک چینز، لیئر 2 رول اپس اور لائٹ کلائنٹس کے لیے، ڈیٹا کی دستیابی کا منظر نامہ زیادہ پیچیدہ ہے، جس کے لیے کچھ زیادہ جدید تصدیقی طریقہ کار کی ضرورت ہوتی ہے۔ + +## شرائط {#prerequisites} + +آپ کو [بلاک چین کے بنیادی اصولوں](/developers/docs/intro-to-ethereum/)، خاص طور پر [اتفاق رائے کے طریقہ کار](/developers/docs/consensus-mechanisms/) کی اچھی سمجھ ہونی چاہیے۔ یہ صفحہ یہ بھی فرض کرتا ہے کہ قاری [بلاکس](/developers/docs/blocks/)، [ٹرانزیکشنز](/developers/docs/transactions/)، [نوڈس](/developers/docs/nodes-and-clients/)، [اسکیلنگ سلوشنز](/developers/docs/scaling/)، اور دیگر متعلقہ موضوعات سے واقف ہے۔ + +## ڈیٹا کی دستیابی کا مسئلہ {#the-data-availability-problem} + +ڈیٹا کی دستیابی کا مسئلہ پورے نیٹ ورک کو یہ ثابت کرنے کی ضرورت ہے کہ بلاک چین میں شامل کیے جانے والے کچھ ٹرانزیکشن ڈیٹا کا خلاصہ شدہ فارم واقعی درست ٹرانزیکشنز کے ایک سیٹ کی نمائندگی کرتا ہے، لیکن ایسا تمام نوڈس سے تمام ڈیٹا ڈاؤن لوڈ کرنے کی ضرورت کے بغیر کیا جاتا ہے۔ بلاکس کی آزادانہ طور پر تصدیق کے لیے مکمل ٹرانزیکشن ڈیٹا ضروری ہے، لیکن تمام نوڈس کو تمام ٹرانزیکشن ڈیٹا ڈاؤن لوڈ کرنے کی ضرورت اسکیلنگ میں ایک رکاوٹ ہے۔ ڈیٹا کی دستیابی کے مسئلے کے حل کا مقصد ان نیٹ ورک شرکاء کو کافی یقین دہانی فراہم کرنا ہے جو خود ڈیٹا ڈاؤن لوڈ اور اسٹور نہیں کرتے ہیں کہ تصدیق کے لیے مکمل ٹرانزیکشن ڈیٹا دستیاب کرایا گیا تھا۔ + +[لائٹ نوڈس](/developers/docs/nodes-and-clients/light-clients) اور [لیئر 2 رول اپس](/developers/docs/scaling) نیٹ ورک شرکاء کی اہم مثالیں ہیں جنہیں ڈیٹا کی دستیابی کی مضبوط یقین دہانی کی ضرورت ہوتی ہے لیکن وہ خود ٹرانزیکشن ڈیٹا ڈاؤن لوڈ اور پراسیس نہیں کر سکتے۔ ٹرانزیکشن ڈیٹا ڈاؤن لوڈ کرنے سے گریز ہی لائٹ نوڈس کو لائٹ بناتا ہے اور رول اپس کو موثر اسکیلنگ سلوشنز بننے کے قابل بناتا ہے۔ + +ڈیٹا کی دستیابی مستقبل کے ["اسٹیٹ لیس"](/roadmap/statelessness) ایتھیریم کلائنٹس کے لیے بھی ایک اہم تشویش ہے جنہیں بلاکس کی تصدیق کے لیے اسٹیٹ ڈیٹا ڈاؤن لوڈ اور اسٹور کرنے کی ضرورت نہیں ہوتی ہے۔ اسٹیٹ لیس کلائنٹس کو اب بھی اس بات کا یقین کرنے کی ضرورت ہے کہ ڈیٹا _کہیں نہ کہیں_ دستیاب ہے اور اسے صحیح طریقے سے پراسیس کیا گیا ہے۔ + +## ڈیٹا کی دستیابی کے حل {#data-availability-solutions} + +### ڈیٹا کی دستیابی کی سیمپلنگ (DAS) {#data-availability-sampling} + +ڈیٹا کی دستیابی کی سیمپلنگ (DAS) نیٹ ورک کے لیے یہ چیک کرنے کا ایک طریقہ ہے کہ ڈیٹا کسی انفرادی نوڈ پر بہت زیادہ دباؤ ڈالے بغیر دستیاب ہے۔ ہر نوڈ (بشمول نان-اسٹیکنگ نوڈس) کل ڈیٹا کا کچھ چھوٹا، تصادفی طور پر منتخب کردہ سب سیٹ ڈاؤن لوڈ کرتا ہے۔ نمونوں کو کامیابی سے ڈاؤن لوڈ کرنا اعلیٰ اعتماد کے ساتھ اس بات کی تصدیق کرتا ہے کہ تمام ڈیٹا دستیاب ہے۔ یہ ڈیٹا ایریزر کوڈنگ پر انحصار کرتا ہے، جو ایک دیئے گئے ڈیٹا سیٹ کو فالتو معلومات کے ساتھ پھیلاتا ہے (ایسا کرنے کا طریقہ یہ ہے کہ ڈیٹا پر ایک فنکشن جسے _پولینومیل_ کہا جاتا ہے فٹ کیا جائے اور اس پولینومیل کو اضافی پوائنٹس پر جانچا جائے)۔ یہ ضرورت پڑنے پر فالتو ڈیٹا سے اصل ڈیٹا کو بازیافت کرنے کی اجازت دیتا ہے۔ اس ڈیٹا کی تخلیق کا ایک نتیجہ یہ ہے کہ اگر اصل ڈیٹا کا _کوئی بھی_ حصہ دستیاب نہیں ہے، تو توسیع شدہ ڈیٹا کا _آدھا_ حصہ غائب ہو جائے گا! ہر نوڈ کے ذریعے ڈاؤن لوڈ کیے گئے ڈیٹا نمونوں کی مقدار کو اس طرح ٹیون کیا جا سکتا ہے کہ یہ _انتہائی_ ممکن ہے کہ ہر کلائنٹ کے ذریعے نمونہ لیے گئے ڈیٹا کے ٹکڑوں میں سے کم از کم ایک غائب ہو جائے گا _اگر_ نصف سے کم ڈیٹا واقعی دستیاب ہو۔ + +[Full Danksharding](/roadmap/danksharding/#what-is-danksharding) کے نفاذ کے بعد یہ یقینی بنانے کے لیے DAS کا استعمال کیا جائے گا کہ رول اپ آپریٹرز اپنا ٹرانزیکشن ڈیٹا دستیاب کرائیں۔ ایتھیریم نوڈس اوپر بیان کردہ ریڈنڈینسی اسکیم کا استعمال کرتے ہوئے بلابز میں فراہم کردہ ٹرانزیکشن ڈیٹا کا تصادفی طور پر نمونہ لیں گے تاکہ یہ یقینی بنایا جا سکے کہ تمام ڈیٹا موجود ہے۔ اسی تکنیک کو یہ یقینی بنانے کے لیے بھی استعمال کیا جا سکتا ہے کہ بلاک پروڈیوسرز اپنا تمام ڈیٹا محفوظ لائٹ کلائنٹس کو دستیاب کرا رہے ہیں۔ اسی طرح، [proposer-builder separation](/roadmap/pbs) کے تحت، صرف بلاک بلڈر کو ایک پورے بلاک کو پراسیس کرنے کی ضرورت ہوگی - دوسرے ویلیڈیٹرز ڈیٹا کی دستیابی کی سیمپلنگ کا استعمال کرتے ہوئے تصدیق کریں گے۔ + +### ڈیٹا کی دستیابی کی کمیٹیاں {#data-availability-committees} + +ڈیٹا کی دستیابی کی کمیٹیاں (DACs) قابل اعتماد پارٹیاں ہیں جو ڈیٹا کی دستیابی فراہم کرتی ہیں، یا اس کی تصدیق کرتی ہیں۔ DACs کو DAS کے بجائے، [یا اس کے ساتھ ملا کر](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) استعمال کیا جا سکتا ہے۔ کمیٹیوں کے ساتھ آنے والی سیکورٹی کی ضمانتیں مخصوص سیٹ اپ پر منحصر ہوتی ہیں۔ مثال کے طور پر، ایتھیریم لائٹ نوڈس کے لیے ڈیٹا کی دستیابی کی تصدیق کے لیے ویلیڈیٹرز کے تصادفی طور پر نمونہ لیے گئے سب سیٹس کا استعمال کرتا ہے۔ + +کچھ ویلیڈیمز کے ذریعے DACs کا بھی استعمال کیا جاتا ہے۔ DAC نوڈس کا ایک قابل اعتماد سیٹ ہے جو ڈیٹا کی کاپیاں آف لائن اسٹور کرتا ہے۔ تنازعہ کی صورت میں DAC کو ڈیٹا دستیاب کرانے کی ضرورت ہوتی ہے۔ DAC کے اراکین یہ ثابت کرنے کے لیے آن چین تصدیقات بھی شائع کرتے ہیں کہ مذکورہ ڈیٹا واقعی دستیاب ہے۔ کچھ ویلیڈیمز DACs کو پروف-آف-اسٹیک (PoS) ویلیڈیٹر سسٹم سے بدل دیتے ہیں۔ یہاں، کوئی بھی ویلیڈیٹر بن سکتا ہے اور ڈیٹا کو آف چین اسٹور کر سکتا ہے۔ تاہم، انہیں ایک "بانڈ" فراہم کرنا ہوگا، جو ایک اسمارٹ کنٹریکٹ میں جمع کیا جاتا ہے۔ بدنیتی پر مبنی رویے کی صورت میں، جیسے کہ ویلیڈیٹر کا ڈیٹا روکنا، بانڈ کو سلیش کیا جا سکتا ہے۔ پروف-آف-اسٹیک ڈیٹا کی دستیابی کی کمیٹیاں باقاعدہ DACs کے مقابلے میں کافی زیادہ محفوظ ہیں کیونکہ وہ براہ راست ایماندارانہ رویے کی ترغیب دیتی ہیں۔ + +## ڈیٹا کی دستیابی اور لائٹ نوڈس {#data-availability-and-light-nodes} + +[لائٹ نوڈس](/developers/docs/nodes-and-clients/light-clients) کو بلاک ڈیٹا ڈاؤن لوڈ کیے بغیر موصول ہونے والے بلاک ہیڈرز کی درستگی کی توثیق کرنے کی ضرورت ہے۔ اس ہلکے پن کی قیمت بلاک ہیڈرز کی آزادانہ طور پر تصدیق کرنے میں ناکامی ہے جس طرح مکمل نوڈس مقامی طور پر ٹرانزیکشنز کو دوبارہ انجام دے کر کرتے ہیں۔ + +ایتھیریم لائٹ نوڈس 512 ویلیڈیٹرز کے تصادفی سیٹوں پر بھروسہ کرتے ہیں جنہیں ایک _سنک کمیٹی_ کو تفویض کیا گیا ہے۔ سنک کمیٹی ایک DAC کے طور پر کام کرتی ہے جو لائٹ کلائنٹس کو اشارہ دیتی ہے کہ ہیڈر میں موجود ڈیٹا کرپٹوگرافک دستخط کا استعمال کرتے ہوئے درست ہے۔ ہر روز، سنک کمیٹی ریفریش ہوتی ہے۔ ہر بلاک ہیڈر لائٹ نوڈس کو خبردار کرتا ہے کہ کن ویلیڈیٹرز سے _اگلے_ بلاک پر دستخط کرنے کی توقع کی جائے، لہذا انہیں حقیقی سنک-کمیٹی ہونے کا بہانہ کرنے والے کسی بدنیتی پر مبنی گروپ پر بھروسہ کرنے کے لیے دھوکہ نہیں دیا جا سکتا۔ + +تاہم، کیا ہوگا اگر کوئی حملہ آور کسی طرح لائٹ کلائنٹس کو ایک بدنیتی پر مبنی بلاک ہیڈر بھیجنے میں کامیاب ہو جاتا ہے اور انہیں اس بات پر قائل کر لیتا ہے کہ اس پر ایک ایماندار سنک-کمیٹی نے دستخط کیے تھے؟ اس صورت میں، حملہ آور غلط ٹرانزیکشنز شامل کر سکتا ہے اور لائٹ کلائنٹ انہیں آنکھیں بند کر کے قبول کر لے گا، کیونکہ وہ بلاک ہیڈر میں خلاصہ کردہ تمام اسٹیٹ تبدیلیوں کو آزادانہ طور پر چیک نہیں کرتے ہیں۔ اس سے بچنے کے لیے، لائٹ کلائنٹ فراڈ پروفس کا استعمال کر سکتا ہے۔ + +یہ فراڈ پروفس اس طرح کام کرتے ہیں کہ ایک مکمل نوڈ، نیٹ ورک کے ارد گرد ایک غلط اسٹیٹ ٹرانزیشن کو گاسپ ہوتے دیکھ کر، تیزی سے ڈیٹا کا ایک چھوٹا ٹکڑا تیار کر سکتا ہے جو یہ ظاہر کرتا ہے کہ ایک مجوزہ اسٹیٹ ٹرانزیشن ٹرانزیکشنز کے دیئے گئے سیٹ سے ممکنہ طور پر پیدا نہیں ہو سکتی اور اس ڈیٹا کو پیئرس تک براڈکاسٹ کر سکتا ہے۔ لائٹ نوڈس ان فراڈ-پروفس کو اٹھا سکتے ہیں اور انہیں خراب بلاک ہیڈرز کو مسترد کرنے کے لیے استعمال کر سکتے ہیں، اس بات کو یقینی بناتے ہوئے کہ وہ مکمل نوڈس کی طرح اسی ایماندار چین پر رہیں۔ + +یہ مکمل نوڈس کو مکمل ٹرانزیکشن ڈیٹا تک رسائی پر انحصار کرتا ہے۔ ایک حملہ آور جو ایک خراب بلاک ہیڈر کو براڈکاسٹ کرتا ہے اور ٹرانزیکشن ڈیٹا کو دستیاب کرانے میں بھی ناکام رہتا ہے وہ مکمل نوڈس کو فراڈ پروفس تیار کرنے سے روک سکے گا۔ مکمل نوڈس شاید ایک خراب بلاک کے بارے میں انتباہ کا اشارہ دے سکیں، لیکن وہ ثبوت کے ساتھ اپنے انتباہ کی پشت پناہی نہیں کر سکے، کیونکہ ثبوت تیار کرنے کے لیے ڈیٹا دستیاب نہیں کرایا گیا تھا! + +اس ڈیٹا کی دستیابی کے مسئلے کا حل DAS ہے۔ لائٹ نوڈس مکمل اسٹیٹ ڈیٹا کے بہت چھوٹے تصادفی حصے ڈاؤن لوڈ کرتے ہیں اور نمونوں کا استعمال اس بات کی تصدیق کے لیے کرتے ہیں کہ مکمل ڈیٹا سیٹ دستیاب ہے۔ N تصادفی حصوں کو ڈاؤن لوڈ کرنے کے بعد مکمل ڈیٹا کی دستیابی کو غلط طریقے سے فرض کرنے کا اصل امکان شمار کیا جا سکتا ہے ([100 حصوں کے لیے موقع 10^-30 ہے](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)، یعنی، ناقابل یقین حد تک غیر ممکن)۔ + +اس منظر نامے میں بھی، صرف چند بائٹس روکنے والے حملے تصادفی ڈیٹا کی درخواست کرنے والے کلائنٹس کی طرف سے ممکنہ طور پر نظر انداز ہو سکتے ہیں۔ ایریزر کوڈنگ ڈیٹا کے چھوٹے غائب ٹکڑوں کو دوبارہ بنا کر اسے ٹھیک کرتی ہے جن کا استعمال مجوزہ اسٹیٹ تبدیلیوں کو چیک کرنے کے لیے کیا جا سکتا ہے۔ اس کے بعد دوبارہ بنائے گئے ڈیٹا کا استعمال کرتے ہوئے ایک فراڈ پروف تیار کیا جا سکتا ہے، جس سے لائٹ نوڈس کو خراب ہیڈرز قبول کرنے سے روکا جا سکتا ہے۔ + +**نوٹ:** DAS اور فراڈ پروفس ابھی تک پروف-آف-اسٹیک ایتھیریم لائٹ کلائنٹس کے لیے نافذ نہیں کیے گئے ہیں، لیکن وہ روڈ میپ پر ہیں، زیادہ امکان ہے کہ وہ ZK-SNARK پر مبنی پروفس کی شکل اختیار کریں۔ آج کے لائٹ کلائنٹس DAC کی ایک شکل پر انحصار کرتے ہیں: وہ سنک-کمیٹی کی شناخت کی تصدیق کرتے ہیں اور پھر موصول ہونے والے دستخط شدہ بلاک ہیڈرز پر بھروسہ کرتے ہیں۔ + +## ڈیٹا کی دستیابی اور لیئر 2 رول اپس {#data-availability-and-layer-2-rollups} + +[لیئر 2 اسکیلنگ سلوشنز](/layer-2/)، جیسے [رول اپس](/glossary/#rollups)، آف چین ٹرانزیکشنز پر کارروائی کرکے ٹرانزیکشن کے اخراجات کو کم کرتے ہیں اور ایتھیریم کی تھرو پٹ میں اضافہ کرتے ہیں۔ رول اپ ٹرانزیکشنز کو کمپریس کیا جاتا ہے اور بیچوں میں ایتھیریم پر پوسٹ کیا جاتا ہے۔ بیچز ایتھیریم پر ایک ہی ٹرانزیکشن میں ہزاروں انفرادی آف چین ٹرانزیکشنز کی نمائندگی کرتے ہیں۔ یہ بیس لیئر پر بھیڑ کو کم کرتا ہے اور صارفین کے لیے فیس کو کم کرتا ہے۔ + +تاہم، ایتھیریم پر پوسٹ کی گئی 'خلاصہ' ٹرانزیکشنز پر بھروسہ کرنا صرف اس صورت میں ممکن ہے جب مجوزہ اسٹیٹ تبدیلی کو آزادانہ طور پر تصدیق کیا جا سکے اور اس بات کی تصدیق کی جا سکے کہ یہ تمام انفرادی آف چین ٹرانزیکشنز کو لاگو کرنے کا نتیجہ ہے۔ اگر رول اپ آپریٹرز اس تصدیق کے لیے ٹرانزیکشن ڈیٹا دستیاب نہیں کراتے ہیں، تو وہ ایتھیریم کو غلط ڈیٹا بھیج سکتے ہیں۔ + +[آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups/) کمپریسڈ ٹرانزیکشن ڈیٹا کو ایتھیریم پر پوسٹ کرتے ہیں اور کچھ وقت (عام طور پر 7 دن) انتظار کرتے ہیں تاکہ آزاد تصدیق کنندگان کو ڈیٹا چیک کرنے کی اجازت مل سکے۔ اگر کوئی کسی مسئلے کی نشاندہی کرتا ہے، تو وہ ایک فراڈ-پروف تیار کر سکتا ہے اور اسے رول اپ کو چیلنج کرنے کے لیے استعمال کر سکتا ہے۔ اس سے چین رول بیک ہو جائے گی اور غلط بلاک کو چھوڑ دیا جائے گا۔ یہ صرف اسی صورت میں ممکن ہے جب ڈیٹا دستیاب ہو۔ فی الحال، دو طریقے ہیں جن سے آپٹیمسٹک رول اپس ٹرانزیکشن ڈیٹا کو L1 پر پوسٹ کرتے ہیں۔ کچھ رول اپس ڈیٹا کو `CALLDATA` کے طور پر مستقل طور پر دستیاب کراتے ہیں جو مستقل طور پر آن چین رہتا ہے۔ EIP-4844 کے نفاذ کے ساتھ، کچھ رول اپس اس کے بجائے اپنے ٹرانزیکشن ڈیٹا کو سستے بلاب اسٹوریج پر پوسٹ کرتے ہیں۔ یہ مستقل اسٹوریج نہیں ہے۔ ایتھیریم لیئر-1 سے ڈیٹا حذف ہونے سے پہلے آزاد تصدیق کنندگان کو بلابز سے استفسار کرنا ہوگا اور ~18 دنوں کے اندر اپنے چیلنجز اٹھانے ہوں گے۔ ڈیٹا کی دستیابی کی ضمانت صرف ایتھیریم پروٹوکول کے ذریعے اس مختصر مقررہ ونڈو کے لیے دی جاتی ہے۔ اس کے بعد، یہ ایتھیریم ایکو سسٹم میں دیگر اداروں کی ذمہ داری بن جاتی ہے۔ کوئی بھی نوڈ DAS کا استعمال کرکے ڈیٹا کی دستیابی کی تصدیق کر سکتا ہے، یعنی، بلاب ڈیٹا کے چھوٹے، تصادفی نمونوں کو ڈاؤن لوڈ کرکے۔ + +[زیرو-نالج (ZK) رول اپس](/developers/docs/scaling/zk-rollups) کو ٹرانزیکشن ڈیٹا پوسٹ کرنے کی ضرورت نہیں ہے کیونکہ [زیرو-نالج ویلیڈیٹی پروفس](/glossary/#zk-proof) اسٹیٹ ٹرانزیشنز کی درستگی کی ضمانت دیتے ہیں۔ تاہم، ڈیٹا کی دستیابی اب بھی ایک مسئلہ ہے کیونکہ ہم ZK-رول اپ کی فعالیت (یا اس کے ساتھ تعامل) کی ضمانت اس کے اسٹیٹ ڈیٹا تک رسائی کے بغیر نہیں دے سکتے۔ مثال کے طور پر، اگر کوئی آپریٹر رول اپ کی اسٹیٹ کے بارے میں تفصیلات روک لیتا ہے تو صارفین اپنے بیلنس نہیں جان سکتے۔ اس کے علاوہ، وہ نئے شامل کردہ بلاک میں موجود معلومات کا استعمال کرتے ہوئے اسٹیٹ اپڈیٹس انجام نہیں دے سکتے ہیں۔ + +## ڈیٹا کی دستیابی بمقابلہ ڈیٹا کی بازیافت {#data-availability-vs-data-retrievability} + +ڈیٹا کی دستیابی ڈیٹا کی بازیافت سے مختلف ہے۔ ڈیٹا کی دستیابی اس بات کی یقین دہانی ہے کہ مکمل نوڈس کسی مخصوص بلاک سے وابستہ ٹرانزیکشنز کے مکمل سیٹ تک رسائی حاصل کرنے اور اس کی تصدیق کرنے میں کامیاب رہے ہیں۔ اس کا لازمی مطلب یہ نہیں ہے کہ ڈیٹا ہمیشہ کے لیے قابل رسائی ہے۔ + +ڈیٹا کی بازیافت نوڈس کی بلاک چین سے _تاریخی معلومات_ بازیافت کرنے کی صلاحیت ہے۔ یہ تاریخی ڈیٹا نئے بلاکس کی تصدیق کے لیے ضروری نہیں ہے، یہ صرف جینیسس بلاک سے مکمل نوڈس کو سنک کرنے یا مخصوص تاریخی درخواستوں کو پورا کرنے کے لیے درکار ہے۔ + +بنیادی ایتھیریم پروٹوکول بنیادی طور پر ڈیٹا کی دستیابی سے متعلق ہے، ڈیٹا کی بازیافت سے نہیں۔ ڈیٹا کی بازیافت تیسرے فریقوں کے ذریعے چلائے جانے والے آرکائیو نوڈس کی ایک چھوٹی آبادی کے ذریعے فراہم کی جا سکتی ہے، یا اسے [Portal Network](https://www.ethportal.net/) جیسے غیر مرکزی فائل اسٹوریج کا استعمال کرتے ہوئے پورے نیٹ ورک میں تقسیم کیا جا سکتا ہے۔ + +## مزید پڑھیں {#further-reading} + +- [ڈیٹا کی دستیابی کیا ہے؟](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [ڈیٹا کی دستیابی کیا ہے؟](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [ڈیٹا کی دستیابی کی جانچ پر ایک پرائمر](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [شارڈنگ + DAS تجویز کی وضاحت](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [ڈیٹا کی دستیابی اور ایریزر کوڈنگ پر ایک نوٹ](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [ڈیٹا کی دستیابی کی کمیٹیاں۔](https://medium.com/starkware/data-availability-e5564c416424) +- [پروف-آف-اسٹیک ڈیٹا کی دستیابی کی کمیٹیاں۔](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [ڈیٹا کی بازیافت کے مسئلے کے حل](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [ڈیٹا کی دستیابی یا: رول اپس نے پریشان ہونا چھوڑ کر ایتھیریم سے محبت کرنا کیسے سیکھا](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: Calldata کی لاگت میں اضافہ](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..5aa2be3dba5 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "ڈیٹا کی ساختیں اور انکوڈنگ" +description: "بنیادی Ethereum ڈیٹا کی ساختوں کا ایک جائزہ۔" +lang: ur-in +sidebarDepth: 2 +--- + +Ethereum بڑی مقدار میں ڈیٹا بناتا، ذخیرہ کرتا اور منتقل کرتا ہے۔ اس ڈیٹا کو معیاری اور میموری کے موافق طریقوں سے فارمیٹ کیا جانا چاہیے تاکہ کسی کو بھی نسبتاً معمولی کنزیومر گریڈ ہارڈویئر پر [ایک نوڈ چلانے](/run-a-node/) کی اجازت دی جا سکے۔ اس کو حاصل کرنے کے لیے، Ethereum اسٹیک پر کئی مخصوص ڈیٹا کی ساختیں استعمال کی جاتی ہیں۔ + +## شرائط {#prerequisites} + +آپ کو Ethereum کی بنیادی باتوں اور [کلائنٹ سافٹ ویئر](/developers/docs/nodes-and-clients/) کو سمجھنا چاہیے۔ نیٹ ورکنگ لیئر اور [Ethereum وائٹ پیپر](/whitepaper/) سے واقفیت کی سفارش کی جاتی ہے۔ + +## ڈیٹا کی ساختیں {#data-structures} + +### Patricia merkle tries {#patricia-merkle-tries} + +Patricia Merkle Tries ایسی ساختیں ہیں جو کلیدی-ویلیو کے جوڑوں کو ایک ڈیٹرمنسٹک اور کرپٹوگرافک طور پر مستند trie میں انکوڈ کرتی ہیں۔ یہ Ethereum کی ایگزیکیوشن لیئر میں بڑے پیمانے پر استعمال ہوتے ہیں۔ + +[Patricia Merkle Tries کے بارے میں مزید](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Recursive Length Prefix {#recursive-length-prefix} + +Recursive Length Prefix (RLP) ایک سیریلائزیشن طریقہ ہے جو Ethereum کی ایگزیکیوشن لیئر میں بڑے پیمانے پر استعمال ہوتا ہے۔ + +[RLP کے بارے میں مزید](/developers/docs/data-structures-and-encoding/rlp) + +### Simple Serialize {#simple-serialize} + +Simple Serialize (SSZ) Ethereum کی کنسینسس لیئر پر ایک غالب سیریلائزیشن فارمیٹ ہے کیونکہ یہ merklelization کے ساتھ مطابقت رکھتا ہے۔ + +[SSZ کے بارے میں مزید](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..79875007f1e --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: "مرکل پیٹریشیا ٹرائی" +description: "مرکل پیٹریشیا ٹرائی کا تعارف۔" +lang: ur-in +sidebarDepth: 2 +--- + +ایتھیریم کی اسٹیٹ (تمام اکاؤنٹس، بیلنس، اور اسمارٹ کنٹریکٹس کا مجموعہ)، کو ڈیٹا اسٹرکچر کے ایک خاص ورژن میں انکوڈ کیا جاتا ہے جسے عام طور پر کمپیوٹر سائنس میں مرکل ٹری کہا جاتا ہے۔ یہ اسٹرکچر کرپٹوگرافی میں بہت سی ایپلی کیشنز کے لیے مفید ہے کیونکہ یہ ٹری میں الجھے ہوئے ڈیٹا کے تمام انفرادی ٹکڑوں کے درمیان ایک قابلِ تصدیق تعلق پیدا کرتا ہے، جس کے نتیجے میں ایک واحد **روٹ** ویلیو حاصل ہوتی ہے جسے ڈیٹا کے بارے میں چیزوں کو ثابت کرنے کے لیے استعمال کیا جا سکتا ہے۔ + +ایتھیریم کا ڈیٹا اسٹرکچر ایک 'موڈیفائیڈ مرکل-پیٹریشیا ٹرائی' ہے، جسے یہ نام اس لیے دیا گیا ہے کیونکہ یہ PATRICIA (پریکٹیکل الگورتھم ٹو ریٹریو انفارمیشن کوڈڈ ان ایلفانیومرک) کی کچھ خصوصیات مستعار لیتا ہے، اور کیونکہ اسے ایتھیریم اسٹیٹ پر مشتمل آئٹمز کی موثر ڈیٹا ری**ٹری**ول کے لیے ڈیزائن کیا گیا ہے۔ + +ایک مرکل-پیٹریشیا ٹرائی ڈیٹرمنسٹک اور کرپٹوگرافک طور پر قابلِ تصدیق ہے: اسٹیٹ روٹ بنانے کا واحد طریقہ اسے اسٹیٹ کے ہر انفرادی ٹکڑے سے کمپیوٹ کرنا ہے، اور دو اسٹیٹس جو ایک جیسی ہیں، ان کو روٹ ہیش اور ان ہیشز کا موازنہ کر کے آسانی سے ثابت کیا جا سکتا ہے جنہوں نے اسے بنایا (_ایک مرکل پروف_)۔ اس کے برعکس، ایک ہی روٹ ہیش کے ساتھ دو مختلف اسٹیٹس بنانے کا کوئی طریقہ نہیں ہے، اور مختلف ویلیوز کے ساتھ اسٹیٹ میں ترمیم کرنے کی کوئی بھی کوشش ایک مختلف اسٹیٹ روٹ ہیش کا باعث بنے گی۔ نظریاتی طور پر، یہ اسٹرکچر انسرٹس، لک اپس اور ڈیلیٹس کے لیے `O(log(n))` کی کارکردگی کا 'ہولی گریل' فراہم کرتا ہے۔ + +مستقبل قریب میں، ایتھیریم ایک [ورکل ٹری](/roadmap/verkle-trees) اسٹرکچر میں منتقل ہونے کا ارادہ رکھتا ہے، جو مستقبل میں پروٹوکول میں بہتری کے لیے بہت سے نئے امکانات کھولے گا۔ + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، [ہیشز](https://en.wikipedia.org/wiki/Hash_function)، [مرکل ٹریز](https://en.wikipedia.org/wiki/Merkle_tree)، [ٹرائیز](https://en.wikipedia.org/wiki/Trie) اور [سیریلائزیشن](https://en.wikipedia.org/wiki/Serialization) کا بنیادی علم ہونا مددگار ثابت ہوگا۔ یہ مضمون ایک بنیادی [ریڈکس ٹری](https://en.wikipedia.org/wiki/Radix_tree) کی تفصیل سے شروع ہوتا ہے، پھر آہستہ آہستہ ایتھیریم کے زیادہ آپٹمائزڈ ڈیٹا اسٹرکچر کے لیے ضروری ترمیمات کا تعارف کراتا ہے۔ + +## بنیادی ریڈکس ٹرائیز {#basic-radix-tries} + +ایک بنیادی ریڈکس ٹرائی میں، ہر نوڈ اس طرح نظر آتا ہے: + +``` + [i_0, i_1 ... i_n, value] +``` + +جہاں `i_0 ...` `i_n` حروف تہجی کی علامتوں (اکثر بائنری یا ہیکس) کی نمائندگی کرتے ہیں، `value` نوڈ پر ٹرمینل ویلیو ہے، اور `i_0، i_1 ...` میں موجود ویلیوز `i_n` سلاٹس یا تو `NULL` ہیں یا دوسرے نوڈس کے پوائنٹرز (ہمارے معاملے میں، ہیشز) ہیں۔ یہ ایک بنیادی `(key, value)` اسٹور بناتا ہے۔ + +فرض کریں کہ آپ کلیدی ویلیو پیئرز کے ایک سیٹ پر ایک آرڈر کو برقرار رکھنے کے لیے ریڈکس ٹری ڈیٹا اسٹرکچر کا استعمال کرنا چاہتے ہیں۔ ٹرائی میں کلید `dog` سے فی الحال میپ شدہ ویلیو تلاش کرنے کے لیے، آپ پہلے `dog` کو حروف تہجی کے حروف میں تبدیل کریں گے (جو `64 6f 67` دے گا)، اور پھر اس راستے پر چلتے ہوئے ٹرائی میں نیچے جائیں گے جب تک کہ آپ کو ویلیو نہ مل جائے۔ یعنی، آپ ٹرائی کے روٹ نوڈ کو تلاش کرنے کے لیے ایک فلیٹ کی/ویلیو DB میں روٹ ہیش کو دیکھ کر شروع کرتے ہیں۔ اسے دوسرے نوڈس کی طرف اشارہ کرنے والی کلیدوں کی ایک صف کے طور پر ظاہر کیا جاتا ہے۔ آپ انڈیکس `6` پر موجود ویلیو کو ایک کلید کے طور پر استعمال کریں گے اور اسے فلیٹ کی/ویلیو DB میں دیکھیں گے تاکہ ایک لیول نیچے نوڈ حاصل کیا جا سکے۔ پھر اگلی ویلیو دیکھنے کے لیے انڈیکس `4` چنیں، پھر انڈیکس `6`، اور اسی طرح، جب تک کہ آپ اس راستے پر نہ چلیں: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`، آپ نوڈ کی ویلیو دیکھیں گے اور نتیجہ واپس کر دیں گے۔ + +'ٹرائی' اور بنیادی فلیٹ کی/ویلیو 'DB' میں کسی چیز کو تلاش کرنے میں فرق ہے۔ یہ دونوں کی/ویلیو انتظامات کی وضاحت کرتے ہیں، لیکن بنیادی DB ایک کلید کا روایتی 1 قدمی لک اپ کر سکتا ہے۔ ٹرائی میں ایک کلید کو تلاش کرنے کے لیے اوپر بیان کردہ حتمی ویلیو تک پہنچنے کے لیے متعدد بنیادی DB لک اپس کی ضرورت ہوتی ہے۔ آئیے ابہام کو ختم کرنے کے لیے بعد والے کو `path` کے طور پر حوالہ دیں۔ + +ریڈکس ٹرائیز کے لیے اپ ڈیٹ اور ڈیلیٹ آپریشنز کی وضاحت اس طرح کی جا سکتی ہے: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 + newnode = curnode.copy() + if path == "": + newnode[-1] = value + else: + newindex = update(curnode[path[0]], path[1:], value) + newnode[path[0]] = newindex + db.put(hash(newnode), newnode) + return hash(newnode) + + def delete(node_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + newnode = curnode.copy() + if path == "": + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]], path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode), newnode) + return hash(newnode) +``` + +ایک "مرکل" ریڈکس ٹری ڈیٹرمنسٹک طور پر تیار کردہ کرپٹوگرافک ہیش ڈائجسٹ کا استعمال کرتے ہوئے نوڈس کو جوڑ کر بنایا جاتا ہے۔ یہ مواد-ایڈریسنگ (کی/ویلیو DB `key == keccak256(rlp(value))` میں) ذخیرہ شدہ ڈیٹا کی کرپٹوگرافک سالمیت کی گارنٹی فراہم کرتا ہے۔ اگر کسی دیے گئے ٹرائی کا روٹ ہیش عوامی طور پر معلوم ہے، تو کوئی بھی شخص جس کے پاس بنیادی لیف ڈیٹا تک رسائی ہو، وہ اس بات کا ثبوت بنا سکتا ہے کہ ٹرائی میں ایک مخصوص راستے پر ایک دی گئی ویلیو شامل ہے، جس کے لیے وہ ہر نوڈ کے ہیشز فراہم کرے گا جو ایک مخصوص ویلیو کو ٹری روٹ سے جوڑتا ہے۔ + +ایک حملہ آور کے لیے `(path, value)` جوڑے کا ثبوت فراہم کرنا ناممکن ہے جو موجود نہیں ہے کیونکہ روٹ ہیش بالآخر اس کے نیچے کے تمام ہیشز پر مبنی ہے۔ کوئی بھی بنیادی ترمیم روٹ ہیش کو بدل دے گی۔ آپ ہیش کو ڈیٹا کے بارے میں ساختی معلومات کی ایک کمپریسڈ نمائندگی کے طور پر سوچ سکتے ہیں، جو ہیشنگ فنکشن کے پری-امیج تحفظ کے ذریعے محفوظ ہے۔ + +ہم ریڈکس ٹری کی ایک اٹامک اکائی (مثلاً، ایک واحد ہیکس کریکٹر، یا 4 بٹ بائنری نمبر) کو "نبل" کہیں گے۔ جیسا کہ اوپر بیان کیا گیا ہے، ایک وقت میں ایک نبل کے راستے پر چلتے ہوئے، نوڈس زیادہ سے زیادہ 16 بچوں کا حوالہ دے سکتے ہیں لیکن ایک `value` عنصر شامل کرتے ہیں۔ لہذا، ہم انہیں 17 کی لمبائی والی ایک صف کے طور پر ظاہر کرتے ہیں۔ ہم ان 17-عناصر والی صفوں کو "برانچ نوڈس" کہتے ہیں۔ + +## مرکل پیٹریشیا ٹرائی {#merkle-patricia-trees} + +ریڈکس ٹرائیز کی ایک بڑی حد ہے: وہ غیر موثر ہیں۔ اگر آپ ایک `(path, value)` بائنڈنگ کو ذخیرہ کرنا چاہتے ہیں جہاں پاتھ، جیسا کہ ایتھیریم میں ہے، 64 حروف لمبا ہے (`bytes32` میں نبلز کی تعداد)، تو ہمیں فی کریکٹر ایک لیول کو ذخیرہ کرنے کے لیے ایک کلو بائٹ سے زیادہ اضافی جگہ کی ضرورت ہوگی، اور ہر لک اپ یا ڈیلیٹ میں پورے 64 مراحل لگیں گے۔ درج ذیل میں متعارف کرایا گیا پیٹریشیا ٹرائی اس مسئلے کو حل کرتا ہے۔ + +### آپٹمائزیشن {#optimization} + +مرکل پیٹریشیا ٹرائی میں ایک نوڈ درج ذیل میں سے ایک ہے: + +1. `NULL` (خالی اسٹرنگ کے طور پر ظاہر کیا جاتا ہے) +2. `branch` ایک 17 آئٹم والا نوڈ `[ v0 ...` v15, vt ]` +3. `leaf` ایک 2 آئٹم والا نوڈ `[ encodedPath, value ]` +4. `extension` ایک 2 آئٹم والا نوڈ `[ encodedPath, key ]` + +64 کریکٹر پاتھس کے ساتھ یہ ناگزیر ہے کہ ٹرائی کی پہلی چند لیئرز کو عبور کرنے کے بعد، آپ ایک ایسے نوڈ پر پہنچ جائیں گے جہاں نیچے کے راستے کے کم از کم ایک حصے کے لیے کوئی مختلف راستہ موجود نہیں ہے۔ راستے میں 15 تک اسپارس `NULL` نوڈز بنانے سے بچنے کے لیے، ہم `[ encodedPath, key ]` کی شکل کا ایک `extension` نوڈ قائم کر کے نزول کو شارٹ کٹ کرتے ہیں، جہاں `encodedPath` آگے بڑھنے کے لیے "جزوی راستہ" پر مشتمل ہے (نیچے بیان کردہ ایک کمپیکٹ انکوڈنگ کا استعمال کرتے ہوئے)، اور `key` اگلے DB لک اپ کے لیے ہے۔ + +`leaf` نوڈ کے لیے، جسے `encodedPath` کے پہلے نبل میں ایک فلیگ کے ذریعے نشان زد کیا جا سکتا ہے، پاتھ تمام پچھلے نوڈ کے پاتھ کے ٹکڑوں کو انکوڈ کرتا ہے اور ہم براہ راست `value` کو دیکھ سکتے ہیں۔ + +تاہم، یہ مذکورہ بالا آپٹمائزیشن ابہام پیدا کرتی ہے۔ + +نبلز میں راستوں کو عبور کرتے وقت، ہمارے پاس عبور کرنے کے لیے نبلز کی ایک طاق تعداد ہو سکتی ہے، لیکن چونکہ تمام ڈیٹا `bytes` فارمیٹ میں ذخیرہ ہوتا ہے۔ مثال کے طور پر، نبل `1`، اور نبلز `01` کے درمیان فرق کرنا ممکن نہیں ہے (دونوں کو `<01>` کے طور پر ذخیرہ کیا جانا چاہیے)۔ طاق لمبائی کی وضاحت کرنے کے لیے، جزوی راستے کو ایک فلیگ کے ساتھ سابقہ لگایا جاتا ہے۔ + +### تفصیلات: اختیاری ٹرمینیٹر کے ساتھ ہیکس ترتیب کی کمپیکٹ انکوڈنگ {#specification} + +جیسا کہ اوپر بیان کیا گیا ہے، _طاق بمقابلہ جفت بقیہ جزوی پاتھ کی لمبائی_ اور _لیف بمقابلہ ایکسٹینشن نوڈ_ دونوں کی فلیگنگ کسی بھی 2-آئٹم نوڈ کے جزوی پاتھ کے پہلے نبل میں ہوتی ہے۔ ان کے نتیجے میں درج ذیل ہوتا ہے: + +| ہیکس کریکٹر | بٹس | نوڈ کی قسم جزوی | پاتھ کی لمبائی | +| ----------- | ---- | ---------------------------------- | -------------- | +| 0 | 0000 | ایکسٹینشن | جفت | +| 1 | 0001 | ایکسٹینشن | طاق | +| 2 | 0010 | ٹرمینیٹنگ (لیف) | جفت | +| 3 | 0011 | ٹرمینیٹنگ (لیف) | طاق | + +جفت بقیہ پاتھ کی لمبائی (`0` یا `2`) کے لیے، ایک اور `0` "پیڈنگ" نبل ہمیشہ پیچھے آئے گا۔ + +```python + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: + hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + # hexarray کی اب ایک جفت لمبائی ہے جس کا پہلا نبل فلیگز ہے۔ + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +مثالیں: + +```python + > [1, 2, 3, 4, 5, ...] + '11 23 45' + > [0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +مرکل پیٹریشیا ٹرائی میں ایک نوڈ حاصل کرنے کے لیے یہاں توسیع شدہ کوڈ ہے: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) + else: + return "" + elif len(curnode) == 17: + return get_helper(curnode[path[0]], path[1:]) + + def get(node_hash, path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node_hash, path2) +``` + +### مثالی ٹرائی {#example-trie} + +فرض کریں کہ ہم ایک ایسی ٹرائی چاہتے ہیں جس میں چار پاتھ/ویلیو جوڑے ہوں `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`۔ + +سب سے پہلے، ہم پاتھس اور ویلیوز دونوں کو `bytes` میں تبدیل کرتے ہیں۔ نیچے، _پاتھس_ کے لیے اصل بائٹ کی نمائندگی `<>` سے کی گئی ہے، حالانکہ _ویلیوز_ کو اب بھی اسٹرنگز کے طور پر دکھایا گیا ہے، جسے `''` سے ظاہر کیا گیا ہے، تاکہ سمجھنے میں آسانی ہو (وہ بھی، دراصل `bytes` ہوں گے): + +``` + <64 6f> : 'verb' + <64 6f 67> : 'puppy' + <64 6f 67 65> : 'coins' + <68 6f 72 73 65> : 'stallion' +``` + +اب، ہم بنیادی DB میں درج ذیل کی/ویلیو جوڑوں کے ساتھ ایسی ٹرائی بناتے ہیں: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +جب ایک نوڈ کا حوالہ دوسرے نوڈ کے اندر دیا جاتا ہے، تو جو چیز شامل کی جاتی ہے وہ `keccak256(rlp.encode(node))` ہے، اگر `len(rlp.encode(node)) >= 32` ورنہ `node` جہاں `rlp.encode` [RLP](/developers/docs/data-structures-and-encoding/rlp) انکوڈنگ فنکشن ہے۔ + +نوٹ کریں کہ ٹرائی کو اپ ڈیٹ کرتے وقت، کسی کو کی/ویلیو جوڑا `(keccak256(x), x)` کو ایک مستقل لک اپ ٹیبل میں ذخیرہ کرنے کی ضرورت ہے _اگر_ نئے بنائے گئے نوڈ کی لمبائی >= 32 ہے۔ تاہم، اگر نوڈ اس سے چھوٹا ہے، تو کسی کو کچھ بھی ذخیرہ کرنے کی ضرورت نہیں ہے، کیونکہ فنکشن f(x) = x قابلِ واپسی ہے۔ + +## ایتھیریم میں ٹرائیز {#tries-in-ethereum} + +ایتھیریم کی ایگزیکیوشن لیئر میں تمام مرکل ٹرائیز ایک مرکل پیٹریشیا ٹرائی کا استعمال کرتی ہیں۔ + +ایک بلاک ہیڈر سے ان 3 ٹرائیز کے 3 روٹس ہوتے ہیں۔ + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### اسٹیٹ ٹرائی {#state-trie} + +ایک عالمی اسٹیٹ ٹرائی ہے، اور جب بھی کوئی کلائنٹ کسی بلاک پر کارروائی کرتا ہے تو اسے اپ ڈیٹ کیا جاتا ہے۔ اس میں، ایک `path` ہمیشہ ہوتا ہے: `keccak256(ethereumAddress)` اور ایک `value` ہمیشہ ہوتی ہے: `rlp(ethereumAccount)`۔ مزید خاص طور پر ایک ایتھیریم `account` ایک 4 آئٹم کی صف ہے `[nonce,balance,storageRoot,codeHash]`۔ اس مقام پر، یہ بات قابل غور ہے کہ یہ `storageRoot` ایک اور پیٹریشیا ٹرائی کا روٹ ہے: + +### اسٹوریج ٹرائی {#storage-trie} + +اسٹوریج ٹرائی وہ جگہ ہے جہاں _تمام_ کنٹریکٹ ڈیٹا رہتا ہے۔ ہر اکاؤنٹ کے لیے ایک الگ اسٹوریج ٹرائی ہوتی ہے۔ کسی دیے گئے ایڈریس پر مخصوص اسٹوریج پوزیشنز پر ویلیوز کو بازیافت کرنے کے لیے اسٹوریج ایڈریس، اسٹوریج میں ذخیرہ شدہ ڈیٹا کی انٹیجر پوزیشن، اور بلاک آئی ڈی کی ضرورت ہوتی ہے۔ اس کے بعد انہیں JSON-RPC API میں بیان کردہ `eth_getStorageAt` میں آرگیومنٹس کے طور پر پاس کیا جا سکتا ہے، مثلاً، ایڈریس `0x295a70b2de5e3953354a6a8344e616ed314d7251` کے لیے اسٹوریج سلاٹ 0 میں ڈیٹا بازیافت کرنے کے لیے: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +اسٹوریج میں دیگر عناصر کو بازیافت کرنا قدرے زیادہ پیچیدہ ہے کیونکہ اسٹوریج ٹرائی میں پوزیشن کا پہلے حساب لگانا ضروری ہے۔ پوزیشن کا حساب ایڈریس اور اسٹوریج پوزیشن کے `keccak256` ہیش کے طور پر کیا جاتا ہے، دونوں کو 32 بائٹس کی لمبائی تک صفر کے ساتھ بائیں طرف پیڈ کیا جاتا ہے۔ مثال کے طور پر، ایڈریس `0x391694e7e0b0cce554cb130d723a9d27458f9298` کے لیے اسٹوریج سلاٹ 1 میں ڈیٹا کی پوزیشن یہ ہے: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +Geth کنسول میں، اس کا حساب اس طرح کیا جا سکتا ہے: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +`path` اس لیے `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` ہے۔ اب اسے پہلے کی طرح اسٹوریج ٹرائی سے ڈیٹا بازیافت کرنے کے لیے استعمال کیا جا سکتا ہے: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +نوٹ: ایتھیریم اکاؤنٹ کے لیے `storageRoot` پہلے سے خالی ہوتا ہے اگر یہ کوئی کنٹریکٹ اکاؤنٹ نہ ہو۔ + +### ٹرانزیکشنز ٹرائی {#transaction-trie} + +ہر بلاک کے لیے ایک الگ ٹرانزیکشنز ٹرائی ہوتی ہے، جو دوبارہ `(key, value)` جوڑوں کو ذخیرہ کرتی ہے۔ یہاں ایک پاتھ ہے: `rlp(transactionIndex)` جو اس کلید کی نمائندگی کرتا ہے جو اس کے ذریعے طے شدہ ویلیو کے مساوی ہے: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +اس بارے میں مزید معلومات [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) ڈاکومنٹیشن میں مل سکتی ہیں۔ + +### رسیدوں کی ٹرائی {#receipts-trie} + +ہر بلاک کی اپنی رسیدوں کی ٹرائی ہوتی ہے۔ یہاں ایک `path` ہے: `rlp(transactionIndex)`۔ `transactionIndex` اس بلاک کے اندر اس کا انڈیکس ہے جس میں اسے شامل کیا گیا تھا۔ رسیدوں کی ٹرائی کو کبھی اپ ڈیٹ نہیں کیا جاتا۔ ٹرانزیکشنز ٹرائی کی طرح، موجودہ اور لیگیسی رسیدیں ہیں۔ رسیدوں کی ٹرائی میں ایک مخصوص رسید کو استفسار کرنے کے لیے، اس کے بلاک میں ٹرانزیکشن کا انڈیکس، رسید کا پے لوڈ اور ٹرانزیکشن کی قسم درکار ہے۔ واپس کی گئی رسید `Receipt` قسم کی ہو سکتی ہے جس کی تعریف `TransactionType` اور `ReceiptPayload` کے جوڑ کے طور پر کی گئی ہے یا یہ `LegacyReceipt` قسم کی ہو سکتی ہے جس کی تعریف `rlp([status, cumulativeGasUsed, logsBloom, logs])` کے طور پر کی گئی ہے۔ + +اس بارے میں مزید معلومات [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) ڈاکومنٹیشن میں مل سکتی ہیں۔ + +## مزید مطالعہ {#further-reading} + +- [موڈیفائیڈ مرکل پیٹریشیا ٹرائی — ایتھیریم اسٹیٹ کو کیسے بچاتا ہے](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [ایتھیریم میں مرکلنگ](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [ایتھیریم ٹرائی کو سمجھنا](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..c9f8faaf378 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: "ریکرسیو-لینتھ پریفکس (RLP) سیریلائزیشن" +description: "Ethereum کی ایگزیکیوشن لیئر میں rlp انکوڈنگ کی ایک تعریف۔" +lang: ur-in +sidebarDepth: 2 +--- + +ریکرسیو لینتھ پریفکس (RLP) سیریلائزیشن کا استعمال Ethereum کے ایگزیکیوشن کلائنٹس میں بڑے پیمانے پر کیا جاتا ہے۔ RLP نوڈز کے درمیان ڈیٹا کی منتقلی کو ایک اسپیس-ایفیشینٹ فارمیٹ میں معیاری بناتا ہے۔ RLP کا مقصد بائنری ڈیٹا کی من مانی طور پر نیسٹڈ اریز کو انکوڈ کرنا ہے، اور RLP Ethereum کی ایگزیکیوشن لیئر میں آبجیکٹس کو سیریلائز کرنے کے لیے استعمال ہونے والا بنیادی انکوڈنگ طریقہ ہے۔ RLP کا بنیادی مقصد اسٹرکچر کو انکوڈ کرنا ہے؛ مثبت انٹیجرز کے علاوہ، RLP مخصوص ڈیٹا کی اقسام (مثلاً، سٹرنگز، فلوٹس) کی انکوڈنگ کو ہائیر-آرڈر پروٹوکولز کو تفویض کرتا ہے۔ مثبت انٹیجرز کی نمائندگی بگ-اینڈین بائنری فارم میں بغیر کسی لیڈنگ زیرو کے کی جانی چاہئے (اس طرح انٹیجر ویلیو صفر کو خالی بائٹ اری کے برابر بناتا ہے)۔ لیڈنگ زیرو والے ڈی سیریلائزڈ مثبت انٹیجرز کو RLP استعمال کرنے والے کسی بھی ہائیر-آرڈر پروٹوکول کے ذریعہ غلط سمجھا جانا چاہئے۔ + +مزید معلومات [ایتھیریم ییلو پیپر (اپینڈکس B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19) میں۔ + +ایک ڈکشنری کو انکوڈ کرنے کے لئے RLP کا استعمال کرنے کے لئے، دو تجویز کردہ کینونیکل فارمز ہیں: + +- `[[k1,v1],[k2,v2]...]` کا استعمال کریں جس میں کیز لیکسیکوگرافک آرڈر میں ہوں۔ +- ہائیر-لیول پیٹریشیا ٹری انکوڈنگ کا استعمال کریں جیسا کہ Ethereum کرتا ہے۔ + +## تعریف {#definition} + +RLP انکوڈنگ فنکشن ایک آئٹم لیتا ہے۔ ایک آئٹم کی تعریف اس طرح ہے: + +- ایک سٹرنگ (یعنی بائٹ اری) ایک آئٹم ہے +- آئٹمز کی ایک لسٹ ایک آئٹم ہے +- ایک مثبت انٹیجر ایک آئٹم ہے + +مثال کے طور پر، مندرجہ ذیل تمام آئٹمز ہیں: + +- ایک خالی سٹرنگ؛ +- لفظ "cat" پر مشتمل سٹرنگ؛ +- کسی بھی تعداد میں سٹرنگز پر مشتمل ایک لسٹ؛ +- اور مزید پیچیدہ ڈیٹا اسٹرکچرز جیسے `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`۔ +- نمبر `100` + +نوٹ کریں کہ اس صفحے کے باقی حصے کے سیاق و سباق میں، 'سٹرنگ' کا مطلب ہے "بائنری ڈیٹا کے بائٹس کی ایک خاص تعداد"؛ کوئی خاص انکوڈنگ استعمال نہیں کی جاتی ہے، اور سٹرنگز کے مواد کے بارے میں کسی علم کا مطلب نہیں ہے (سوائے اس کے کہ غیر کم از کم مثبت انٹیجرز کے خلاف اصول کے مطابق ضرورت ہو)۔ + +RLP انکوڈنگ کی تعریف اس طرح ہے: + +- ایک مثبت انٹیجر کے لیے، اسے سب سے چھوٹی بائٹ اری میں تبدیل کیا جاتا ہے جس کی بگ-اینڈین تشریح انٹیجر ہے، اور پھر نیچے دیے گئے اصولوں کے مطابق ایک سٹرنگ کے طور پر انکوڈ کیا جاتا ہے۔ +- ایک واحد بائٹ کے لیے جس کی ویلیو `[0x00, 0x7f]` (ڈیسیمل `[0, 127]`) رینج میں ہے، وہ بائٹ خود اس کی RLP انکوڈنگ ہے۔ +- بصورت دیگر، اگر کوئی سٹرنگ 0-55 بائٹس لمبی ہے، تو RLP انکوڈنگ ایک واحد بائٹ پر مشتمل ہوتی ہے جس کی ویلیو **0x80** (ڈیسیمل 128) ہوتی ہے، اور اس کے بعد سٹرنگ کی لمبائی اور پھر سٹرنگ آتی ہے۔ اس طرح پہلے بائٹ کی رینج `[0x80, 0xb7]` (ڈیسیمل `[128, 183]`) ہے۔ +- اگر کوئی سٹرنگ 55 بائٹس سے زیادہ لمبی ہے، تو RLP انکوڈنگ **0xb7** (ڈیسیمل 183) کی ویلیو کے ساتھ ایک واحد بائٹ پر مشتمل ہوتی ہے، اور اس کے بعد بائنری فارم میں سٹرنگ کی لمبائی کی بائٹس میں لمبائی، پھر سٹرنگ کی لمبائی، اور پھر سٹرنگ آتی ہے۔ مثال کے طور پر، ایک 1024 بائٹ لمبی سٹرنگ کو `\xb9\x04\x00` (ڈیسیمل `185, 4, 0`) کے طور پر انکوڈ کیا جائے گا جس کے بعد سٹرنگ آئے گی۔ یہاں، `0xb9` (183 + 2 = 185) پہلے بائٹ کے طور پر ہے، جس کے بعد 2 بائٹس `0x0400` (ڈیسیمل 1024) آتے ہیں جو اصل سٹرنگ کی لمبائی کو ظاہر کرتے ہیں۔ اس طرح پہلے بائٹ کی رینج `[0xb8, 0xbf]` (ڈیسیمل `[184, 191]`) ہے۔ +- اگر کوئی سٹرنگ 2^64 بائٹس لمبی، یا اس سے زیادہ لمبی ہے، تو اسے انکوڈ نہیں کیا جا سکتا۔ +- اگر کسی لسٹ کا کل پے لوڈ (یعنی، اس کے تمام آئٹمز کی مشترکہ لمبائی جنہیں RLP انکوڈ کیا جا رہا ہے) 0-55 بائٹس لمبا ہے، تو RLP انکوڈنگ **0xc0** کی ویلیو کے ساتھ ایک واحد بائٹ پر مشتمل ہوتی ہے، اور اس کے بعد پے لوڈ کی لمبائی اور پھر آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن آتا ہے۔ اس طرح پہلے بائٹ کی رینج `[0xc0, 0xf7]` (ڈیسیمل `[192, 247]`) ہے۔ +- اگر کسی لسٹ کا کل پے لوڈ 55 بائٹس سے زیادہ لمبا ہے، تو RLP انکوڈنگ **0xf7** کی ویلیو کے ساتھ ایک واحد بائٹ پر مشتمل ہوتی ہے، اور اس کے بعد بائنری فارم میں پے لوڈ کی لمبائی کی بائٹس میں لمبائی، پھر پے لوڈ کی لمبائی، اور پھر آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن آتا ہے۔ اس طرح پہلے بائٹ کی رینج `[0xf8, 0xff]` (ڈیسیمل `[248, 255]`) ہے۔ + +کوڈ میں، یہ ہے: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("input too long") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## مثالیں {#examples} + +- سٹرنگ "dog" = [ 0x83, 'd', 'o', 'g' ] +- لسٹ [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- خالی سٹرنگ ('null') = `[ 0x80 ]` +- خالی لسٹ = `[ 0xc0 ]` +- انٹیجر 0 = `[ 0x80 ]` +- بائٹ '\\x00' = `[ 0x00 ]` +- بائٹ '\\x0f' = `[ 0x0f ]` +- بائٹس '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- تین کی [سیٹ تھیوریٹیکل نمائندگی](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers)، `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- سٹرنگ "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` `, 'e', 'l', 'i', 't' ]` + +## RLP ڈی کوڈنگ {#rlp-decoding} + +RLP انکوڈنگ کے اصولوں اور عمل کے مطابق، RLP ڈی کوڈ کے ان پٹ کو بائنری ڈیٹا کا ایک اری سمجھا جاتا ہے۔ RLP ڈی کوڈنگ کا عمل اس طرح ہے: + +1. ان پٹ ڈیٹا کے پہلے بائٹ (یعنی پریفکس) کے مطابق ڈیٹا کی قسم، اصل ڈیٹا کی لمبائی اور آفسیٹ کو ڈی کوڈ کرنا؛ + +2. ڈیٹا کی قسم اور آفسیٹ کے مطابق، ڈیٹا کو اسی کے مطابق ڈی کوڈ کریں، مثبت انٹیجرز کے لئے کم از کم انکوڈنگ کے اصول کا احترام کرتے ہوئے؛ + +3. باقی ان پٹ کو ڈی کوڈ کرنا جاری رکھیں؛ + +ان میں سے، ڈیٹا کی اقسام اور آفسیٹ کو ڈی کوڈ کرنے کے اصول اس طرح ہیں: + +1. ڈیٹا ایک سٹرنگ ہے اگر پہلے بائٹ (یعنی پریفکس) کی رینج [0x00, 0x7f] ہے، اور سٹرنگ خود بالکل پہلا بائٹ ہے؛ + +2. ڈیٹا ایک سٹرنگ ہے اگر پہلے بائٹ کی رینج [0x80, 0xb7] ہے، اور وہ سٹرنگ جس کی لمبائی پہلے بائٹ مائنس 0x80 کے برابر ہے پہلے بائٹ کے بعد آتی ہے؛ + +3. ڈیٹا ایک سٹرنگ ہے اگر پہلے بائٹ کی رینج [0xb8, 0xbf] ہے، اور سٹرنگ کی لمبائی جس کی بائٹس میں لمبائی پہلے بائٹ مائنس 0xb7 کے برابر ہے پہلے بائٹ کے بعد آتی ہے، اور سٹرنگ، سٹرنگ کی لمبائی کے بعد آتی ہے؛ + +4. ڈیٹا ایک لسٹ ہے اگر پہلے بائٹ کی رینج [0xc0, 0xf7] ہے، اور لسٹ کے تمام آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن جس کا کل پے لوڈ پہلے بائٹ مائنس 0xc0 کے برابر ہے پہلے بائٹ کے بعد آتا ہے؛ + +5. ڈیٹا ایک لسٹ ہے اگر پہلے بائٹ کی رینج [0xf8, 0xff] ہے، اور لسٹ کا کل پے لوڈ جس کی لمبائی پہلے بائٹ مائنس 0xf7 کے برابر ہے پہلے بائٹ کے بعد آتا ہے، اور لسٹ کے تمام آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن لسٹ کے کل پے لوڈ کے بعد آتا ہے؛ + +کوڈ میں، یہ ہے: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("input is null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("input does not conform to RLP encoding form") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("input is null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## مزید پڑھیں {#further-reading} + +- [Ethereum میں RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum انڈر دی ہڈ: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). ACL2 میں Ethereum کا ریکرسیو لینتھ پریفکس۔ arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## متعلقہ موضوعات {#related-topics} + +- [Patricia merkle trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..5044d561ca4 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,149 @@ +--- +title: Simple serialize +description: "Ethereum کے SSZ فارمیٹ کی وضاحت۔" +lang: ur-in +sidebarDepth: 2 +--- + +**Simple serialize (SSZ)** وہ سیریلائزیشن طریقہ ہے جو Beacon Chain پر استعمال ہوتا ہے۔ یہ consensus layer میں ہر جگہ execution layer پر استعمال ہونے والی RLP سیریلائزیشن کی جگہ لیتا ہے، سوائے peer discovery protocol کے۔ RLP سیریلائزیشن کے بارے میں مزید جاننے کے لیے، [Recursive-length prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp/) دیکھیں۔ SSZ کو اس طرح ڈیزائن کیا گیا ہے کہ یہ متعین (deterministic) ہو اور مؤثر طریقے سے Merkleize بھی کر سکے۔ SSZ کو دو اجزاء پر مشتمل سمجھا جا سکتا ہے: ایک سیریلائزیشن اسکیم اور ایک Merkleization اسکیم جسے سیریلائزڈ ڈیٹا اسٹرکچر کے ساتھ مؤثر طریقے سے کام کرنے کے لیے ڈیزائن کیا گیا ہے۔ + +## SSZ کیسے کام کرتا ہے؟ {#how-does-ssz-work} + +### سیریلائزیشن {#serialization} + +SSZ ایک سیریلائزیشن اسکیم ہے جو خود اپنی وضاحت نہیں کرتی - بلکہ یہ ایک ایسے اسکیما پر انحصار کرتی ہے جسے پہلے سے معلوم ہونا ضروری ہے۔ SSZ سیریلائزیشن کا مقصد کسی بھی پیچیدگی کی اشیاء (objects) کی نمائندگی بائٹس (bytes) کی اسٹرنگز کے طور پر کرنا ہے۔ یہ "بنیادی اقسام" (basic types) کے لیے ایک بہت آسان عمل ہے۔ عنصر (element) کو سیدھے سادھے ہیکسا ڈیسیمل بائٹس میں تبدیل کر دیا جاتا ہے۔ بنیادی اقسام میں شامل ہیں: + +- غیر دستخط شدہ انٹیجرس (unsigned integers) +- بولینز (Booleans) + +پیچیدہ "مرکب" اقسام (composite types) کے لیے، سیریلائزیشن زیادہ پیچیدہ ہے کیونکہ مرکب قسم میں متعدد عناصر ہوتے ہیں جن کی اقسام یا سائز مختلف ہو سکتے ہیں، یا دونوں۔ جہاں ان تمام اشیاء (objects) کی لمبائی مقرر (fixed) ہوتی ہے (یعنی، عناصر کا سائز ان کی اصل قدروں سے قطع نظر ہمیشہ مستقل رہے گا)، سیریلائزیشن صرف مرکب قسم کے ہر عنصر کو little-endian بائٹ اسٹرنگز میں ترتیب دے کر تبدیل کرنا ہے۔ ان بائٹ اسٹرنگز کو ایک ساتھ جوڑ دیا جاتا ہے۔ سیریلائزڈ آبجیکٹ میں مقررہ لمبائی والے عناصر کی بائٹ لسٹ نمائندگی اسی ترتیب میں ہوتی ہے جس میں وہ ڈی سیریلائزڈ آبجیکٹ میں ظاہر ہوتے ہیں۔ + +متغیر لمبائی والی اقسام کے لیے، سیریلائزڈ آبجیکٹ میں اس عنصر کی پوزیشن پر اصل ڈیٹا کو ایک "آفسیٹ" قدر سے بدل دیا جاتا ہے۔ اصل ڈیٹا کو سیریلائزڈ آبجیکٹ کے آخر میں ایک ہیپ (heap) میں شامل کیا جاتا ہے۔ آفسیٹ قدر ہیپ میں اصل ڈیٹا کے آغاز کے لیے انڈیکس ہے، جو متعلقہ بائٹس کے لیے ایک پوائنٹر کے طور پر کام کرتا ہے۔ + +نیچے دی گئی مثال وضاحت کرتی ہے کہ ایک ایسے کنٹینر کے لیے آفسیٹنگ کیسے کام کرتی ہے جس میں مقررہ اور متغیر لمبائی والے دونوں عناصر ہوں: + +```Rust + + struct Dummy { + + number1: u64, + number2: u64, + vector: Vec, + number3: u64 + } + + dummy = Dummy{ + + number1: 37, + number2: 55, + vector: vec![1,2,3,4], + number3: 22, + } + + serialized = ssz.serialize(dummy) + +``` + +`serialized` کی ساخت درج ذیل ہوگی (یہاں صرف 4 بٹس تک پیڈ کیا گیا ہے، حقیقت میں 32 بٹس تک پیڈ کیا جاتا ہے، اور وضاحت کے لیے `int` نمائندگی کو برقرار رکھا گیا ہے): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + number1 number2 vector کے number 3 vector کی + لیے آفسیٹ قدر + +``` + +وضاحت کے لیے لائنوں میں تقسیم کیا گیا ہے: + +``` +[ + 37, 0, 0, 0, # `number1` کی little-endian انکوڈنگ۔ + 55, 0, 0, 0, # `number2` کی little-endian انکوڈنگ۔ + 16, 0, 0, 0, # وہ "آفسیٹ" جو بتاتا ہے کہ `vector` کی قدر کہاں سے شروع ہوتی ہے (little-endian 16)۔ + 22, 0, 0, 0, # `number3` کی little-endian انکوڈنگ۔ + 1, 2, 3, 4, # `vector` میں اصل قدریں۔ +] +``` + +یہ اب بھی ایک سادہ شکل ہے - اوپر دیے گئے خاکوں میں موجود انٹیجرس اور زیروز دراصل بائٹ لسٹس کے طور پر اسٹور کیے جائیں گے، اس طرح: + +``` +[ + 10100101000000000000000000000000 # `number1` کی little-endian انکوڈنگ + 10110111000000000000000000000000 # `number2` کی little-endian انکوڈنگ۔ + 10010000000000000000000000000000 # وہ "آفسیٹ" جو بتاتا ہے کہ `vector` کی قدر کہاں سے شروع ہوتی ہے (little-endian 16)۔ + 10010110000000000000000000000000 # `number3` کی little-endian انکوڈنگ۔ + 10000001100000101000001110000100 # `bytes` فیلڈ کی اصل قدر۔ +] +``` + +لہذا متغیر لمبائی والی اقسام کی اصل قدریں سیریلائزڈ آبجیکٹ کے آخر میں ایک ہیپ میں اسٹور کی جاتی ہیں اور ان کے آفسیٹس کو فیلڈز کی ترتیب شدہ فہرست میں ان کی صحیح پوزیشنوں پر اسٹور کیا جاتا ہے۔ + +کچھ خاص معاملات بھی ہیں جن کے لیے مخصوص برتاؤ کی ضرورت ہوتی ہے، جیسے کہ `BitList` قسم جس میں سیریلائزیشن کے دوران لمبائی کی حد (length cap) شامل کرنے اور ڈی سیریلائزیشن کے دوران اسے ہٹانے کی ضرورت ہوتی ہے۔ مکمل تفصیلات [SSZ spec](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) میں دستیاب ہیں۔ + +### ڈی سیریلائزیشن {#deserialization} + +اس آبجیکٹ کو ڈی سیریلائز کرنے کے لیے اسکیما کی ضرورت ہوتی ہے۔ اسکیما سیریلائزڈ ڈیٹا کی عین ترتیب کی وضاحت کرتا ہے تاکہ ہر مخصوص عنصر کو بائٹس کے ایک blob سے ایک ایسے بامعنی آبجیکٹ میں ڈی سیریلائز کیا جا سکے جس میں عناصر کی قسم، قدر، سائز اور پوزیشن صحیح ہو۔ یہ اسکیما ہی ہے جو ڈی سیریلائزر کو بتاتا ہے کہ کون سی قدریں اصل ہیں اور کون سی آفسیٹ ہیں۔ جب کسی آبجیکٹ کو سیریلائز کیا جاتا ہے تو تمام فیلڈ کے نام غائب ہو جاتے ہیں، لیکن ڈی سیریلائزیشن پر اسکیما کے مطابق انہیں دوبارہ بنایا جاتا ہے۔ + +اس پر ایک انٹرایکٹو وضاحت کنندہ کے لیے [ssz.dev](https://www.ssz.dev/overview) دیکھیں۔ + +## مرکلائزیشن {#merkleization} + +اس SSZ سیریلائزڈ آبجیکٹ کو پھر مرکلائز کیا جا سکتا ہے - یعنی اسی ڈیٹا کی Merkle-tree نمائندگی میں تبدیل کیا جا سکتا ہے۔ سب سے پہلے، سیریلائزڈ آبجیکٹ میں 32-بائٹ کے چنکس (chunks) کی تعداد کا تعین کیا جاتا ہے۔ یہ درخت کے "پتے" (leaves) ہیں۔ پتوں کی کل تعداد 2 کی طاقت (power of 2) ہونی چاہیے تاکہ پتوں کو ایک ساتھ ہیش کرنے پر آخر کار ایک واحد ہیش-ٹری-روٹ (hash-tree-root) بن جائے۔ اگر قدرتی طور پر ایسا نہیں ہے، تو 32 بائٹس کے زیروز پر مشتمل اضافی پتے شامل کیے جاتے ہیں۔ خاکے کے طور پر: + +``` + ہیش ٹری روٹ + / \ + / \ + / \ + / \ + پتے 1 اور 2 کا ہیش پتے 3 اور 4 کا ہیش + / \ / \ + / \ / \ + / \ / \ + پتا 1 پتا 2 پتا 3 پتا 4 +``` + +ایسے معاملات بھی ہیں جہاں درخت کے پتے قدرتی طور پر اس طرح یکساں طور پر تقسیم نہیں ہوتے جیسا کہ اوپر کی مثال میں ہے۔ مثال کے طور پر، پتا 4 ایک ایسا کنٹینر ہو سکتا ہے جس میں متعدد عناصر ہوں جن کے لیے Merkle ٹری میں اضافی "گہرائی" (depth) شامل کرنے کی ضرورت ہوتی ہے، جس سے ایک غیر مساوی درخت بنتا ہے۔ + +درخت کے ان عناصر کو پتا X، نوڈ X وغیرہ کہنے کے بجائے، ہم انہیں عمومی انڈیکس دے سکتے ہیں، جس کی شروعات روٹ = 1 سے ہوتی ہے اور ہر سطح پر بائیں سے دائیں گنتی کی جاتی ہے۔ یہ اوپر بیان کردہ عمومی انڈیکس ہے۔ سیریلائزڈ فہرست میں ہر عنصر کا ایک عمومی انڈیکس ہوتا ہے جو `2**depth + idx` کے برابر ہوتا ہے، جہاں idx سیریلائزڈ آبجیکٹ میں اس کی زیرو-انڈیکسڈ پوزیشن ہے اور depth مرکل ٹری میں سطحوں کی تعداد ہے, جس کا تعین عناصر (پتوں) کی تعداد کے بیس-ٹو لاگرتھم کے طور پر کیا جا سکتا ہے۔ + +## عمومی انڈیکس {#generalized-indices} + +ایک عمومی انڈیکس ایک انٹیجر ہے جو ایک بائنری Merkle ٹری میں ایک نوڈ کی نمائندگی کرتا ہے جہاں ہر نوڈ کا ایک عمومی انڈیکس `2 ** depth + index in row` ہوتا ہے۔ + +``` + 1 --گہرائی = 0 2**0 + 0 = 1 + 2 3 --گہرائی = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --گہرائی = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +یہ نمائندگی Merkle ٹری میں موجود ڈیٹا کے ہر ٹکڑے کے لیے ایک نوڈ انڈیکس فراہم کرتی ہے۔ + +## ملٹی پروفس {#multiproofs} + +کسی مخصوص عنصر کی نمائندگی کرنے والے عمومی انڈیکس کی فہرست فراہم کرنا ہمیں اسے ہیش-ٹری-روٹ کے خلاف تصدیق کرنے کی اجازت دیتا ہے۔ یہ روٹ حقیقت کا ہمارا قبول شدہ ورژن ہے۔ ہمیں فراہم کردہ کسی بھی ڈیٹا کی اس حقیقت کے خلاف تصدیق کی جا سکتی ہے، اسے Merkle ٹری میں صحیح جگہ پر داخل کرکے (جس کا تعین اس کے عمومی انڈیکس سے ہوتا ہے) اور یہ دیکھ کر کہ روٹ مستقل رہتا ہے۔ اسپیک میں [یہاں](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) فنکشنز ہیں جو عمومی انڈیکس کے ایک خاص سیٹ کے مواد کی تصدیق کے لیے درکار نوڈز کے کم سے کم سیٹ کا حساب لگانے کا طریقہ دکھاتے ہیں۔ + +مثال کے طور پر، نیچے دیے گئے ٹری میں انڈیکس 9 پر ڈیٹا کی تصدیق کرنے کے لیے، ہمیں انڈیکس 8، 9، 5، 3، 1 پر موجود ڈیٹا کے ہیش کی ضرورت ہے۔ +(8,9) کا ہیش، ہیش (4) کے برابر ہونا چاہیے، جو 5 کے ساتھ ہیش ہو کر 2 بناتا ہے، جو 3 کے ساتھ ہیش ہو کر ٹری روٹ 1 بناتا ہے۔ اگر 9 کے لیے غلط ڈیٹا فراہم کیا گیا، تو روٹ بدل جائے گا - ہم اس کا پتہ لگا لیں گے اور برانچ کی تصدیق میں ناکام ہو جائیں گے۔ + +``` +* = پروف بنانے کے لیے درکار ڈیٹا + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم کو اپ گریڈ کرنا: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [ایتھیریم کو اپ گریڈ کرنا: مرکلائزیشن](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [SSZ کے نفاذ](https://github.com/ethereum/consensus-specs/issues/2138) +- [SSZ کیلکولیٹر](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..7a0959b71f4 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: "Web3 خفیہ اسٹوریج کی تعریف" +description: "web3 خفیہ اسٹوریج کے لیے رسمی تعریف" +lang: ur-in +sidebarDepth: 2 +--- + +اپنی ایپ کو Ethereum پر کام کرنے کے قابل بنانے کے لیے، آپ web3.js لائبریری کے ذریعے فراہم کردہ web3 آبجیکٹ استعمال کر سکتے ہیں۔ اندرونی طور پر یہ RPC کالز کے ذریعے ایک مقامی نوڈ سے رابطہ کرتا ہے۔ [web3](https://github.com/ethereum/web3.js/) کسی بھی ایسے Ethereum نوڈ کے ساتھ کام کرتا ہے جو RPC لیئر کو ایکسپوز کرتا ہے۔ + +`web3` میں `eth` آبجیکٹ شامل ہے - web3.eth۔ + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** نتیجہ + * [ 'web3', 3 ] web3 (v3) کلیدی فائل + * [ 'ethersale', undefined ] Ethersale کلیدی فائل + * null غلط کلیدی فائل + */ +``` + +یہ دستاویز Web3 خفیہ اسٹوریج کی تعریف کا **ورژن 3** ہے۔ + +## تعریف {#definition} + +فائل کی اصل انکوڈنگ اور ڈی کوڈنگ بڑی حد تک ورژن 1 سے غیر تبدیل شدہ ہے، سوائے اس کے کہ کرپٹو الگورتھم اب AES-128-CBC پر فکس نہیں ہے (AES-128-CTR اب کم از کم ضرورت ہے)۔ زیادہ تر معنی/الگورتھم ورژن 1 کی طرح ہیں، سوائے `mac` کے، جسے ماخوذ کلید کے دوسرے بائیں طرف کے 16 بائٹس اور مکمل `ciphertext` کے الحاق کے SHA3 (keccak-256) کے طور پر دیا گیا ہے۔ + +خفیہ کلیدی فائلیں براہ راست `~/.web3/keystore` (یونکس جیسے سسٹمز کے لیے) اور `~/AppData/Web3/keystore` (ونڈوز کے لیے) میں محفوظ کی جاتی ہیں۔ ان کا نام کچھ بھی رکھا جا سکتا ہے، لیکن ایک اچھا کنونشن `.json` ہے، جہاں `` خفیہ کلید کو دیا گیا 128 بٹ UUID ہے (خفیہ کلید کے ایڈریس کے لیے رازداری کو محفوظ رکھنے والی پراکسی)۔ + +ایسی تمام فائلوں کا ایک متعلقہ پاس ورڈ ہوتا ہے۔ کسی دی گئی `.json` فائل کی خفیہ کلید حاصل کرنے کے لیے، پہلے فائل کی انکرپشن کلید حاصل کریں؛ یہ فائل کا پاس ورڈ لے کر اور اسے کلیدی ڈیریویشن فنکشن کے ذریعے پاس کر کے کیا جاتا ہے جیسا کہ `kdf` کلید کے ذریعے بیان کیا گیا ہے۔ KDF فنکشن کے لیے KDF پر منحصر جامد اور متحرک پیرامیٹرز `kdfparams` کلید میں بیان کیے گئے ہیں۔ + +PBKDF2 کو تمام کم از کم تعمیل کرنے والے نفاذ کے ذریعے سپورٹ کیا جانا چاہیے، جس کی نشاندہی اس طرح کی گئی ہے: + +- `kdf`: `pbkdf2` + +PBKDF2 کے لیے، kdfparams میں شامل ہیں: + +- `prf`: `hmac-sha256` ہونا چاہیے (مستقبل میں بڑھایا جا سکتا ہے)؛ +- `c`: تکرار کی تعداد؛ +- `salt`: PBKDF کو بھیجا گیا سالٹ؛ +- `dklen`: ماخوذ کلید کی لمبائی۔ >= 32 ہونا چاہیے۔ + +ایک بار فائل کی کلید حاصل ہو جانے کے بعد، اسے MAC کے ڈیریویشن کے ذریعے تصدیق کی جانی چاہیے۔ MAC کا حساب بائٹ ارے کے SHA3 (keccak-256) ہیش کے طور پر کیا جانا چاہیے جو ماخوذ کلید کے دوسرے بائیں طرف کے 16 بائٹس اور `ciphertext` کلید کے مواد کے الحاق کے طور پر تشکیل دیا گیا ہے، یعنی: + +```js +KECCAK(DK[16..31] ++ ) +``` + +(جہاں `++` الحاق آپریٹر ہے) + +اس قدر کا موازنہ `mac` کلید کے مواد سے کیا جانا چاہیے؛ اگر وہ مختلف ہیں، تو ایک متبادل پاس ورڈ کی درخواست کی جانی چاہیے (یا آپریشن منسوخ کر دیا جائے)۔ + +فائل کی کلید کی تصدیق کے بعد، سائفر ٹیکسٹ (فائل میں `ciphertext` کلید) کو `cipher` کلید کے ذریعے متعین کردہ سمیٹرک انکرپشن الگورتھم کا استعمال کرتے ہوئے اور `cipherparams` کلید کے ذریعے پیرامیٹرائز کر کے ڈکرپٹ کیا جا سکتا ہے۔ اگر ماخوذ کلید کا سائز اور الگورتھم کی کلید کا سائز مماثل نہیں ہے، تو ماخوذ کلید کے صفر سے بھرے، دائیں جانب کے بائٹس کو الگورتھم کی کلید کے طور پر استعمال کیا جانا چاہیے۔ + +تمام کم از کم تعمیل کرنے والے نفاذ کو AES-128-CTR الگورتھم کو سپورٹ کرنا چاہیے، جس کی نشاندہی اس طرح کی گئی ہے: + +- `cipher: aes-128-ctr` + +یہ سائفر درج ذیل پیرامیٹرز لیتا ہے، جو cipherparams کلید کو کلیدوں کے طور پر دیے گئے ہیں: + +- `iv`: سائفر کے لیے 128 بٹ ابتدائی ویکٹر۔ + +سائفر کی کلید ماخوذ کلید کے بائیں طرف کے 16 بائٹس ہے، یعنی، `DK[0..15]` + +خفیہ کلید کی تخلیق/انکرپشن بنیادی طور پر ان ہدایات کے برعکس ہونی چاہیے۔ یقینی بنائیں کہ `uuid`، `salt` اور `iv` واقعی بے ترتیب ہیں۔ + +`version` فیلڈ کے علاوہ، جسے ورژن کے "سخت" شناخت کنندہ کے طور پر کام کرنا چاہیے، نفاذ فارمیٹ میں چھوٹی، غیر توڑنے والی تبدیلیوں کو ٹریک کرنے کے لیے `minorversion` کا بھی استعمال کر سکتے ہیں۔ + +## ٹیسٹ ویکٹرز {#test-vectors} + +تفصیلات: + +- `ایڈریس`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `پاس ورڈ`: `testpassword` +- `خفیہ`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +`AES-128-CTR` اور `PBKDF2-SHA-256` کا استعمال کرتے ہوئے ٹیسٹ ویکٹر: + +`~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json` کی فائل کا مواد: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**انٹرمیڈیٹس**: + +`ماخوذ کلید`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`MAC باڈی`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`سائفر کلید`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +AES-128-CTR اور Scrypt کا استعمال کرتے ہوئے ٹیسٹ ویکٹر: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**انٹرمیڈیٹس**: + +`ماخوذ کلید`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`MAC باڈی`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`سائفر کلید`: `7446f59ecc301d2d79bc3302650d8a5c` + +## ورژن 1 سے تبدیلیاں {#alterations-from-v2} + +یہ ورژن [یہاں](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) شائع کردہ ورژن 1 کے ساتھ کئی تضادات کو ٹھیک کرتا ہے۔ مختصر میں یہ ہیں: + +- کیپٹلائزیشن غیر منصفانہ اور متضاد ہے (scrypt چھوٹے حروف، Kdf مخلوط کیس، MAC بڑے حروف)۔ +- ایڈریس غیر ضروری ہے اور رازداری سے سمجھوتہ کرتا ہے۔ +- `Salt` بنیادی طور پر کلیدی ڈیریویشن فنکشن کا ایک پیرامیٹر ہے اور اس کے ساتھ منسلک ہونے کا مستحق ہے، نہ کہ عام طور پر کرپٹو کے ساتھ۔ +- _SaltLen_ غیر ضروری ہے (صرف اسے Salt سے حاصل کریں)۔ +- کلیدی ڈیریویشن فنکشن دیا گیا ہے، پھر بھی کرپٹو الگورتھم کو سختی سے متعین کیا گیا ہے۔ +- `Version` بنیادی طور پر عددی ہے پھر بھی ایک سٹرنگ ہے (سٹرکچرڈ ورژننگ ایک سٹرنگ کے ساتھ ممکن ہوگی، لیکن اسے شاذ و نادر ہی تبدیل ہونے والی کنفیگریشن فائل فارمیٹ کے دائرہ کار سے باہر سمجھا جا سکتا ہے)۔ +- `KDF` اور `cipher` تصوراتی طور پر بھائی بہن کے تصورات ہیں پھر بھی مختلف طریقے سے منظم ہیں۔ +- `MAC` کا حساب ڈیٹا کے ایک وائٹ اسپیس اگنوسٹک ٹکڑے کے ذریعے کیا جاتا ہے (!) + +فارمیٹ میں درج ذیل فائل دینے کے لیے تبدیلیاں کی گئی ہیں، جو پہلے سے منسلک صفحہ پر دی گئی مثال کے فعال طور پر مساوی ہے: + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## ورژن 2 سے تبدیلیاں {#alterations-from-v2} + +ورژن 2 ایک ابتدائی C++ نفاذ تھا جس میں بہت سے کیڑے تھے۔ اس سے تمام ضروری چیزیں غیر تبدیل شدہ رہتی ہیں۔ diff --git a/public/content/translations/ur/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/ur/developers/docs/design-and-ux/dex-design-best-practice/index.md new file mode 100644 index 00000000000..06f93a93b5f --- /dev/null +++ b/public/content/translations/ur/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -0,0 +1,220 @@ +--- +title: "غیر مرکزی ایکسچینج (DEX) ڈیزائن کے بہترین طور طریقے" +description: "ٹوکنز کو سویپ کرنے کے لیے UX/UI فیصلوں کی وضاحت کرنے والا ایک گائیڈ۔" +lang: ur-in +--- + +2018 میں Uniswap کے لانچ کے بعد سے، درجنوں مختلف چینز پر سینکڑوں غیر مرکزی ایکسچینجز لانچ ہو چکے ہیں۔ +ان میں سے بہت سے نے نئے عناصر متعارف کرائے یا اپنا الگ انداز شامل کیا، لیکن انٹرفیس عام طور پر ویسا ہی رہا ہے۔ + +اس کی ایک وجہ [جیکب کا قانون](https://lawsofux.com/jakobs-law/) ہے: + +> صارفین اپنا زیادہ تر وقت دوسری سائٹس پر گزارتے ہیں۔ اس کا مطلب ہے کہ صارفین چاہتے ہیں کہ آپ کی سائٹ بھی ان تمام دوسری سائٹس کی طرح کام کرے جنہیں وہ پہلے سے جانتے ہیں۔ + +Uniswap, Pancakeswap، اور Sushiswap جیسے ابتدائی اختراع کاروں کی بدولت، DeFi صارفین کو ایک اجتماعی اندازہ ہے کہ ایک DEX کیسا دکھتا ہے۔ +اسی وجہ سے، ”بہترین عمل“ جیسی کوئی چیز اب ابھر رہی ہے۔ ہم دیکھ رہے ہیں کہ سائٹس پر زیادہ سے زیادہ ڈیزائن کے فیصلوں کو معیاری بنایا جا رہا ہے۔ آپ DEXes کے ارتقاء کو اسے لائیو ٹیسٹ کرنے کی ایک بڑی مثال کے طور پر دیکھ سکتے ہیں۔ جو چیزیں کام کرتی تھیں وہ رہیں، جو نہیں کرتی تھیں، انہیں باہر پھینک دیا گیا۔ شخصیت کے لیے اب بھی گنجائش ہے، لیکن کچھ معیارات ہیں جن پر ایک DEX کو عمل کرنا چاہیے۔ + +یہ مضمون اس کا خلاصہ ہے: + +- کیا شامل کرنا ہے +- اسے جتنا ممکن ہو قابل استعمال کیسے بنایا جائے +- ڈیزائن کو اپنی مرضی کے مطابق بنانے کے اہم طریقے + +مثال کے تمام وائر فریمز خاص طور پر اس مضمون کے لیے بنائے گئے تھے، اگرچہ یہ سب حقیقی پروجیکٹس پر مبنی ہیں۔ + +Figma کٹ بھی نیچے شامل ہے - اسے استعمال کرنے میں ہچکچاہٹ نہ کریں اور اپنے وائر فریمز کو تیز کریں! + +## ایک DEX کی بنیادی ساخت {#basic-anatomy-of-a-dex} + +UI عام طور پر تین عناصر پر مشتمل ہوتا ہے: + +1. مرکزی فارم +2. بٹن +3. تفصیلات کا پینل + +![عام DEX UI، تین اہم عناصر دکھا رہا ہے](./1.png) + +## تغیرات {#variations} + +یہ اس مضمون میں ایک عام موضوع ہوگا، لیکن مختلف طریقے ہیں جن سے ان عناصر کو منظم کیا جا سکتا ہے۔ ”تفصیلات کا پینل“ ہو سکتا ہے: + +- بٹن کے اوپر +- بٹن کے نیچے +- ایک accordion پینل میں پوشیدہ +- اور/یا ایک ”پیش منظر“ موڈل پر + +نوٹ: ایک ”پیش منظر“ موڈل اختیاری ہے، لیکن اگر آپ مرکزی UI پر بہت کم تفصیلات دکھا رہے ہیں، تو یہ ضروری ہو جاتا ہے۔ + +## مرکزی فارم کی ساخت {#structure-of-the-main-form} + +یہ وہ باکس ہے جہاں آپ اصل میں انتخاب کرتے ہیں کہ آپ کون سا ٹوکن سویپ کرنا چاہتے ہیں۔ یہ جزو ایک قطار میں ایک ان پٹ فیلڈ اور ایک چھوٹے بٹن پر مشتمل ہے۔ + +DEXes عام طور پر اضافی تفصیلات ایک قطار اوپر اور ایک قطار نیچے دکھاتے ہیں، اگرچہ اسے مختلف طریقے سے ترتیب دیا جا سکتا ہے۔ + +![ان پٹ قطار، جس کے اوپر اور نیچے تفصیلات کی قطار ہے](./2.png) + +## تغیرات {#variations2} + +یہاں دو UI تغیرات دکھائے گئے ہیں؛ ایک بغیر کسی بارڈر کے، جو ایک بہت ہی کھلا ڈیزائن بناتا ہے، اور ایک جہاں ان پٹ قطار میں ایک بارڈر ہے، جو اس عنصر پر توجہ مرکوز کرتا ہے۔ + +![مرکزی فارم کے دو UI تغیرات](./3.png) + +یہ بنیادی ساخت ڈیزائن میں **معلومات کے چار اہم ٹکڑوں** کو دکھانے کی اجازت دیتی ہے: ہر کونے میں ایک۔ اگر صرف ایک اوپر/نیچے کی قطار ہے، تو صرف دو جگہیں ہیں۔ + +DeFi کے ارتقاء کے دوران، یہاں بہت سی مختلف چیزیں شامل کی گئی ہیں۔ + +## شامل کرنے کے لیے اہم معلومات {#key-info-to-include} + +- والیٹ میں بیلنس +- میکس بٹن +- فیاٹ مساوی +- ”موصولہ“ رقم پر قیمت کا اثر + +DeFi کے ابتدائی دنوں میں، فیاٹ مساوی اکثر غائب تھا۔ اگر آپ کسی بھی قسم کا Web3 پروجیکٹ بنا رہے ہیں، تو یہ ضروری ہے کہ ایک فیاٹ مساوی دکھایا جائے۔ صارفین اب بھی مقامی کرنسیوں کے لحاظ سے سوچتے ہیں، لہذا حقیقی دنیا کے ذہنی ماڈلز سے مطابقت رکھنے کے لیے، اسے شامل کیا جانا چاہیے۔ + +دوسرے فیلڈ پر (وہ جہاں آپ اس ٹوکن کا انتخاب کرتے ہیں جس میں آپ سویپ کر رہے ہیں) آپ ان پٹ رقم اور تخمینی آؤٹ پٹ رقم کے درمیان فرق کا حساب لگا کر فیاٹ کرنسی کی رقم کے آگے قیمت کا اثر بھی شامل کر سکتے ہیں۔ یہ شامل کرنے کے لیے کافی مفید تفصیل ہے۔ + +فیصد بٹن (مثلاً، 25%، 50%، 75%) ایک مفید خصوصیت ہو سکتے ہیں، لیکن وہ زیادہ جگہ لیتے ہیں، زیادہ کال ٹو ایکشن شامل کرتے ہیں، اور زیادہ ذہنی بوجھ ڈالتے ہیں۔ یہی بات فیصد سلائیڈرز کے ساتھ بھی ہے۔ ان میں سے کچھ UI فیصلے آپ کے برانڈ اور آپ کے صارف کی قسم پر منحصر ہوں گے۔ + +اضافی تفصیلات مرکزی فارم کے نیچے دکھائی جا سکتی ہیں۔ چونکہ اس قسم کی معلومات زیادہ تر پرو صارفین کے لیے ہوتی ہیں، اس لیے یہ بہتر ہے کہ یا تو: + +- اسے جتنا ممکن ہو کم سے کم رکھیں، یا؛ +- اسے ایک accordion پینل میں چھپائیں + +![اس مرکزی فارم کے کونوں میں دکھائی گئی تفصیلات](./4.png) + +## شامل کرنے کے لیے اضافی معلومات {#extra-info-to-include} + +- ٹوکن قیمت +- Slippage +- کم از کم موصولہ +- متوقع آؤٹ پٹ +- قیمت کا اثر +- گیس لاگت کا تخمینہ +- دیگر فیس +- آرڈر روٹنگ + +یقیناً، ان میں سے کچھ تفصیلات اختیاری ہو سکتی ہیں۔ + +آرڈر روٹنگ دلچسپ ہے، لیکن زیادہ تر صارفین کے لیے اس سے زیادہ فرق نہیں پڑتا۔ + +کچھ دیگر تفصیلات صرف ایک ہی چیز کو مختلف طریقوں سے دوبارہ بیان کر رہی ہیں۔ مثال کے طور پر ”کم از کم موصولہ“ اور ”slippage“ ایک ہی سکے کے دو رخ ہیں۔ اگر آپ نے slippage 1% پر سیٹ کیا ہے، تو کم از کم جو آپ وصول کرنے کی توقع کر سکتے ہیں وہ ہے = متوقع آؤٹ پٹ-1%۔ کچھ UIs متوقع رقم، کم از کم رقم، اور slippage دکھائیں گے… جو مفید ہے لیکن ممکنہ طور پر ضرورت سے زیادہ ہے۔ + +زیادہ تر صارفین ویسے بھی ڈیفالٹ slippage چھوڑ دیں گے۔ + +”قیمت کا اثر“ اکثر ”to“ فیلڈ میں فیاٹ مساوی کے آگے بریکٹ میں دکھایا جاتا ہے۔ یہ شامل کرنے کے لیے ایک بہترین ux تفصیل ہے، لیکن اگر اسے یہاں دکھایا گیا ہے، تو کیا اسے واقعی نیچے دوبارہ دکھانے کی ضرورت ہے؟ اور پھر دوبارہ ایک پیش منظر اسکرین پر؟ + +بہت سے صارفین (خاص طور پر وہ جو چھوٹی مقدار میں سویپ کر رہے ہیں) ان تفصیلات کی پرواہ نہیں کریں گے؛ وہ صرف ایک نمبر درج کریں گے اور سویپ کو دبائیں گے۔ + +![کچھ تفصیلات ایک ہی چیز دکھاتی ہیں](./5.png) + +بالکل کیا تفصیلات دکھائی جاتی ہیں یہ آپ کے سامعین پر اور آپ ایپ کو کیا احساس دینا چاہتے ہیں اس پر منحصر ہوگا۔ + +اگر آپ تفصیلات کے پینل میں slippage tolerance شامل کرتے ہیں، تو آپ کو اسے یہاں سے براہ راست قابل تدوین بھی بنانا چاہیے۔ یہ ایک ”ایکسلریٹر“ کی ایک اچھی مثال ہے؛ ایک صاف ستھری UX چال جو تجربہ کار صارفین کے بہاؤ کو تیز کر سکتی ہے، ایپ کی عمومی استعمالی اہلیت کو متاثر کیے بغیر۔ + +![Slippage کو تفصیلات کے پینل سے کنٹرول کیا جا سکتا ہے](./6.png) + +یہ ایک اچھا خیال ہے کہ نہ صرف ایک اسکرین پر معلومات کے ایک مخصوص ٹکڑے کے بارے میں احتیاط سے سوچیں، بلکہ پورے بہاؤ کے بارے میں بھی: +مرکزی فارم میں نمبر درج کرنا → تفصیلات اسکین کرنا → پیش منظر اسکرین پر کلک کرنا (اگر آپ کے پاس پیش منظر اسکرین ہے)۔ +کیا تفصیلات کا پینل ہر وقت نظر آنا چاہیے، یا صارف کو اسے پھیلانے کے لیے کلک کرنے کی ضرورت ہے؟ +کیا آپ کو ایک پیش منظر اسکرین شامل کرکے رگڑ پیدا کرنی چاہیے؟ یہ صارف کو سست ہونے اور اپنی تجارت پر غور کرنے پر مجبور کرتا ہے، جو مفید ہو سکتا ہے۔ لیکن کیا وہ وہی تمام معلومات دوبارہ دیکھنا چاہتے ہیں؟ اس مقام پر ان کے لیے سب سے زیادہ مفید کیا ہے؟ + +## ڈیزائن کے اختیارات {#design-options} + +جیسا کہ ذکر کیا گیا ہے، اس میں سے بہت کچھ آپ کے ذاتی انداز پر منحصر ہے +آپ کا صارف کون ہے؟ +آپ کا برانڈ کیا ہے؟ +کیا آپ ایک ”پرو“ انٹرفیس چاہتے ہیں جو ہر تفصیل دکھائے، یا آپ کم سے کم پسند کرنا چاہتے ہیں؟ +یہاں تک کہ اگر آپ ان پرو صارفین کو نشانہ بنا رہے ہیں جو تمام ممکنہ معلومات چاہتے ہیں، آپ کو پھر بھی ایلن کوپر کے دانشمندانہ الفاظ یاد رکھنے چاہئیں: + +> چاہے کتنا ہی خوبصورت کیوں نہ ہو، چاہے آپ کا انٹرفیس کتنا ہی ٹھنڈا کیوں نہ ہو، یہ بہتر ہوگا اگر یہ کم ہوتا۔ + +### ساخت {#structure} + +- بائیں طرف ٹوکن، یا دائیں طرف ٹوکن +- 2 قطاریں یا 3 +- بٹن کے اوپر یا نیچے تفصیلات +- تفصیلات پھیلائی گئیں، چھوٹی کی گئیں، یا نہیں دکھائی گئیں + +### جزوی انداز {#component-style} + +- خالی +- آؤٹ لائن شدہ +- بھرا ہوا + +ایک خالص UX نقطہ نظر سے، UI انداز آپ کی سوچ سے کم اہمیت رکھتا ہے۔ بصری رجحانات چکروں میں آتے اور جاتے ہیں، اور بہت سی ترجیحات موضوعی ہوتی ہیں۔ + +اس کا احساس حاصل کرنے کا سب سے آسان طریقہ - اور مختلف تشکیلات کے بارے میں سوچنا - یہ ہے کہ کچھ مثالیں دیکھیں اور پھر خود کچھ تجربات کریں۔ + +شامل Figma کٹ میں خالی، آؤٹ لائن شدہ اور بھرے ہوئے اجزاء شامل ہیں۔ + +نیچے دی گئی مثالوں پر ایک نظر ڈالیں یہ دیکھنے کے لیے کہ آپ اسے مختلف طریقوں سے کیسے اکٹھا کر سکتے ہیں: + +![بھرے ہوئے انداز میں 3 قطاریں](./7.png) + +![آؤٹ لائن والے انداز میں 3 قطاریں](./8.png) + +![خالی انداز میں 2 قطاریں](./9.png) + +![آؤٹ لائن والے انداز میں 3 قطاریں، ایک تفصیلات پینل کے ساتھ](./10.png) + +![3 قطاریں جس میں ان پٹ قطار آؤٹ لائن والے انداز میں ہے](./11.png) + +![بھرے ہوئے انداز میں 2 قطاریں](./12.png) + +## لیکن ٹوکن کس طرف جانا چاہیے؟ {#but-which-side-should-the-token-go-on} + +حتمی بات یہ ہے کہ اس سے شاید استعمالی اہلیت پر کوئی بڑا فرق نہیں پڑتا۔ تاہم، کچھ باتیں ذہن میں رکھنے کی ہیں، جو آپ کو ایک یا دوسری طرف مائل کر سکتی ہیں۔ + +یہ دیکھنا قدرے دلچسپ رہا ہے کہ وقت کے ساتھ فیشن کیسے بدلتا ہے۔ Uniswap نے شروع میں ٹوکن کو بائیں طرف رکھا تھا، لیکن اب اسے دائیں طرف منتقل کر دیا ہے۔ Sushiswap نے بھی یہ تبدیلی ایک ڈیزائن اپ گریڈ کے دوران کی۔ زیادہ تر، لیکن سبھی نہیں، پروٹوکولز نے اس کی پیروی کی ہے۔ + +مالیاتی روایت روایتی طور پر کرنسی کی علامت کو نمبر سے پہلے رکھتی ہے، مثال کے طور پر، $50, €50, £50، لیکن ہم 50 ڈالر، 50 یورو، 50 پاؤنڈ _کہتے_ ہیں۔ + +عام صارف کے لیے - خاص طور پر وہ جو بائیں سے دائیں، اوپر سے نیچے پڑھتا ہے - دائیں طرف ٹوکن شاید زیادہ قدرتی محسوس ہوتا ہے۔ + +![ایک UI جس میں ٹوکن بائیں طرف ہیں](./13.png) + +ٹوکن کو بائیں طرف اور تمام نمبروں کو دائیں طرف رکھنا خوشگوار طور پر متوازی لگتا ہے، جو ایک پلس ہے، لیکن اس لے آؤٹ کا ایک اور نقصان ہے۔ + +قربت کا قانون کہتا ہے کہ جو اشیاء ایک دوسرے کے قریب ہوتی ہیں انہیں متعلقہ سمجھا جاتا ہے۔ اسی کے مطابق، ہم متعلقہ اشیاء کو ایک دوسرے کے ساتھ رکھنا چاہتے ہیں۔ ٹوکن بیلنس کا براہ راست تعلق خود ٹوکن سے ہے، اور جب بھی کوئی نیا ٹوکن منتخب کیا جائے گا تو یہ بدل جائے گا۔ اس لیے یہ قدرے زیادہ معنی خیز ہے کہ ٹوکن بیلنس ٹوکن سلیکٹ بٹن کے ساتھ ہو۔ اسے ٹوکن کے نیچے منتقل کیا جا سکتا ہے، لیکن اس سے لے آؤٹ کی ہم آہنگی ٹوٹ جاتی ہے۔ + +آخر کار، دونوں آپشنز کے فائدے اور نقصانات ہیں، لیکن یہ دلچسپ ہے کہ رجحان دائیں طرف ٹوکن کی طرف دکھائی دیتا ہے۔ + +## بٹن کا برتاؤ {#button-behavior} + +Approve کے لیے الگ بٹن نہ رکھیں۔ Approve کے لیے الگ کلک بھی نہ رکھیں۔ صارف Swap کرنا چاہتا ہے، اس لیے بٹن پر صرف ”swap“ کہیں اور منظوری کو پہلے قدم کے طور پر شروع کریں۔ ایک موڈل ایک اسٹیپر کے ساتھ پیش رفت دکھا سکتا ہے، یا ایک سادہ ”tx 1 of 2 - approving“ نوٹیفکیشن۔ + +![ایک UI جس میں approve اور swap کے لیے الگ الگ بٹن ہیں](./14.png) + +![ایک UI جس میں ایک بٹن ہے جو approve کہتا ہے](./15.png) + +### بٹن بطور سیاق و سباق کی مدد {#button-as-contextual-help} + +بٹن ایک الرٹ کے طور پر دوہرا کام کر سکتا ہے! + +یہ دراصل Web3 سے باہر ایک کافی غیر معمولی ڈیزائن پیٹرن ہے، لیکن اس کے اندر یہ معیاری بن گیا ہے۔ یہ ایک اچھی اختراع ہے کیونکہ یہ جگہ بچاتی ہے، اور توجہ مرکوز رکھتی ہے۔ + +اگر مرکزی کارروائی - SWAP - کسی خرابی کی وجہ سے دستیاب نہیں ہے، تو اس کی وجہ بٹن کے ساتھ بیان کی جا سکتی ہے، مثلاً: + +- نیٹ ورک تبدیل کریں +- والیٹ جوڑیں +- مختلف غلطیاں + +بٹن کو اس کارروائی سے بھی **میپ** کیا جا سکتا ہے جسے انجام دینے کی ضرورت ہے۔ مثال کے طور پر، اگر صارف غلط نیٹ ورک پر ہونے کی وجہ سے سویپ نہیں کر سکتا، تو بٹن کو ”ایتھیریم پر سوئچ کریں“ کہنا چاہیے، اور جب صارف بٹن پر کلک کرتا ہے، تو اسے نیٹ ورک کو ایتھیریم پر سوئچ کرنا چاہیے۔ یہ صارف کے بہاؤ کو نمایاں طور پر تیز کرتا ہے۔ + +![مرکزی CTA سے شروع کی جانے والی اہم کارروائیاں](./16.png) + +![مرکزی CTA کے اندر دکھایا گیا خرابی کا پیغام](./17.png) + +## اس figma فائل کے ساتھ اپنا خود بنائیں {#build-your-own-with-this-figma-file} + +متعدد پروٹوکولز کی محنت کی بدولت، DEX ڈیزائن میں بہت بہتری آئی ہے۔ ہم جانتے ہیں کہ صارف کو کیا معلومات درکار ہیں، ہمیں اسے کیسے دکھانا چاہیے، اور بہاؤ کو جتنا ممکن ہو ہموار کیسے بنایا جائے۔ +امید ہے کہ یہ مضمون UX اصولوں کا ایک ٹھوس جائزہ فراہم کرتا ہے۔ + +اگر آپ تجربہ کرنا چاہتے ہیں، تو براہ کرم Figma وائر فریم کٹ استعمال کرنے میں ہچکچاہٹ نہ کریں۔ اسے جتنا ممکن ہو سادہ رکھا گیا ہے، لیکن اس میں بنیادی ڈھانچے کو مختلف طریقوں سے بنانے کے لیے کافی لچک ہے۔ + +[Figma وائر فریم کٹ](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) + +DeFi کا ارتقاء جاری رہے گا، اور بہتری کی گنجائش ہمیشہ رہتی ہے۔ + +گڈ لک! diff --git a/public/content/translations/ur/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/ur/developers/docs/design-and-ux/heuristics-for-web3/index.md new file mode 100644 index 00000000000..c35f2af19fe --- /dev/null +++ b/public/content/translations/ur/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -0,0 +1,138 @@ +--- +title: "Web3 انٹرفیس ڈیزائن کے لیے 7 طریقہ کار" +description: "Web3 کی استعمال پذیری کو بہتر بنانے کے اصول" +lang: ur-in +--- + +استعمال پذیری کے طریقہ کار وسیع "عام اصول" ہیں جنہیں آپ اپنی سائٹ کی استعمال پذیری کی پیمائش کرنے کے لیے استعمال کر سکتے ہیں۔ +یہاں دیے گئے 7 طریقہ کار خاص طور پر Web3 کے لیے بنائے گئے ہیں اور انہیں Jakob Nielsen کے [تعامل ڈیزائن کے 10 عمومی اصولوں](https://www.nngroup.com/articles/ten-usability-heuristics/) کے ساتھ استعمال کیا جانا چاہیے۔ + +## web3 کے لیے استعمال پذیری کے سات طریقہ کار {#seven-usability-heuristics-for-web3} + +1. فیڈبیک کارروائی کے بعد آتا ہے +2. سیکیورٹی اور اعتماد +3. سب سے اہم معلومات واضح ہے +4. قابل فہم اصطلاحات +5. کارروائیاں جتنی ممکن ہو مختصر ہوں +6. نیٹ ورک کنکشنز نظر آنے والے اور لچکدار ہیں +7. ایپ سے کنٹرول کریں، والیٹ سے نہیں + +## تعریفیں اور مثالیں {#definitions-and-examples} + +### 1۔ فیڈبیک کارروائی کے بعد آتا ہے {#feedback-follows-action} + +**یہ واضح ہونا چاہیے کہ کب کچھ ہوا ہے، یا ہو رہا ہے۔** + +صارفین اپنے پچھلے اقدامات کے نتیجے کی بنیاد پر اپنے اگلے اقدامات کا فیصلہ کرتے ہیں۔ اس لیے یہ ضروری ہے کہ وہ سسٹم کی حالت کے بارے میں باخبر رہیں۔ یہ Web3 میں خاص طور پر اہم ہے کیونکہ ٹرانزیکشنز کو بلاک چین پر کمٹ ہونے میں کبھی کبھی تھوڑا وقت لگ سکتا ہے۔ اگر انہیں انتظار کرنے کے لیے کوئی فیڈبیک نہیں ملتا، تو صارفین کو یقین نہیں ہوتا کہ کچھ ہوا بھی ہے یا نہیں۔ + +**تجاویز:** + +- صارف کو میسجنگ، نوٹیفیکیشنز، اور دیگر الرٹس کے ذریعے مطلع کریں۔ +- انتظار کے اوقات کو واضح طور پر بتائیں۔ +- اگر کسی کارروائی میں چند سیکنڈ سے زیادہ وقت لگنے والا ہے، تو صارف کو ایک ٹائمر یا اینیمیشن کے ذریعے یقین دلائیں تاکہ انہیں لگے کہ کچھ ہو رہا ہے۔ +- اگر کسی عمل میں کئی مراحل ہیں، تو ہر مرحلہ دکھائیں۔ + +**مثال:** +ٹرانزیکشن میں شامل ہر مرحلہ دکھانے سے صارفین کو یہ جاننے میں مدد ملتی ہے کہ وہ عمل میں کہاں ہیں۔ مناسب آئیکنز صارف کو ان کی کارروائیوں کی حالت بتاتے ہیں۔ + +![ٹوکنز تبدیل کرتے وقت ہر مرحلے کے بارے میں صارف کو مطلع کرنا](./Image1.png) + +### 2۔ سیکیورٹی اور اعتماد پہلے سے شامل ہیں {#security-and-trust-are-backed-in} + +سیکیورٹی کو ترجیح دی جانی چاہیے، اور صارف کے لیے اس پر زور دیا جانا چاہیے۔ +لوگوں کو اپنے ڈیٹا کی بہت فکر ہوتی ہے۔ حفاظت اکثر صارفین کے لیے ایک بنیادی تشویش ہوتی ہے، اس لیے ڈیزائن کے تمام سطحوں پر اس پر غور کیا جانا چاہیے۔ آپ کو ہمیشہ اپنے صارفین کا اعتماد حاصل کرنے کی کوشش کرنی چاہیے، لیکن آپ یہ کیسے کرتے ہیں اس کا مطلب مختلف ایپس پر مختلف ہو سکتا ہے۔ یہ بعد میں سوچنے والی چیز نہیں ہونی چاہیے، بلکہ اسے پورے عمل میں شعوری طور پر ڈیزائن کیا جانا چاہیے۔ صارف کے پورے تجربے میں اعتماد پیدا کریں، بشمول سوشل چینلز اور دستاویزات، اور ساتھ ہی حتمی UI میں بھی۔ وکندریقرت کی سطح، ٹریژری ملٹی-سگ اسٹیٹس، اور کیا ٹیم کی شناخت ظاہر کی گئی ہے، یہ تمام چیزیں صارفین کے اعتماد کو متاثر کرتی ہیں + +**تجاویز:** + +- اپنے آڈٹس کی فخر سے فہرست بنائیں۔ +- متعدد آڈٹس کروائیں۔ +- آپ کی ڈیزائن کردہ کسی بھی حفاظتی خصوصیات کی تشہیر کریں۔ +- ممکنہ خطرات کو نمایاں کریں، بشمول بنیادی انضمام۔ +- حکمت عملیوں کی پیچیدگی کو بتائیں۔ +- ان غیر-UI مسائل پر غور کریں جو آپ کے صارفین کے حفاظت کے تصور کو متاثر کر سکتے ہیں۔ + +**مثال:** +اپنے آڈٹس کو فوٹر میں ایک نمایاں سائز میں شامل کریں۔ + +![ویب سائٹ کے فوٹر میں حوالہ دیے گئے آڈٹس](./Image2.png) + +### 3۔ سب سے اہم معلومات واضح ہے {#the-most-important-info-is-obvious} + +پیچیدہ سسٹمز کے لیے، صرف سب سے متعلقہ ڈیٹا دکھائیں۔ طے کریں کہ سب سے اہم کیا ہے، اور اس کے ڈسپلے کو ترجیح دیں۔ +بہت زیادہ معلومات بھاری ہوتی ہے اور صارفین فیصلے کرتے وقت عام طور پر ایک ہی معلومات پر انحصار کرتے ہیں۔ DeFi میں، یہ شاید ییلڈ ایپس پر APR اور قرض دینے والی ایپس پر LTV ہوگا۔ + +**تجاویز:** + +- صارف کی تحقیق سب سے اہم میٹرک کو ظاہر کرے گی۔ +- کلیدی معلومات کو بڑا، اور دیگر تفصیلات کو چھوٹا اور غیر نمایاں بنائیں۔ +- لوگ پڑھتے نہیں، وہ اسکین کرتے ہیں؛ یقینی بنائیں کہ آپ کا ڈیزائن اسکین کے قابل ہے۔ + +**مثال:** مکمل رنگ میں بڑے ٹوکنز اسکین کرتے وقت آسانی سے مل جاتے ہیں۔ APR بڑا ہے اور ایک نمایاں رنگ میں نمایاں کیا گیا ہے۔ + +![ٹوکن اور APR کو تلاش کرنا آسان ہے](./Image3.png) + +### 4. واضح اصطلاحات {#clear-terminology} + +اصطلاحات قابل فہم اور مناسب ہونی چاہئیں۔ +تکنیکی اصطلاحات ایک بڑی رکاوٹ ہو سکتی ہیں، کیونکہ اس کے لیے بالکل نئے ذہنی ماڈل کی تعمیر کی ضرورت ہوتی ہے۔ صارفین ڈیزائن کو ان الفاظ، جملوں اور تصورات سے جوڑ نہیں پاتے جنہیں وہ پہلے سے جانتے ہیں۔ سب کچھ الجھا ہوا اور غیر مانوس لگتا ہے، اور اسے استعمال کرنے کی کوشش کرنے سے پہلے ہی ایک مشکل سیکھنے کا مرحلہ ہوتا ہے۔ ایک صارف کچھ پیسے بچانے کی خواہش کے ساتھ DeFi سے رجوع کر سکتا ہے، اور اسے یہ ملتا ہے: مائننگ، فارمنگ، اسٹیکنگ، ایمیشنز، برائبس، والٹس، لاکرز، veTokens، ویسٹنگ، ایپوکس، وکندریقرت الگورتھم، پروٹوکول کی ملکیت والی لیکویڈیٹی... +سادہ اصطلاحات استعمال کرنے کی کوشش کریں جنہیں لوگوں کا وسیع ترین گروہ سمجھ سکے۔ صرف اپنے پروجیکٹ کے لیے بالکل نئی اصطلاحات ایجاد نہ کریں۔ + +**تجاویز:** + +- سادہ اور مستقل اصطلاحات استعمال کریں۔ +- جتنا ممکن ہو موجودہ زبان استعمال کریں۔ +- اپنی اصطلاحات نہ بنائیں۔ +- روایات پر عمل کریں جیسے ہی وہ ظاہر ہوں۔ +- صارفین کو جتنا ممکن ہو تعلیم دیں۔ + +**مثال:** +"آپ کے انعامات" ایک وسیع پیمانے پر سمجھی جانے والی، غیر جانبدار اصطلاح ہے؛ نہ کہ اس پروجیکٹ کے لیے بنایا گیا کوئی نیا لفظ۔ انعامات USD میں ظاہر کیے جاتے ہیں تاکہ حقیقی دنیا کے ذہنی ماڈلز سے مطابقت پیدا کی جا سکے، چاہے انعامات خود کسی دوسرے ٹوکن میں ہوں۔ + +![ٹوکن انعامات، امریکی ڈالر میں دکھائے گئے](./Image4.png) + +### 5. کارروائیاں جتنی ممکن ہو مختصر ہوں {#actions-are-as-short-as-possible} + +ذیلی کارروائیوں کو گروپ کرکے صارف کے تعاملات کو تیز کریں۔ +یہ اسمارٹ کنٹریکٹ کی سطح پر، اور ساتھ ہی UI پر بھی کیا جا سکتا ہے۔ صارف کو ایک عام کارروائی مکمل کرنے کے لیے سسٹم کے ایک حصے سے دوسرے حصے میں منتقل نہیں ہونا چاہیے – یا سسٹم کو مکمل طور پر چھوڑنا نہیں چاہیے۔ + +**تجاویز:** + +- جہاں ممکن ہو "منظور کریں" کو دیگر کارروائیوں کے ساتھ یکجا کریں۔ +- دستخط کرنے کے مراحل کو جتنا ممکن ہو قریب ایک ساتھ بنڈل کریں۔ + +**مثال:** "لیکویڈیٹی شامل کریں" اور "اسٹیک" کو یکجا کرنا ایک ایکسلریٹر کی ایک سادہ مثال ہے جو صارف کا وقت اور گیس دونوں بچاتا ہے۔ + +![ڈپازٹ اور اسٹیک کارروائیوں کو یکجا کرنے کے لیے ایک سوئچ دکھانے والا موڈل](./Image5.png) + +### 6. نیٹ ورک کنکشنز نظر آنے والے اور لچکدار ہیں {#network-connections-are-visible-and-flexible} + +صارف کو بتائیں کہ وہ کس نیٹ ورک سے جڑے ہیں، اور نیٹ ورک تبدیل کرنے کے لیے واضح شارٹ کٹ فراہم کریں۔ +یہ ملٹی چین ایپس پر خاص طور پر اہم ہے۔ ایپ کے اہم فنکشنز منقطع ہونے یا غیر معاونت یافتہ نیٹ ورک سے جڑنے پر بھی نظر آنے چاہئیں۔ + +**تجاویز:** + +- منقطع ہونے پر ایپ کو جتنا ممکن ہو دکھائیں۔ +- دکھائیں کہ صارف فی الحال کس نیٹ ورک سے جڑا ہوا ہے۔ +- صارف کو نیٹ ورک تبدیل کرنے کے لیے والیٹ پر نہ بھیجیں۔ +- اگر ایپ صارف سے نیٹ ورک تبدیل کرنے کا تقاضا کرتی ہے، تو مرکزی کال ٹو ایکشن سے کارروائی کا اشارہ دیں۔ +- اگر ایپ میں متعدد نیٹ ورکس کے لیے مارکیٹس یا والٹس ہیں، تو واضح طور پر بتائیں کہ صارف فی الحال کون سا سیٹ دیکھ رہا ہے۔ + +**مثال:** صارف کو دکھائیں کہ وہ کس نیٹ ورک سے جڑے ہیں، اور انہیں ایپ بار میں اسے تبدیل کرنے کی اجازت دیں۔ + +![منسلک نیٹ ورک دکھانے والا ڈراپ ڈاؤن بٹن](./Image6.png) + +### 7. ایپ سے کنٹرول کریں، والیٹ سے نہیں {#control-from-the-app-not-the-wallet} + +UI کو صارف کو وہ سب کچھ بتانا چاہیے جو انہیں جاننے کی ضرورت ہے اور انہیں ہر اس کام پر کنٹرول دینا چاہیے جو انہیں کرنے کی ضرورت ہے۔ +Web3 میں، کچھ کارروائیاں آپ UI میں کرتے ہیں، اور کچھ کارروائیاں آپ والیٹ میں کرتے ہیں۔ عام طور پر، آپ UI میں ایک کارروائی شروع کرتے ہیں، اور پھر اسے والیٹ میں تصدیق کرتے ہیں۔ اگر ان دو سلسلوں کو احتیاط سے مربوط نہ کیا جائے تو صارفین کو بے چینی محسوس ہو سکتی ہے۔ + +**تجاویز:** + +- UI میں فیڈبیک کے ذریعے سسٹم کی حالت بتائیں۔ +- ان کی تاریخ کا ریکارڈ رکھیں۔ +- پرانی ٹرانزیکشنز کے لیے بلاک ایکسپلوررز کے لنکس فراہم کریں۔ +- نیٹ ورکس تبدیل کرنے کے لیے شارٹ کٹ فراہم کریں۔ + +ایک غیر نمایاں کنٹینر صارف کو دکھاتا ہے کہ ان کے والیٹ میں کون سے متعلقہ ٹوکنز ہیں، اور مرکزی CTA نیٹ ورک کو تبدیل کرنے کے لیے ایک شارٹ کٹ فراہم کرتا ہے۔ + +![مرکزی CTA صارف کو نیٹ ورک تبدیل کرنے کا اشارہ دے رہا ہے](./Image7.png) diff --git a/public/content/translations/ur/developers/docs/design-and-ux/index.md b/public/content/translations/ur/developers/docs/design-and-ux/index.md new file mode 100644 index 00000000000..1b4d232fd97 --- /dev/null +++ b/public/content/translations/ur/developers/docs/design-and-ux/index.md @@ -0,0 +1,86 @@ +--- +title: "ویب 3 میں ڈیزائن اور UX" +description: "ویب 3 اسپیس اور ایتھیریم میں UX ڈیزائن اور تحقیق کا تعارف" +lang: ur-in +--- + +کیا آپ ایتھیریم کے ساتھ ڈیزائننگ میں نئے ہیں؟ یہ آپ کے لیے صحیح جگہ ہے۔ ایتھیریم کمیونٹی نے آپ کو ویب 3 ڈیزائن اور تحقیق کی بنیادی باتوں سے متعارف کرانے کے لیے وسائل لکھے ہیں۔ آپ ان بنیادی تصورات کے بارے میں جانیں گے جو ان دیگر ایپ ڈیزائنز سے مختلف ہو سکتے ہیں جن سے آپ واقف ہیں۔ + +پہلے ویب 3 کی مزید بنیادی سمجھ کی ضرورت ہے؟ [**Learn hub**](/learn/) دیکھیں۔ + +## صارف کی تحقیق سے شروع کریں {#start-with-user-research} + +مؤثر ڈیزائن بصری طور پر دلکش یوزر انٹرفیس بنانے سے کہیں بڑھ کر ہے۔ اس میں صارف کی ضروریات، مقاصد، اور محرک عوامل کی گہری سمجھ حاصل کرنا شامل ہے۔ لہذا، ہم تمام ڈیزائنرز کو سختی سے مشورہ دیتے ہیں کہ وہ ایک ڈیزائن پروسیس اپنائیں، جیسے کہ [**ڈبل ڈائمنڈ پروسیس**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\))، تاکہ یہ یقینی بنایا جا سکے کہ ان کا کام سوچا سمجھا اور جان بوجھ کر کیا گیا ہے۔ + +- [ویب 3 کو مزید UX محققین اور ڈیزائنرز کی ضرورت ہے](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - موجودہ ڈیزائن کی پختگی کا ایک جائزہ +- [ویب 3 میں UX تحقیق کے لیے ایک سادہ گائیڈ](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - تحقیق کرنے کا طریقہ کار پر ایک سادہ گائیڈ +- [ویب 3 میں UX فیصلوں تک کیسے پہنچیں](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - مقداری اور معیاری تحقیق کا ایک مختصر جائزہ اور دونوں کے درمیان فرق (ویڈیو، 6 منٹ) +- [ویب 3 میں ایک یو ایکس محقق ہونا](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - ویب 3 میں ایک UX محقق ہونے کے بارے میں ایک ذاتی نظریہ + +## ویب 3 میں تحقیقی مطالعے {#research-in-web3} + +یہ ویب 3 میں کی گئی صارف تحقیق کی ایک منتخب فہرست ہے جو ڈیزائن اور پروڈکٹ کے فیصلوں میں مدد کر سکتی ہے یا اپنا مطالعہ کرنے کے لیے ایک تحریک کے طور پر کام کر سکتی ہے۔ + +| توجہ کا مرکز | نام | +| :---------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| کرپٹو آن بورڈنگ | [The Reown Pulse 2024: Crypto Consumer Sentiment & Usage](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | +| کرپٹو آن بورڈنگ | [CRADL: کرپٹو کرنسی میں UX](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| کرپٹو آن بورڈنگ | [CRADL: کرپٹو کرنسی میں آن بورڈنگ](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| کرپٹو آن بورڈنگ | [بٹ کوائن UX رپورٹ](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| کرپٹو آن بورڈنگ | [ConSensys: دنیا بھر میں ویب 3 کے تاثر کی حالت 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| کرپٹو آن بورڈنگ | [NEAR: اپنانے کی طرف سفر کو تیز کرنا](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| اسٹیکنگ | [OpenUX: راکٹ پول نوڈ آپریٹر UX](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| اسٹیکنگ | [اسٹیکنگ: کلیدی رجحانات، اہم نکات، اور پیشین گوئیاں - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| اسٹیکنگ | [ملٹی ایپ اسٹیکنگ](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [2022 DAO ریسرچ اپ ڈیٹ: DAO بنانے والوں کو کیا چاہیے؟](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [کوریج پولز](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [ConSensys: DeFi یوزر ریسرچ رپورٹ 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| میٹاورس | [میٹاورس: یوزر ریسرچ رپورٹ](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| میٹاورس | [سفاری پر جانا: میٹاورس میں صارفین کی تحقیق](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (ویڈیو، 27 منٹ) | + +## ویب 3 کے لیے ڈیزائن {#design-for-web3} + +- [ویب 3 UX ڈیزائن ہینڈ بک](https://web3ux.design/) - ویب 3 ایپس کو ڈیزائن کرنے کے لیے عملی گائیڈ +- [ویب 3 ڈیزائن کے اصول](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - بلاک چین پر مبنی dapps کے لیے UX قوانین کا ایک فریم ورک +- [بلاک چین ڈیزائن کے اصول](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - IBM کی بلاک چین ڈیزائن ٹیم سے سیکھے گئے اسباق +- [Neueux.com](https://neueux.com/apps) - متنوع فلٹرنگ کے اختیارات کے ساتھ یوزر فلو کی UI لائبریری +- [ویب 3 کا استعمال کا بحران: آپ کو کیا جاننے کی ضرورت ہے!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - ڈیولپر مرکوز پروجیکٹ کی تعمیر کی خامیوں پر ایک پینل بحث (ویڈیو، 34 منٹ) + +## شروع کرنا {#getting-started} + +- [ویب 3 کے لیے ہیورسٹکس](/developers/docs/design-and-ux/heuristics-for-web3/) - ویب 3 انٹرفیس ڈیزائن کے لیے 7 ہیورسٹکس +- [DEX ڈیزائن کے بہترین طریقے](/developers/docs/design-and-ux/dex-design-best-practice/) - ڈی سینٹرالائزڈ ایکسچینجز (DEX) کو ڈیزائن کرنے کے لیے ایک گائیڈ + +## ویب 3 ڈیزائن کیس اسٹڈیز {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) +- [OpenSea پر ایک NFT فروخت کرنا](https://builtformars.com/case-studies/opensea) +- [والیٹ UX کا تجزیہ: والیٹس کو کیسے بدلنے کی ضرورت ہے](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (ویڈیو، 20 منٹ) + +## ڈیزائن باؤنٹیز {#bounties} + +- [Dework](https://app.dework.xyz/bounties) +- [Buildbox ہیکاتھنز](https://app.buidlbox.io/) +- [ETHGlobal ہیکاتھنز](https://ethglobal.com/) + +## ڈیزائن DAOs اور کمیونٹیز {#design-daos-and-communities} + +پیشہ ورانہ کمیونٹی سے چلنے والی تنظیموں میں شامل ہوں یا دوسرے ممبران کے ساتھ ڈیزائن اور تحقیق سے متعلقہ موضوعات اور رجحانات پر تبادلہ خیال کرنے کے لیے ڈیزائن گروپس میں شامل ہوں۔ + +- [Vectordao.com](https://vectordao.com/) +- [Deepwork.studio](https://www.deepwork.studio/) +- [We3.co](https://we3.co/) +- [Openux.xyz](https://openux.xyz/) + +## ڈیزائن سسٹمز اور دیگر ڈیزائن وسائل {#design-systems-and-resources} + +- [Optimism ڈیزائن](https://www.figma.com/@optimism) (Figma) +- [Ethereum.org ڈیزائن سسٹم](https://www.figma.com/@ethdotorg) (Figma) +- [Finity، پولی گون کا ایک ڈیزائن سسٹم](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) +- [Kleros ڈیزائن سسٹم](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) +- [Safe ڈیزائن سسٹم](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) +- [ENS ڈیزائن سسٹم](https://thorin.ens.domains/) +- [Mirror ڈیزائن سسٹم](https://degen-xyz.vercel.app/) + +**اس صفحہ پر درج مضامین اور پروجیکٹس سرکاری توثیق نہیں ہیں**، اور صرف معلوماتی مقاصد کے لیے فراہم کیے گئے ہیں۔ +ہم اپنی [لسٹنگ پالیسی](/contributing/design/adding-design-resources) میں موجود معیارات کی بنیاد پر اس صفحے پر لنکس شامل کرتے ہیں۔ اگر آپ چاہتے ہیں کہ ہم کوئی پروجیکٹ/مضمون شامل کریں، تو اس صفحہ کو [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) پر ایڈٹ کریں۔ diff --git a/public/content/translations/ur/developers/docs/development-networks/index.md b/public/content/translations/ur/developers/docs/development-networks/index.md new file mode 100644 index 00000000000..d7e61770d63 --- /dev/null +++ b/public/content/translations/ur/developers/docs/development-networks/index.md @@ -0,0 +1,71 @@ +--- +title: "ڈیولپمنٹ نیٹ ورکس" +description: "ڈیولپمنٹ نیٹ ورکس اور ایتھیریم ایپلیکیشنز بنانے میں مدد کے لیے دستیاب ٹولز کا ایک جائزہ۔" +lang: ur-in +--- + +اسمارٹ کنٹریکٹس کے ساتھ ایتھیریم ایپلیکیشن بناتے وقت، آپ اسے ڈیپلائے کرنے سے پہلے یہ دیکھنے کے لیے کہ یہ کیسے کام کرتا ہے، اسے مقامی نیٹ ورک پر چلانا چاہیں گے۔ + +اسی طرح جیسے آپ ویب ڈیولپمنٹ کے لیے اپنے کمپیوٹر پر ایک لوکل سرور چلا سکتے ہیں، آپ اپنی dapp کو ٹیسٹ کرنے کے لیے ایک لوکل بلاک چین انسٹینس بنانے کے لیے ڈیولپمنٹ نیٹ ورک کا استعمال کر سکتے ہیں۔ یہ ایتھیریم ڈیولپمنٹ نیٹ ورکس ایسی خصوصیات فراہم کرتے ہیں جو پبلک ٹیسٹ نیٹ کے مقابلے میں بہت تیز تکرار کی اجازت دیتے ہیں (مثال کے طور پر آپ کو ٹیسٹ نیٹ فاسیٹ سے ETH حاصل کرنے کی ضرورت نہیں ہے)۔ + +## شرائط {#prerequisites} + +ڈیولپمنٹ نیٹ ورکس میں غوطہ لگانے سے پہلے آپ کو [ایتھیریم اسٹیک کی بنیادی باتیں](/developers/docs/ethereum-stack/) اور [ایتھیریم نیٹ ورکس](/developers/docs/networks/) کو سمجھنا چاہیے۔ + +## ڈیولپمنٹ نیٹ ورک کیا ہے؟ {#what-is-a-development-network} + +ڈیولپمنٹ نیٹ ورکس بنیادی طور پر ایتھیریم کلائنٹس ہیں (ایتھیریم کے نفاذ) جو خاص طور پر لوکل ڈیولپمنٹ کے لیے بنائے گئے ہیں۔ + +**صرف مقامی طور پر ایک معیاری ایتھیریم نوڈ کیوں نہیں چلاتے؟** + +آپ [ایک نوڈ چلا سکتے ہیں](/developers/docs/nodes-and-clients/#running-your-own-node) لیکن چونکہ ڈیولپمنٹ نیٹ ورکس ڈیولپمنٹ کے لیے ہی بنائے گئے ہیں، اس لیے وہ اکثر آسان خصوصیات کے ساتھ آتے ہیں جیسے: + +- ڈیٹا (مثال کے طور پر، ETH بیلنس والے اکاؤنٹس) کے ساتھ اپنے مقامی بلاک چین کو قطعی طور پر سیڈ کرنا +- ہر ٹرانزیکشن کے ساتھ فوری طور پر بلاکس تیار کرنا، ترتیب میں اور بغیر کسی تاخیر کے +- بہتر ڈیبگنگ اور لاگنگ فنکشنلٹی + +## دستیاب ٹولز {#available-projects} + +**نوٹ**: زیادہ تر [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) میں ایک بلٹ ان ڈیولپمنٹ نیٹ ورک شامل ہوتا ہے۔ ہم آپ کے [مقامی ڈیولپمنٹ اینوائرمنٹ کو سیٹ کرنے](/developers/local-environment/) کے لیے ایک فریم ورک کے ساتھ شروع کرنے کی تجویز کرتے ہیں۔ + +### Hardhat نیٹ ورک {#hardhat-network} + +ڈیولپمنٹ کے لیے ڈیزائن کیا گیا ایک لوکل ایتھیریم نیٹ ورک۔ یہ آپ کو اپنے کنٹریکٹس کو ڈیپلائے کرنے، اپنے ٹیسٹ چلانے اور اپنے کوڈ کو ڈیبگ کرنے کی اجازت دیتا ہے۔ + +Hardhat نیٹ ورک Hardhat کے ساتھ بلٹ ان آتا ہے، جو پیشہ ور افراد کے لیے ایک ایتھیریم ڈیولپمنٹ اینوائرمنٹ ہے۔ + +- [ویب سائٹ](https://hardhat.org/) +- [GitHub](https://github.com/NomicFoundation/hardhat) + +### لوکل بیکن چینز {#local-beacon-chains} + +کچھ کنسینسس کلائنٹس کے پاس ٹیسٹنگ کے مقاصد کے لیے لوکل بیکن چینز کو اسپن اپ کرنے کے لیے بلٹ ان ٹولز ہوتے ہیں۔ Lighthouse, Nimbus اور Lodestar کے لیے ہدایات دستیاب ہیں: + +- [Lodestar کا استعمال کرتے ہوئے لوکل ٹیسٹ نیٹ](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) +- [Lighthouse کا استعمال کرتے ہوئے لوکل ٹیسٹ نیٹ](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) + +### پبلک ایتھیریم ٹیسٹ چینز {#public-beacon-testchains} + +ایتھیریم کے دو برقرار رکھے ہوئے پبلک ٹیسٹ نفاذ بھی ہیں: Sepolia اور Hoodi۔ طویل مدتی سپورٹ کے ساتھ تجویز کردہ ٹیسٹ نیٹ Hoodi ہے، جس پر کوئی بھی ویلیڈیٹ کرنے کے لیے آزاد ہے۔ Sepolia ایک اجازت یافتہ ویلیڈیٹر سیٹ کا استعمال کرتا ہے، جس کا مطلب ہے کہ اس ٹیسٹ نیٹ پر نئے ویلیڈیٹرز تک عمومی رسائی نہیں ہے۔ + +- [Hoodi اسٹیکنگ لانچ پیڈ](https://hoodi.launchpad.ethereum.org/) + +### Kurtosis ایتھیریم پیکیج {#kurtosis} + +Kurtosis ملٹی کنٹینر ٹیسٹ اینوائرنمنٹس کے لیے ایک بلڈ سسٹم ہے جو ڈیولپرز کو مقامی طور پر بلاک چین نیٹ ورکس کے دوبارہ قابل تولید انسٹینس کو اسپن اپ کرنے کے قابل بناتا ہے۔ + +ایتھیریم Kurtosis پیکیج کو Docker یا Kubernetes پر ایک پیرامیٹرائز ایبل، انتہائی اسکیل ایبل، اور نجی ایتھیریم ٹیسٹ نیٹ کو تیزی سے انسٹینشیئٹ کرنے کے لیے استعمال کیا جا سکتا ہے۔ یہ پیکیج تمام بڑے ایگزیکیوشن لیئر (EL) اور کنسینسس لیئر (CL) کلائنٹس کو سپورٹ کرتا ہے۔ Kurtosis ایتھیریم کور انفراسٹرکچر سے متعلق ویلیڈیشن اور ٹیسٹنگ ورک فلوز میں استعمال ہونے والے نمائندہ نیٹ ورک کے لیے تمام لوکل پورٹ میپنگز اور سروس کنکشنز کو احسن طریقے سے ہینڈل کرتا ہے۔ + +- [ایتھیریم نیٹ ورک پیکیج](https://github.com/kurtosis-tech/ethereum-package) +- [ویب سائٹ](https://www.kurtosis.com/) +- [GitHub](https://github.com/kurtosis-tech/kurtosis) +- [ڈاکیومینٹیشن](https://docs.kurtosis.com/) + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) +- [ایک مقامی ڈیولپمنٹ اینوائرمنٹ سیٹ اپ کریں](/developers/local-environment/) diff --git a/public/content/translations/ur/developers/docs/ethereum-stack/index.md b/public/content/translations/ur/developers/docs/ethereum-stack/index.md new file mode 100644 index 00000000000..1186540be08 --- /dev/null +++ b/public/content/translations/ur/developers/docs/ethereum-stack/index.md @@ -0,0 +1,61 @@ +--- +title: "ایتھریم اسٹیک کا تعارف" +description: "ایتھریم اسٹیک کی مختلف تہوں کا ایک واک تھرو اور وہ ایک ساتھ کیسے فٹ ہوتے ہیں۔" +lang: ur-in +--- + +کسی بھی سافٹ ویئر اسٹیک کی طرح، مکمل "ایتھریم اسٹیک" آپ کے مقاصد کے لحاظ سے پروجیکٹ سے پروجیکٹ میں مختلف ہوگا۔ + +تاہم، ایتھریم کے بنیادی اجزاء ہیں جو اس بات کے لیے ذہنی ماڈل فراہم کرنے میں مدد کرتے ہیں کہ سافٹ ویئر ایپلی کیشنز ایتھریم بلاک چین کے ساتھ کیسے تعامل کرتی ہیں۔ اسٹیک کی تہوں کو سمجھنے سے آپ کو ان مختلف طریقوں کو سمجھنے میں مدد ملے گی جن سے ایتھریم کو سافٹ ویئر پروجیکٹس میں ضم کیا جا سکتا ہے۔ + +## سطح 1: ایتھریم ورچوئل مشین {#ethereum-virtual-machine} + +[ایتھریم ورچوئل مشین (EVM)](/developers/docs/evm/) ایتھریم پر اسمارٹ کنٹریکٹس کے لیے رن ٹائم ماحول ہے۔ ایتھریم بلاک چین پر تمام اسمارٹ کنٹریکٹس اور اسٹیٹ کی تبدیلیاں [ٹرانزیکشنز](/developers/docs/transactions/) کے ذریعے انجام دی جاتی ہیں۔ EVM ایتھریم نیٹ ورک پر تمام ٹرانزیکشن پروسیسنگ کو ہینڈل کرتا ہے۔ + +کسی بھی ورچوئل مشین کی طرح، EVM ایگزیکیوٹنگ کوڈ اور ایگزیکیوٹنگ مشین (ایک ایتھریم نوڈ) کے درمیان ایبسٹریکشن کی ایک سطح بناتا ہے۔ فی الحال، EVM دنیا بھر میں تقسیم شدہ ہزاروں نوڈز پر چل رہا ہے۔ + +پس پردہ، EVM مخصوص کاموں کو انجام دینے کے لیے اوپ کوڈ ہدایات کا ایک سیٹ استعمال کرتا ہے۔ یہ (140 منفرد) اوپ کوڈز EVM کو [ٹیورنگ-کمپلیٹ](https://en.wikipedia.org/wiki/Turing_completeness) ہونے کی اجازت دیتے ہیں، جس کا مطلب ہے کہ کافی وسائل دیے جانے پر EVM تقریباً کچھ بھی شمار کرنے کے قابل ہے۔ + +ایک dApp ڈیولپر کے طور پر، آپ کو EVM کے بارے میں اس کے علاوہ بہت کچھ جاننے کی ضرورت نہیں ہے کہ یہ موجود ہے اور یہ کہ یہ بغیر کسی ڈاؤن ٹائم کے ایتھریم پر تمام ایپلی کیشنز کو قابل اعتماد طریقے سے طاقت دیتا ہے۔ + +## سطح 2: اسمارٹ کنٹریکٹس {#smart-contracts} + +[اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) قابل عمل پروگرام ہیں جو ایتھریم بلاک چین پر چلتے ہیں۔ + +اسمارٹ کنٹریکٹس مخصوص [پروگرامنگ زبانوں](/developers/docs/smart-contracts/languages/) کا استعمال کرتے ہوئے لکھے جاتے ہیں جو EVM بائٹ کوڈ (اوپ کوڈز کہلانے والی نچلی سطح کی مشین ہدایات) میں کمپائل ہوتے ہیں۔ + +اسمارٹ کنٹریکٹس نہ صرف اوپن سورس لائبریریوں کے طور پر کام کرتے ہیں، بلکہ وہ بنیادی طور پر کھلی API خدمات ہیں جو ہمیشہ چلتی رہتی ہیں اور انہیں بند نہیں کیا جا سکتا۔ اسمارٹ کنٹریکٹس عوامی فنکشنز فراہم کرتے ہیں جن کے ساتھ صارفین اور ایپلی کیشنز ([dApps](/developers/docs/dapps/)) بغیر اجازت کے تعامل کر سکتے ہیں۔ کوئی بھی ایپلیکیشن تعینات شدہ اسمارٹ کنٹریکٹس کے ساتھ فعالیت کو کمپوز کرنے کے لیے ضم ہو سکتی ہے، جیسے [ڈیٹا فیڈز](/developers/docs/oracles/) شامل کرنا یا ٹوکن سویپس کو سپورٹ کرنا۔ مزید برآں، کوئی بھی اپنی ایپلیکیشن کی ضروریات کو پورا کرنے کے لیے حسب ضرورت فعالیت شامل کرنے کے لیے ایتھریم پر نئے اسمارٹ کنٹریکٹس تعینات کر سکتا ہے۔ + +ایک dApp ڈیولپر کے طور پر، آپ کو صرف اس صورت میں اسمارٹ کنٹریکٹس لکھنے کی ضرورت ہوگی جب آپ ایتھریم بلاک چین پر حسب ضرورت فعالیت شامل کرنا چاہتے ہوں۔ آپ کو معلوم ہو سکتا ہے کہ آپ اپنے پروجیکٹ کی زیادہ تر یا تمام ضروریات کو محض موجودہ اسمارٹ کنٹریکٹس کے ساتھ ضم کر کے پورا کر سکتے ہیں، مثال کے طور پر اگر آپ اسٹیبل کوائنز میں ادائیگیوں کو سپورٹ کرنا چاہتے ہیں یا ٹوکنز کے غیر مرکزی تبادلے کو فعال کرنا چاہتے ہیں۔ + +## سطح 3: ایتھریم نوڈز {#ethereum-nodes} + +ایک ایپلیکیشن کو ایتھریم بلاک چین کے ساتھ تعامل کرنے کے لیے، اسے ایک [ایتھریم نوڈ](/developers/docs/nodes-and-clients/) سے جڑنا ہوگا۔ ایک نوڈ سے جڑنے سے آپ کو بلاک چین ڈیٹا پڑھنے اور/یا نیٹ ورک پر ٹرانزیکشنز بھیجنے کی اجازت ملتی ہے۔ + +ایتھریم نوڈز سافٹ ویئر چلانے والے کمپیوٹر ہیں - ایک ایتھریم کلائنٹ۔ ایک کلائنٹ ایتھریم کا نفاذ ہے جو ہر بلاک میں تمام ٹرانزیکشنز کی تصدیق کرتا ہے، نیٹ ورک کو محفوظ اور ڈیٹا کو درست رکھتا ہے۔ **ایتھریم نوڈز ہی ایتھریم بلاک چین ہیں**۔ وہ اجتماعی طور پر ایتھریم بلاک چین کی حالت کو ذخیرہ کرتے ہیں اور بلاک چین کی حالت کو تبدیل کرنے کے لیے ٹرانزیکشنز پر اتفاق رائے تک پہنچتے ہیں۔ + +اپنی ایپلیکیشن کو ایتھریم نوڈ سے جوڑ کر ([JSON-RPC API](/developers/docs/apis/json-rpc/) کے ذریعے)، آپ کی ایپلیکیشن بلاک چین سے ڈیٹا پڑھنے کے قابل ہے (جیسے صارف کے اکاؤنٹ کا بیلنس) اور ساتھ ہی نیٹ ورک پر نئی ٹرانزیکشنز کو براڈکاسٹ کرنے کے بھی قابل ہے (جیسے صارف کے اکاؤنٹس کے درمیان ETH منتقل کرنا یا اسمارٹ کنٹریکٹس کے فنکشنز کو انجام دینا)۔ + +## سطح 4: ایتھریم کلائنٹ APIs {#ethereum-client-apis} + +بہت سی سہولت والی لائبریریاں (ایتھریم کی اوپن سورس کمیونٹی کے ذریعہ بنائی اور برقرار رکھی گئی) آپ کی ایپلی کیشنز کو ایتھریم بلاک چین سے جڑنے اور بات چیت کرنے کی اجازت دیتی ہیں۔ + +اگر آپ کی صارف کا سامنا کرنے والی ایپلیکیشن ایک ویب ایپ ہے، تو آپ اپنے فرنٹ اینڈ میں براہ راست ایک [جاوا اسکرپٹ API](/developers/docs/apis/javascript/) کو `npm install` کرنے کا انتخاب کر سکتے ہیں۔ یا شاید آپ اس فعالیت کو سرور کی طرف نافذ کرنے کا انتخاب کریں گے، ایک [پائتھون](/developers/docs/programming-languages/python/) یا [جاوا](/developers/docs/programming-languages/java/) API کا استعمال کرتے ہوئے۔ + +اگرچہ یہ APIs اسٹیک کا لازمی حصہ نہیں ہیں، لیکن وہ ایتھریم نوڈ کے ساتھ براہ راست تعامل کرنے کی بہت سی پیچیدگی کو دور کر دیتی ہیں۔ وہ یوٹیلیٹی فنکشنز بھی فراہم کرتے ہیں (مثلاً، ETH کو Gwei میں تبدیل کرنا) تاکہ ایک ڈیولپر کے طور پر آپ ایتھریم کلائنٹس کی پیچیدگیوں سے نمٹنے میں کم وقت صرف کر سکیں اور اپنی ایپلیکیشن کے لیے مخصوص فعالیت پر زیادہ وقت مرکوز کر سکیں۔ + +## سطح 5: اختتامی صارف کی ایپلی کیشنز {#end-user-applications} + +اسٹیک کی سب سے اوپری سطح پر صارف کا سامنا کرنے والی ایپلی کیشنز ہیں۔ یہ وہ معیاری ایپلی کیشنز ہیں جو آپ آج باقاعدگی سے استعمال کرتے اور بناتے ہیں: بنیادی طور پر ویب اور موبائل ایپس۔ + +جس طرح سے آپ یہ یوزر انٹرفیس تیار کرتے ہیں وہ بنیادی طور پر غیر تبدیل شدہ رہتا ہے۔ اکثر صارفین کو یہ جاننے کی ضرورت نہیں ہوگی کہ وہ جو ایپلیکیشن استعمال کر رہے ہیں وہ بلاک چین کا استعمال کرتے ہوئے بنائی گئی ہے۔ + +## اپنا اسٹیک منتخب کرنے کے لیے تیار ہیں؟ {#ready-to-choose-your-stack} + +اپنی ایتھریم ایپلیکیشن کے لیے [مقامی ترقیاتی ماحول قائم کرنے](/developers/local-environment/) کے لیے ہماری گائیڈ دیکھیں۔ + +## مزید پڑھیں {#further-reading} + +- [The Architecture of a Web 3.0 application](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/evm/index.md b/public/content/translations/ur/developers/docs/evm/index.md new file mode 100644 index 00000000000..51ae2502a58 --- /dev/null +++ b/public/content/translations/ur/developers/docs/evm/index.md @@ -0,0 +1,88 @@ +--- +title: "Ethereum ورچوئل مشین (EVM)" +description: "Ethereum ورچوئل مشین کا تعارف اور یہ کہ یہ اسٹیٹ، ٹرانزیکشنز، اور اسمارٹ کنٹریکٹس سے کیسے متعلق ہے۔" +lang: ur-in +--- + +Ethereum ورچوئل مشین (EVM) ایک ڈی سینٹرلائزڈ ورچوئل ماحول ہے جو تمام Ethereum نوڈس پر کوڈ کو مستقل اور محفوظ طریقے سے چلاتا ہے۔ نوڈس اسمارٹ کنٹریکٹس کو چلانے کے لیے EVM چلاتے ہیں، [آپریشنز](/developers/docs/evm/opcodes/) کے لیے درکار کمپیوٹیشنل کوشش کی پیمائش کے لیے "[گیس](/developers/docs/gas/)" کا استعمال کرتے ہیں، جس سے وسائل کی موثر تقسیم اور نیٹ ورک کی سیکیورٹی کو یقینی بنایا جاتا ہے۔ + +## شرائط {#prerequisites} + +EVM کو سمجھنے کے لیے کمپیوٹر سائنس میں عام اصطلاحات جیسے [بائٹس](https://wikipedia.org/wiki/Byte)، [میموری](https://wikipedia.org/wiki/Computer_memory)، اور [اسٹیک](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)) سے کچھ بنیادی واقفیت ضروری ہے۔ یہ کرپٹوگرافی/بلاک چین کے تصورات جیسے [ہیش فنکشنز](https://wikipedia.org/wiki/Cryptographic_hash_function) اور [مرکل ٹری](https://wikipedia.org/wiki/Merkle_tree) سے واقف ہونے میں بھی مددگار ثابت ہوگا۔ + +## لیجر سے اسٹیٹ مشین تک {#from-ledger-to-state-machine} + +ایک 'ڈسٹریبیوٹڈ لیجر' کا موازنہ اکثر Bitcoin جیسے بلاک چینز کو بیان کرنے کے لیے استعمال کیا جاتا ہے، جو کرپٹوگرافی کے بنیادی ٹولز کا استعمال کرتے ہوئے ایک ڈی سینٹرلائزڈ کرنسی کو فعال کرتے ہیں۔ لیجر سرگرمی کا ایک ریکارڈ برقرار رکھتا ہے جسے قوانین کے ایک سیٹ پر عمل کرنا ہوتا ہے جو اس بات پر حکمرانی کرتے ہیں کہ کوئی لیجر میں ترمیم کرنے کے لیے کیا کر سکتا ہے اور کیا نہیں کر سکتا۔ مثال کے طور پر، ایک Bitcoin ایڈریس اس سے زیادہ Bitcoin خرچ نہیں کر سکتا جتنا اس نے پہلے حاصل کیا ہے۔ یہ قوانین Bitcoin اور بہت سے دوسرے بلاک چینز پر تمام ٹرانزیکشنز کی بنیاد ہیں۔ + +جبکہ Ethereum کی اپنی مقامی کرپٹو کرنسی (ether) ہے جو تقریباً انہی بدیہی قوانین پر عمل کرتی ہے، یہ ایک بہت زیادہ طاقتور فنکشن کو بھی فعال کرتا ہے: [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/)۔ اس زیادہ پیچیدہ خصوصیت کے لیے، ایک زیادہ نفیس موازنہ درکار ہے۔ ایک ڈسٹریبیوٹڈ لیجر کے بجائے، Ethereum ایک ڈسٹریبیوٹڈ [اسٹیٹ مشین](https://wikipedia.org/wiki/Finite-state_machine) ہے۔ Ethereum کا اسٹیٹ ایک بڑا ڈیٹا اسٹرکچر ہے جس میں نہ صرف تمام اکاؤنٹس اور بیلنس ہوتے ہیں، بلکہ ایک _مشین اسٹیٹ_ بھی ہوتا ہے، جو پہلے سے طے شدہ قوانین کے ایک سیٹ کے مطابق بلاک سے بلاک میں تبدیل ہو سکتا ہے، اور جو کسی بھی مشین کوڈ کو چلا سکتا ہے۔ بلاک سے بلاک میں اسٹیٹ کو تبدیل کرنے کے مخصوص قوانین EVM کے ذریعے بیان کیے گئے ہیں۔ + +![EVM کی ساخت کو دکھانے والا ایک ڈایاگرام](./evm.png) +_ڈایاگرام [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے لیا گیا ہے_ + +## Ethereum اسٹیٹ ٹرانزیشن فنکشن {#the-ethereum-state-transition-function} + +EVM ایک ریاضیاتی فنکشن کی طرح برتاؤ کرتا ہے: ایک ان پٹ دیے جانے پر، یہ ایک ڈیٹرمینسٹک آؤٹ پٹ پیدا کرتا ہے۔ لہذا Ethereum کو رسمی طور پر **اسٹیٹ ٹرانزیشن فنکشن** کے طور پر بیان کرنا کافی مددگار ہے: + +``` +Y(S, T)= S' +``` + +ایک پرانے درست اسٹیٹ `(S)` اور درست ٹرانزیکشنز کے ایک نئے سیٹ `(T)` کو دیکھتے ہوئے، Ethereum اسٹیٹ ٹرانزیشن فنکشن `Y(S, T)` ایک نیا درست آؤٹ پٹ اسٹیٹ `S'` پیدا کرتا ہے۔ + +### اسٹیٹ {#state} + +Ethereum کے تناظر میں، اسٹیٹ ایک بہت بڑا ڈیٹا اسٹرکچر ہے جسے [موڈیفائیڈ مرکل پیٹریشیا ٹرائی](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) کہا جاتا ہے، جو تمام [اکاؤنٹس](/developers/docs/accounts/) کو ہیشز کے ذریعے جوڑ کر رکھتا ہے اور بلاک چین پر اسٹور کیے گئے ایک واحد روٹ ہیش تک کم کیا جا سکتا ہے۔ + +### ٹرانزیکشنز {#transactions} + +ٹرانزیکشنز اکاؤنٹس سے بھیجی گئی کرپٹوگرافک طور پر دستخط شدہ ہدایات ہیں۔ ٹرانزیکشنز کی دو قسمیں ہیں: وہ جن کے نتیجے میں میسیج کالز ہوتی ہیں اور وہ جن کے نتیجے میں کنٹریکٹ کی تخلیق ہوتی ہے۔ + +کنٹریکٹ کی تخلیق کے نتیجے میں ایک نیا کنٹریکٹ اکاؤنٹ بنتا ہے جس میں کمپائلڈ [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/anatomy/) بائٹ کوڈ ہوتا ہے۔ جب بھی کوئی دوسرا اکاؤنٹ اس کنٹریکٹ کو میسیج کال کرتا ہے، تو یہ اپنے بائٹ کوڈ کو چلاتا ہے۔ + +## EVM ہدایات {#evm-instructions} + +EVM 1024 آئٹمز کی گہرائی کے ساتھ ایک [اسٹیک مشین](https://wikipedia.org/wiki/Stack_machine) کے طور پر کام کرتا ہے۔ ہر آئٹم ایک 256-بٹ ورڈ ہے، جسے 256-بٹ کرپٹوگرافی (جیسے Keccak-256 ہیشز یا secp256k1 سگنیچرز) کے ساتھ استعمال میں آسانی کے لیے منتخب کیا گیا تھا۔ + +ایگزیکیوشن کے دوران، EVM ایک عارضی _میموری_ (ایک ورڈ-ایڈریسڈ بائٹ ارے کے طور پر) برقرار رکھتا ہے، جو ٹرانزیکشنز کے درمیان برقرار نہیں رہتی۔ + +### عارضی اسٹوریج + +عارضی اسٹوریج ایک فی ٹرانزیکشن کی-ویلیو اسٹور ہے جس تک `TSTORE` اور `TLOAD` آپ کوڈز کے ذریعے رسائی حاصل کی جاتی ہے۔ یہ ایک ہی ٹرانزیکشن کے دوران تمام اندرونی کالز میں برقرار رہتا ہے لیکن ٹرانزیکشن کے آخر میں صاف ہو جاتا ہے۔ میموری کے برعکس، عارضی اسٹوریج کو ایگزیکیوشن فریم کے بجائے EVM اسٹیٹ کے حصے کے طور پر ماڈل کیا گیا ہے، پھر بھی اسے عالمی اسٹیٹ کے لیے کمٹ نہیں کیا جاتا ہے۔ عارضی اسٹوریج ایک ٹرانزیکشن کے دوران اندرونی کالز میں گیس-موثر عارضی اسٹیٹ شیئرنگ کو قابل بناتا ہے۔ + +### اسٹوریج + +کنٹریکٹس میں ایک مرکل پیٹریشیا _اسٹوریج_ ٹرائی (ایک ورڈ-ایڈریسڈ ورڈ ارے کے طور پر) ہوتا ہے، جو زیرِ بحث اکاؤنٹ سے وابستہ اور عالمی اسٹیٹ کا حصہ ہے۔ یہ مستقل اسٹوریج عارضی اسٹوریج سے مختلف ہے، جو صرف ایک ٹرانزیکشن کی مدت کے لیے دستیاب ہے اور اکاؤنٹ کے مستقل اسٹوریج ٹرائی کا حصہ نہیں بنتا۔ + +### Opcodes + +کمپائلڈ اسمارٹ کنٹریکٹ بائٹ کوڈ کئی EVM [آپ کوڈز](/developers/docs/evm/opcodes) کے طور پر چلتا ہے، جو معیاری اسٹیک آپریشنز جیسے `XOR`، `AND`، `ADD`، `SUB`، وغیرہ انجام دیتے ہیں۔ EVM بلاک چین کے لیے مخصوص کئی اسٹیک آپریشنز کو بھی نافذ کرتا ہے، جیسے `ADDRESS`، `BALANCE`، `BLOCKHASH`، وغیرہ۔ آپ کوڈ سیٹ میں `TSTORE` اور `TLOAD` بھی شامل ہیں، جو عارضی اسٹوریج تک رسائی فراہم کرتے ہیں۔ + +![ایک ڈایاگرام جو دکھاتا ہے کہ EVM آپریشنز کے لیے گیس کی کہاں ضرورت ہے](../gas/gas.png) +_ڈایاگرام [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے لیے گئے ہیں_ + +## EVM نفاذ {#evm-implementations} + +EVM کے تمام نفاذ کو Ethereum ییلو پیپر میں بیان کردہ تفصیلات پر عمل کرنا چاہیے۔ + +Ethereum کی دس سالہ تاریخ میں، EVM میں کئی بار نظرثانی کی گئی ہے، اور مختلف پروگرامنگ زبانوں میں EVM کے کئی نفاذ موجود ہیں۔ + +[Ethereum ایگزیکیوشن کلائنٹس](/developers/docs/nodes-and-clients/#execution-clients) میں ایک EVM نفاذ شامل ہے۔ اس کے علاوہ، متعدد اسٹینڈ الون نفاذ ہیں، بشمول: + +- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ +- [evmone](https://github.com/ethereum/evmone) - _C++_ +- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ +- [revm](https://github.com/bluealloy/revm) - _Rust_ + +## مزید مطالعہ {#further-reading} + +- [Ethereum ییلو پیپر](https://ethereum.github.io/yellowpaper/paper.pdf) +- [جیلو پیپر عرف KEVM: K میں EVM کے سیمنٹکس](https://jellopaper.org/) +- [دی بیج پیپر](https://github.com/chronaeon/beigepaper) +- [Ethereum ورچوئل مشین آپ کوڈز](https://www.ethervm.io/) +- [Ethereum ورچوئل مشین آپ کوڈز انٹرایکٹو حوالہ](https://www.evm.codes/) +- [Solidity کی ڈاکومنٹیشن میں ایک مختصر تعارف](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) +- [ماسٹرنگ Ethereum - دی Ethereum ورچوئل مشین](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) + +## متعلقہ موضوعات {#related-topics} + +- [گیس](/developers/docs/gas/) diff --git a/public/content/translations/ur/developers/docs/evm/opcodes/index.md b/public/content/translations/ur/developers/docs/evm/opcodes/index.md new file mode 100644 index 00000000000..99d4d2d436a --- /dev/null +++ b/public/content/translations/ur/developers/docs/evm/opcodes/index.md @@ -0,0 +1,177 @@ +--- +title: "ای وی ایم کے لیے آپ کوڈز" +description: "ایتھیریم ورچوئل مشین کے لیے تمام دستیاب آپ کوڈز کی ایک فہرست۔" +lang: ur-in +--- + +## جائزہ {#overview} + +یہ [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) پر ای وی ایم حوالہ جاتی صفحہ کا ایک اپڈیٹ شدہ ورژن ہے۔ +[Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)، [Jello Paper](https://jellopaper.org/evm/)، اور [geth](https://github.com/ethereum/go-ethereum) کے نفاذ سے بھی لیا گیا ہے۔ +اس کا مقصد ایک قابل رسائی حوالہ ہونا ہے، لیکن یہ خاص طور پر سخت نہیں ہے۔ +اگر آپ درستگی کا یقین کرنا چاہتے ہیں اور ہر ایج کیس سے واقف ہونا چاہتے ہیں، تو جیلو پیپر یا کلائنٹ کے نفاذ کا استعمال کرنے کا مشورہ دیا جاتا ہے۔ + +ایک انٹرایکٹو حوالہ تلاش کر رہے ہیں؟ [evm.codes](https://www.evm.codes/) دیکھیں۔ + +ڈائنامک گیس کی لاگت والے آپریشنز کے لیے، [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md) دیکھیں۔ + +💡 فوری ٹپ: پوری لائنیں دیکھنے کے لیے، ڈیسک ٹاپ پر افقی طور پر اسکرول کرنے کے لیے `[shift] + scroll` استعمال کریں۔ + +| اسٹیک | نام | گیس | ابتدائی اسٹیک | نتیجہ خیز اسٹیک | میم / اسٹوریج | نوٹس | | +| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | +| 00 | STOP | 0 | | | | عملدرآمد روک دیں | | +| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 کا اضافہ ماڈیولو 2\*\*256 | | +| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 کا ضرب ماڈیولو 2\*\*256 | | +| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 کا گھٹاؤ ماڈیولو 2\*\*256 | | +| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 تقسیم | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 تقسیم | | +| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 ماڈیولس | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 ماڈیولس | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 کا اضافہ ماڈیولو N | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 کا ضرب ماڈیولو N | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 کا ایکسپونینشیشن ماڈیولو 2\*\*256 | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | `x` کو `(b+1)` بائٹس سے 32 بائٹس تک [سائن ایکسٹینڈ](https://wikipedia.org/wiki/Sign_extension) کریں | | +| 0C-0F | _غلط_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 سے کم | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 سے زیادہ | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 سے کم | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 سے زیادہ | | +| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 مساوات | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | | +| 16 | AND | 3 | `a, b` | `a && b` | | بٹ وائز AND | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | بٹ وائز OR | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | بٹ وائز XOR | | +| 19 | NOT | 3 | `a` | `~a` | | بٹ وائز NOT | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | (u)int256 `x` کا `i` واں بائٹ، بائیں طرف سے | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | بائیں شفٹ کریں | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | منطقی دائیں شفٹ | | +| 1D | DUP5 | 3 | `shift, val` | `val >> shift` | | حسابی دائیں شفٹ | | +| 1E-1F | _غلط_ | | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | +| 21-2F | _غلط_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | عملدرآمد کرنے والے کنٹریکٹ کا پتہ | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | بیلنس، wei میں | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | وہ پتہ جس نے tx شروع کیا | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | msg بھیجنے والے کا پتہ | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg کی قیمت، wei میں | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | انڈیکس `idx` پر msg ڈیٹا سے لفظ پڑھیں | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | msg ڈیٹا کی لمبائی، بائٹس میں | | +| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | msg ڈیٹا کاپی کریں | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | عملدرآمد کرنے والے کنٹریکٹ کے کوڈ کی لمبائی، بائٹس میں | | +| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | عملدرآمد کرنے والے کنٹریکٹ کے بائٹ کوڈ کو کاپی کریں | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | tx کی گیس کی قیمت، فی یونٹ گیس wei میں [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | addr پر کوڈ کا سائز، بائٹس میں | | +| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | `addr` سے کوڈ کاپی کریں | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | آخری بیرونی کال سے واپس آنے والے ڈیٹا کا سائز، بائٹس میں | | +| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | آخری بیرونی کال سے واپس آنے والے ڈیٹا کو کاپی کریں | | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | ہیش = addr.exists؟ keccak256(addr.code) : 0 | | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | موجودہ بلاک کے پروپوزر کا پتہ | | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | موجودہ بلاک کا ٹائم اسٹیمپ | | +| 43 | NUMBER | 2 | `.` | `block.number` | | موجودہ بلاک کا نمبر | | +| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | رینڈمنس بیکن | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | موجودہ بلاک کی گیس کی حد | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | موجودہ [چین آئی ڈی](https://eips.ethereum.org/EIPS/eip-155) کو اسٹیک پر پش کریں | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | عملدرآمد کرنے والے کنٹریکٹ کا بیلنس، wei میں | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | موجودہ بلاک کی بیس فیس | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | موجودہ بلاک کی بلاب بیس فیس ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _غلط_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | اسٹیک کے اوپر سے آئٹم ہٹائیں اور اسے ضائع کر دیں | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | آفسیٹ `ost` پر میموری سے لفظ پڑھیں | | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | میموری میں ایک لفظ لکھیں | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | میموری میں ایک بائٹ لکھیں | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | اسٹوریج سے لفظ پڑھیں | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | اسٹوریج میں لفظ لکھیں | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` نشان زد کریں کہ `pc` صرف اس صورت میں تفویض کیا جاتا ہے جب `dst` ایک درست جمپ ڈیسٹ ہو | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | پروگرام کاؤنٹر | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | موجودہ عملدرآمد کے سیاق و سباق میں میموری کا سائز، بائٹس میں | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | درست جمپ کی منزل کو نشان زد کریں | ایک درست جمپ کی منزل مثال کے طور پر ایک جمپ کی منزل جو پش ڈیٹا کے اندر نہیں ہے | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | عارضی اسٹوریج سے لفظ پڑھیں ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | عارضی اسٹوریج میں لفظ لکھیں ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | میموری کو ایک علاقے سے دوسرے میں کاپی کریں ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | | +| 5F | PUSH0 | 2 | `.` | `uint8` | | مستقل قیمت 0 کو اسٹیک پر پش کریں | | +| 60 | PUSH1 | 3 | `.` | `uint8` | | 1-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | 2-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | 3-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | 4-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | 5-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | 6-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | 7-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | 8-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | 9-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | 10-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | 11-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | 12-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | 13-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | 14-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | 15-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | 16-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | 17-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | 18-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | 19-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | 20-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | 21-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | 22-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | 23-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | 24-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | 25-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | 26-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | 27-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | 28-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | 29-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | 30-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | 31-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | 32-بائٹ کی قیمت کو اسٹیک پر پش کریں | | +| 80 | DUP1 | 3 | `a` | `a, a` | | اسٹیک پر پہلی قیمت کا کلون بنائیں | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | اسٹیک پر دوسری قیمت کا کلون بنائیں | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | اسٹیک پر تیسری قیمت کا کلون بنائیں | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | اسٹیک پر چوتھی قیمت کا کلون بنائیں | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 5 ویں قیمت کا کلون بنائیں | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 6 ویں قیمت کا کلون بنائیں | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 7 ویں قیمت کا کلون بنائیں | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 8 ویں قیمت کا کلون بنائیں | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 9 ویں قیمت کا کلون بنائیں | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 10 ویں قیمت کا کلون بنائیں | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 11 ویں قیمت کا کلون بنائیں | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 12 ویں قیمت کا کلون بنائیں | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 13 ویں قیمت کا کلون بنائیں | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 14 ویں قیمت کا کلون بنائیں | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 15 ویں قیمت کا کلون بنائیں | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | اسٹیک پر 16 ویں قیمت کا کلون بنائیں | | +| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | | +| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | | +| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | | +| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | | +| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | | +| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | | +| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | | +| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | | +| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | | +| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | | +| A5-EF | _غلط_ | | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | | +| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | DELEGATECALL کی طرح، لیکن اصل msg.sender اور msg.value کو پھیلاتا نہیں ہے | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | mem[ost:ost+len-1] واپس کریں | | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | | +| F6-F9 | _غلط_ | | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| FB-FC | _غلط_ | | | | | | | +| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | | +| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | نامزد غلط آپ کوڈ - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | تمام ETH کو `addr` پر بھیجتا ہے؛ اگر اسی ٹرانزیکشن میں عملدرآمد کیا جائے جس میں ایک کنٹریکٹ بنایا گیا تھا تو یہ کنٹریکٹ کو تباہ کر دیتا ہے | | diff --git a/public/content/translations/ur/developers/docs/frameworks/index.md b/public/content/translations/ur/developers/docs/frameworks/index.md new file mode 100644 index 00000000000..cedfccdeac3 --- /dev/null +++ b/public/content/translations/ur/developers/docs/frameworks/index.md @@ -0,0 +1,156 @@ +--- +title: "Dapp ڈیولپمنٹ فریم ورکس" +description: "فریم ورکس کے فوائد کا جائزہ لیں اور دستیاب اختیارات کا موازنہ کریں۔" +lang: ur-in +--- + +## فریم ورکس کا تعارف {#introduction-to-frameworks} + +ایک مکمل dapp بنانے کے لیے +مختلف قسم کی ٹیکنالوجی کی ضرورت ہوتی ہے۔ سافٹ ویئر فریم ورکس میں بہت سی مطلوبہ +خصوصیات شامل ہوتی ہیں یا یہ آپ کو اپنی پسند کے ٹولز منتخب کرنے کے لیے آسان پلگ ان سسٹم فراہم کرتے ہیں۔ + +فریم ورکس بہت ساری پہلے سے تیار شدہ فعالیت کے ساتھ آتے ہیں، +جیسے: + +- مقامی بلاک چین انسٹینس کو شروع کرنے کی خصوصیات۔ +- آپ کے اسمارٹ کنٹریکٹس کو کمپائل اور ٹیسٹ کرنے کے لیے یوٹیلیٹیز۔ +- ایک ہی پروجیکٹ/ریپوزٹری کے اندر اپنی صارف پر مبنی ایپلیکیشن + بنانے کے لیے کلائنٹ ڈیولپمنٹ ایڈ آنز۔ +- Ethereum نیٹ ورکس سے جڑنے اور کنٹریکٹس کو ڈیپلائے کرنے کے لیے کنفیگریشن، + چاہے مقامی طور پر چلنے والے انسٹینس پر ہو، یا Ethereum کے + عوامی نیٹ ورکس میں سے کسی ایک پر۔ +- غیر مرکزی ایپ کی تقسیم - IPFS جیسے اسٹوریج + کے اختیارات کے ساتھ انضمام۔ + +## شرائط {#prerequisites} + +فریم ورکس میں گہرائی میں جانے سے پہلے، ہم تجویز کرتے ہیں کہ آپ پہلے ہمارے [dapps](/developers/docs/dapps/) اور [Ethereum اسٹیک](/developers/docs/ethereum-stack/) کا تعارف پڑھ لیں۔ + +## دستیاب فریم ورکس {#available-frameworks} + +**Foundry** - **_Foundry Ethereum ایپلیکیشن ڈیولپمنٹ کے لیے ایک انتہائی تیز، پورٹیبل اور ماڈیولر ٹول کٹ ہے_** + +- [Foundry انسٹال کریں](https://book.getfoundry.sh/) +- [Foundry کتاب](https://book.getfoundry.sh/) +- [Telegram پر Foundry کمیونٹی چیٹ](https://t.me/foundry_support) +- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry) + +**Hardhat -** **_پیشہ ور افراد کے لیے Ethereum ڈیولپمنٹ کا ماحول۔_** + +- [hardhat.org](https://hardhat.org) +- [GitHub](https://github.com/nomiclabs/hardhat) + +**Ape -** **_Pythonistas، ڈیٹا سائنسدانوں، اور سیکورٹی پیشہ ور افراد کے لیے اسمارٹ کنٹریکٹ ڈیولپمنٹ ٹول۔_** + +- [ڈاکیومنٹیشن](https://docs.apeworx.io/ape/stable/) +- [GitHub](https://github.com/ApeWorX/ape) + +**Web3j -** **_JVM پر بلاک چین ایپلیکیشنز تیار کرنے کا ایک پلیٹ فارم۔_** + +- [ہوم پیج](https://www.web3labs.com/web3j-sdk) +- [ڈاکیومنٹیشن](https://docs.web3j.io) +- [GitHub](https://github.com/web3j/web3j) + +**ethers-kt -** **_EVM پر مبنی بلاک چینز کے لیے غیر مطابقت پذیر، اعلی کارکردگی والی Kotlin/Java/Android لائبریری۔_** + +- [GitHub](https://github.com/Kr1ptal/ethers-kt) +- [مثالیں](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [Discord](https://discord.gg/rx35NzQGSb) + +**Create Eth App -** **_ایک کمانڈ سے Ethereum سے چلنے والی ایپس بنائیں۔ یہ منتخب کرنے کے لیے UI فریم ورکس اور DeFi ٹیمپلیٹس کی ایک وسیع رینج کے ساتھ آتا ہے۔_** + +- [GitHub](https://github.com/paulrberg/create-eth-app) +- [ٹیمپلیٹس](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) + +**Scaffold-Eth -** **_ویب 3 کے لیے Ethers.js + Hardhat + React اجزاء اور ہکس: اسمارٹ کنٹریکٹس سے چلنے والی غیر مرکزی ایپلیکیشنز کی تعمیر شروع کرنے کے لیے آپ کو درکار ہر چیز۔_** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) + +**Tenderly -** **_ویب 3 ڈیولپمنٹ پلیٹ فارم جو بلاک چین ڈیولپرز کو اسمارٹ کنٹریکٹس بنانے، ٹیسٹ کرنے، ڈیبگ کرنے، مانیٹر کرنے اور چلانے اور dapp UX کو بہتر بنانے کے قابل بناتا ہے۔_** + +- [ویب سائٹ](https://tenderly.co/) +- [ڈاکیومنٹیشن](https://docs.tenderly.co/) + +**The Graph -** **_بلاک چین ڈیٹا کو مؤثر طریقے سے استفسار کرنے کے لیے The Graph۔_** + +- [ویب سائٹ](https://thegraph.com/) +- [ٹیوٹوریل](/developers/tutorials/the-graph-fixing-web3-data-querying/) + +**Alchemy -** **_Ethereum ڈیولپمنٹ پلیٹ فارم۔_** + +- [alchemy.com](https://www.alchemy.com/) +- [GitHub](https://github.com/alchemyplatform) +- [Discord](https://discord.com/invite/alchemyplatform) + +**NodeReal -** **_Ethereum ڈیولپمنٹ پلیٹ فارم۔_** + +- [Nodereal.io](https://nodereal.io/) +- [GitHub](https://github.com/node-real) +- [Discord](https://discord.gg/V5k5gsuE) + +**thirdweb SDK -** **_ہمارے طاقتور SDKs اور CLI کا استعمال کرتے ہوئے ویب 3 ایپلیکیشنز بنائیں جو آپ کے اسمارٹ کنٹریکٹس کے ساتھ تعامل کر سکیں۔_** + +- [ڈاکیومنٹیشن](https://portal.thirdweb.com/sdk/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Chainstack -** **_ویب 3 (Ethereum اور دیگر) ڈیولپمنٹ پلیٹ فارم۔_** + +- [chainstack.com](https://www.chainstack.com/) +- [GitHub](https://github.com/chainstack) +- [Discord](https://discord.gg/BSb5zfp9AT) + +**Crossmint -** **_انٹرپرائز-گریڈ ویب 3 ڈیولپمنٹ پلیٹ فارم، جو آپ کو تمام بڑی EVM چینز (اور دیگر) پر NFT ایپلیکیشنز بنانے کی اجازت دیتا ہے۔_** + +- [ویب سائٹ](https://www.crossmint.com) +- [ڈاکومینٹیشن](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +**Brownie -** **_Python پر مبنی ڈیولپمنٹ ماحول اور ٹیسٹنگ فریم ورک۔_** + +- [ڈاکیومنٹیشن](https://eth-brownie.readthedocs.io/en/latest/) +- [GitHub](https://github.com/eth-brownie/brownie) +- **Brownie کی فی الحال دیکھ بھال نہیں کی جا رہی** + +**OpenZeppelin SDK -** **_الٹیمیٹ اسمارٹ کنٹریکٹ ٹول کٹ: ٹولز کا ایک مجموعہ جو آپ کو اسمارٹ کنٹریکٹس کو ڈیولپ کرنے، کمپائل کرنے، اپ گریڈ کرنے، ڈیپلائے کرنے اور ان کے ساتھ تعامل کرنے میں مدد کرتا ہے۔_** + +- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) +- [کمیونٹی فورم](https://forum.openzeppelin.com/c/support/17) +- **OpenZeppelin SDK کی ڈیولپمنٹ ختم ہو چکی ہے** + +**Catapulta -** **_ملٹی چین اسمارٹ کنٹریکٹس ڈیپلائمنٹ ٹول، بلاک ایکسپلوررز میں تصدیق کو خودکار بناتا ہے، ڈیپلائے کیے گئے اسمارٹ کنٹریکٹس کا ٹریک رکھتا ہے اور ڈیپلائمنٹ رپورٹس شیئر کرتا ہے، Foundry اور Hardhat پروجیکٹس کے لیے پلگ-این-پلے۔_** + +- [ویب سائٹ](https://catapulta.sh/) +- [ڈاکیومنٹیشن](https://catapulta.sh/docs) +- [Github](https://github.com/catapulta-sh) + +**GoldRush (Covalent کے ذریعے تقویت یافتہ) -** **_GoldRush ڈیولپرز، تجزیہ کاروں، اور کاروباری اداروں کے لیے سب سے جامع بلاک چین ڈیٹا API سویٹ پیش کرتا ہے۔ چاہے آپ ایک DeFi ڈیش بورڈ، ایک والیٹ، ایک ٹریڈنگ بوٹ، ایک AI ایجنٹ یا ایک کمپلائنس پلیٹ فارم بنا رہے ہوں، ڈیٹا APIs آپ کو درکار ضروری آن چین ڈیٹا تک تیز، درست، اور ڈیولپر دوست رسائی فراہم کرتے ہیں_** + +- [ویب سائٹ](https://goldrush.dev/) +- [ڈاکیومنٹیشن](https://goldrush.dev/docs/chains/ethereum) +- [GitHub](https://github.com/covalenthq) +- [Discord](https://www.covalenthq.com/discord/) + +**Wake -** **_کنٹریکٹس کی ٹیسٹنگ، فزنگ، ڈیپلائمنٹ، کمزوری اسکیننگ اور کوڈ نیویگیشن کے لیے آل ان ون Python فریم ورک۔_** + +- [ہوم پیج](https://getwake.io/) +- [ڈاکیومنٹیشن](https://ackeeblockchain.com/wake/docs/latest/) +- [GitHub](https://github.com/Ackee-Blockchain/wake) +- [VS Code ایکسٹینشن](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) + +**Veramo -** **_اوپن سورس، ماڈیولر اور ایگنوسٹک فریم ورک جو غیر مرکزی ایپلیکیشن ڈیولپرز کے لیے اپنی ایپلیکیشنز میں غیر مرکزی شناختیں اور قابل تصدیق اسناد بنانا آسان بناتا ہے۔_** + +- [ہوم پیج](https://veramo.io/) +- [ڈاکیومنٹیشن](https://veramo.io/docs/basics/introduction) +- [GitHub](https://github.com/uport-project/veramo) +- [Discord](https://discord.com/invite/FRRBdjemHV) +- [NPM پیکیج](https://www.npmjs.com/package/@veramo/core) + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ایک مقامی ڈیولپمنٹ اینوائرمنٹ سیٹ اپ کریں](/developers/local-environment/) diff --git a/public/content/translations/ur/developers/docs/gas/index.md b/public/content/translations/ur/developers/docs/gas/index.md new file mode 100644 index 00000000000..b958de8fa56 --- /dev/null +++ b/public/content/translations/ur/developers/docs/gas/index.md @@ -0,0 +1,151 @@ +--- +title: "گیس اور فیس" +metaTitle: "ایتھیریم گیس اور فیس: تکنیکی جائزہ" +description: "ایتھیریم گیس فیس، ان کا حساب لگانے کے طریقے، اور نیٹ ورک سیکورٹی اور ٹرانزیکشن پروسیسنگ میں ان کے کردار کے بارے میں جانیں۔" +lang: ur-in +--- + +گیس ایتھیریم نیٹ ورک کے لیے ضروری ہے۔ یہ وہ ایندھن ہے جو اسے کام کرنے کی اجازت دیتا ہے، بالکل اسی طرح جیسے کسی کار کو چلنے کے لیے پٹرول کی ضرورت ہوتی ہے۔ + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ٹرانزیکشنز](/developers/docs/transactions/) اور [EVM](/developers/docs/evm/) کے بارے میں پڑھیں۔ + +## گیس کیا ہے؟ {#what-is-gas} + +گیس اس یونٹ سے مراد ہے جو ایتھیریم نیٹ ورک پر مخصوص آپریشنز کو انجام دینے کے لیے درکار کمپیوٹیشنل کوشش کی مقدار کی پیمائش کرتا ہے۔ + +چونکہ ہر ایتھیریم ٹرانزیکشن کو انجام دینے کے لیے کمپیوٹیشنل وسائل کی ضرورت ہوتی ہے، اس لیے ان وسائل کی ادائیگی کرنی پڑتی ہے تاکہ یہ یقینی بنایا جا سکے کہ ایتھیریم اسپام کے لیے غیر محفوظ نہیں ہے اور لامحدود کمپیوٹیشنل لوپس میں پھنس نہیں سکتا ہے۔ کمپیوٹیشن کی ادائیگی گیس فیس کی شکل میں کی جاتی ہے۔ + +گیس فیس **کسی آپریشن کو کرنے کے لیے استعمال ہونے والی گیس کی مقدار ہے، جسے فی یونٹ گیس کی قیمت سے ضرب دی جاتی ہے**۔ ٹرانزیکشن کامیاب ہو یا ناکام، فیس کی ادائیگی ہر حال میں کی جاتی ہے۔ + +![ایک ڈایاگرام جس میں دکھایا گیا ہے کہ EVM آپریشنز میں گیس کی ضرورت کہاں ہوتی ہے](./gas.png) +_ڈایاگرام [Ethereum EVM کی تصویری وضاحت](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے ماخوذ ہے_ + +گیس فیس کی ادائیگی ایتھیریم کی مقامی کرنسی، ایتھر (ETH) میں کی جانی چاہیے۔ گیس کی قیمتیں عام طور پر gwei میں بیان کی جاتی ہیں، جو ETH کی ایک قسم ہے۔ ہر gwei ایک ارب ویں ETH (0.000000001 ETH یا 10-9 ETH) کے برابر ہے۔ + +مثال کے طور پر، یہ کہنے کے بجائے کہ آپ کی گیس کی لاگت 0.000000001 ایتھر ہے، آپ کہہ سکتے ہیں کہ آپ کی گیس کی لاگت 1 gwei ہے۔ + +لفظ 'gwei' 'giga-wei' کا مخفف ہے، جس کا مطلب ہے 'بلین wei'۔ ایک gwei ایک بلین wei کے برابر ہے۔ Wei خود ( [b-money](https://www.investopedia.com/terms/b/bmoney.asp) کے تخلیق کار [Wei Dai](https://wikipedia.org/wiki/Wei_Dai) کے نام پر رکھا گیا) ETH کی سب سے چھوٹی اکائی ہے۔ + +## گیس فیس کا حساب کیسے لگایا جاتا ہے؟ {#how-are-gas-fees-calculated} + +جب آپ کوئی ٹرانزیکشن جمع کرتے ہیں تو آپ گیس کی وہ رقم مقرر کر سکتے ہیں جو آپ ادا کرنے کے لیے تیار ہیں۔ گیس کی ایک خاص مقدار کی پیشکش کر کے، آپ اپنے ٹرانزیکشن کو اگلے بلاک میں شامل کرنے کے لیے بولی لگا رہے ہیں۔ اگر آپ بہت کم پیشکش کرتے ہیں، تو توثیق کاروں کے آپ کے ٹرانزیکشن کو شمولیت کے لیے منتخب کرنے کا امکان کم ہوتا ہے، جس کا مطلب ہے کہ آپ کا ٹرانزیکشن تاخیر سے یا بالکل بھی انجام نہیں پا سکتا ہے۔ اگر آپ بہت زیادہ پیشکش کرتے ہیں، تو آپ کچھ ETH ضائع کر سکتے ہیں۔ تو، آپ کیسے بتا سکتے ہیں کہ کتنی ادائیگی کرنی ہے؟ + +آپ جو کل گیس ادا کرتے ہیں اسے دو اجزاء میں تقسیم کیا گیا ہے: `base fee` اور `priority fee` (ٹپ)۔ + +`base fee` پروٹوکول کے ذریعہ مقرر کی جاتی ہے—آپ کو اپنے ٹرانزیکشن کو درست سمجھنے کے لیے کم از کم یہ رقم ادا کرنی ہوگی۔ `priority fee` ایک ٹپ ہے جسے آپ بنیادی فیس میں شامل کرتے ہیں تاکہ آپ کے ٹرانزیکشن کو توثیق کاروں کے لیے پرکشش بنایا جا سکے تاکہ وہ اسے اگلے بلاک میں شمولیت کے لیے منتخب کریں۔ + +ایک ٹرانزیکشن جو صرف `base fee` ادا کرتا ہے تکنیکی طور پر درست ہے لیکن اس کے شامل ہونے کا امکان نہیں ہے کیونکہ یہ توثیق کاروں کو کسی دوسرے ٹرانزیکشن پر اسے منتخب کرنے کے لیے کوئی ترغیب نہیں دیتا ہے۔ 'صحیح' `priority` فیس کا تعین آپ کے ٹرانزیکشن بھیجتے وقت نیٹ ورک کے استعمال سے ہوتا ہے—اگر بہت زیادہ ڈیمانڈ ہے تو آپ کو اپنی `priority` فیس زیادہ مقرر کرنی پڑ سکتی ہے، لیکن جب ڈیمانڈ کم ہو تو آپ کم ادائیگی کر سکتے ہیں۔ + +مثال کے طور پر، فرض کریں کہ جارڈن کو ٹیلر کو 1 ETH ادا کرنا ہے۔ ETH کی منتقلی کے لیے 21,000 یونٹ گیس کی ضرورت ہوتی ہے، اور بنیادی فیس 10 gwei ہے۔ جارڈن 2 gwei کی ٹپ شامل کرتا ہے۔ + +کل فیس اب اس کے برابر ہوگی: + +`استعمال شدہ گیس کے یونٹ * (بنیادی فیس + ترجیحی فیس)` + +جہاں `base fee` پروٹوکول کے ذریعہ مقرر کردہ ایک قدر ہے اور `priority fee` صارف کے ذریعہ توثیق کار کو ٹپ کے طور پر مقرر کردہ ایک قدر ہے۔ + +مثال کے طور پر، `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH)۔ + +جب جارڈن رقم بھیجتا ہے، تو جارڈن کے اکاؤنٹ سے 1.000252 ETH کاٹ لیے جائیں گے۔ ٹیلر کو 1.0000 ETH کریڈٹ کیا جائے گا۔ توثیق کار کو 0.000042 ETH کی ٹپ ملتی ہے۔ 0.00021 ETH کی `base fee` جلا دی جاتی ہے۔ + +### بنیادی فیس {#base-fee} + +ہر بلاک کی ایک بنیادی فیس ہوتی ہے جو ریزرو قیمت کے طور پر کام کرتی ہے۔ کسی بلاک میں شمولیت کے لیے اہل ہونے کے لیے گیس کی فی پیش کردہ قیمت کم از کم بنیادی فیس کے برابر ہونی چاہیے۔ بنیادی فیس کا حساب موجودہ بلاک سے آزادانہ طور پر کیا جاتا ہے اور اس کے بجائے اس سے پہلے کے بلاکس کے ذریعہ اس کا تعین کیا جاتا ہے، جس سے صارفین کے لیے ٹرانزیکشن فیس زیادہ قابل قیاس ہو جاتی ہے۔ جب بلاک بنایا جاتا ہے تو یہ **بنیادی فیس "جلا" دی جاتی ہے**، اسے گردش سے ہٹا دیا جاتا ہے۔ + +بنیادی فیس کا حساب ایک فارمولے کے ذریعے کیا جاتا ہے جو پچھلے بلاک کے سائز (تمام ٹرانزیکشنز کے لیے استعمال ہونے والی گیس کی مقدار) کا ہدف کے سائز (گیس کی حد کا نصف) سے موازنہ کرتا ہے۔ اگر ٹارگٹ بلاک کا سائز ٹارگٹ سے زیادہ یا کم ہو تو بنیادی فیس میں بالترتیب فی بلاک زیادہ سے زیادہ 12.5% کا اضافہ یا کمی ہوگی۔ یہ تیز رفتار نمو بلاک کے سائز کو غیر معینہ مدت تک بلند رہنے کے لیے اقتصادی طور پر غیر قابل عمل بناتی ہے۔ + +| بلاک نمبر | شامل گیس | فیس میں اضافہ | موجودہ بنیادی فیس | +| --------- | -------: | --------------------: | -------------------------: | +| 1 | 18M | 0% | 100 gwei | +| 2 | 36M | 0% | 100 gwei | +| 3 | 36M | 12.5% | 112.5 gwei | +| 4 | 36M | 12.5% | 126.6 gwei | +| 5 | 36M | 12.5% | 142.4 gwei | +| 6 | 36M | 12.5% | 160.2 gwei | +| 7 | 36M | 12.5% | 180.2 gwei | +| 8 | 36M | 12.5% | 202.7 gwei | + +اوپر دی گئی جدول میں، 36 ملین کو گیس کی حد کے طور پر استعمال کرتے ہوئے ایک مثال کا مظاہرہ کیا گیا ہے۔ اس مثال کے بعد، بلاک نمبر 9 پر ایک ٹرانزیکشن بنانے کے لیے، ایک والیٹ صارف کو یقینی طور پر یہ بتائے گا کہ اگلے بلاک میں شامل کی جانے والی **زیادہ سے زیادہ بنیادی فیس** `موجودہ بنیادی فیس * 112.5%` یا `202.7 gwei * 112.5% = 228.1 gwei` ہے۔ + +یہ نوٹ کرنا بھی ضروری ہے کہ مکمل بلاکس کی توسیعی اسپائکس دیکھنے کا امکان نہیں ہے کیونکہ مکمل بلاک سے پہلے بنیادی فیس میں جس رفتار سے اضافہ ہوتا ہے۔ + +| بلاک نمبر | شامل گیس | فیس میں اضافہ | موجودہ بنیادی فیس | +| --------------------------------------------------- | --------------------------------------------------: | --------------------: | --------------------------------------------------: | +| 30 | 36M | 12.5% | 2705.6 gwei | +| ... | ... | 12.5% | ... | +| 50 | 36M | 12.5% | 28531.3 gwei | +| ... | ... | 12.5% | ... | +| 100 | 36M | 12.5% | 10302608.6 gwei | + +### ترجیحی فیس (ٹپس) {#priority-fee} + +ترجیحی فیس (ٹپ) توثیق کاروں کو ایک بلاک میں ٹرانزیکشنز کی تعداد کو زیادہ سے زیادہ کرنے کی ترغیب دیتی ہے، جو صرف بلاک گیس کی حد سے محدود ہے۔ ٹپس کے بغیر، ایک عقلی توثیق کار بغیر کسی براہ راست ایگزیکیوشن پرت یا اتفاق رائے کی پرت کے جرمانے کے کم — یا صفر — ٹرانزیکشنز شامل کر سکتا ہے، کیونکہ اسٹیکنگ انعامات اس سے آزاد ہیں کہ ایک بلاک میں کتنے ٹرانزیکشنز ہیں۔ مزید برآں، ٹپس صارفین کو اسی بلاک کے اندر ترجیح کے لیے دوسروں سے زیادہ بولی لگانے کی اجازت دیتے ہیں، جو مؤثر طریقے سے فوری ضرورت کا اشارہ دیتے ہیں۔ + +### زیادہ سے زیادہ فیس {#maxfee} + +نیٹ ورک پر ٹرانزیکشن کو انجام دینے کے لیے، صارفین ایک زیادہ سے زیادہ حد کی وضاحت کر سکتے ہیں جو وہ اپنے ٹرانزیکشن کو انجام دینے کے لیے ادا کرنے کے لیے تیار ہیں۔ اس اختیاری پیرامیٹر کو `maxFeePerGas` کے نام سے جانا جاتا ہے۔ ٹرانزیکشن کو انجام دینے کے لیے، زیادہ سے زیادہ فیس بنیادی فیس اور ٹپ کے مجموعے سے زیادہ ہونی چاہیے۔ ٹرانزیکشن بھیجنے والے کو زیادہ سے زیادہ فیس اور بنیادی فیس اور ٹپ کے مجموعے کے درمیان فرق واپس کر دیا جاتا ہے۔ + +### بلاک کا سائز {#block-size} + +ہر بلاک کا ہدف کا سائز موجودہ گیس کی حد کا نصف ہے، لیکن بلاکس کا سائز نیٹ ورک کی طلب کے مطابق بڑھے گا یا کم ہوگا، جب تک کہ بلاک کی حد تک نہ پہنچ جائے (ہدف بلاک کے سائز کا 2x)۔ پروٹوکول _tâtonnement_ کے عمل کے ذریعے ہدف پر ایک متوازن اوسط بلاک سائز حاصل کرتا ہے۔ اس کا مطلب ہے کہ اگر بلاک کا سائز ہدف بلاک کے سائز سے زیادہ ہے، تو پروٹوکول اگلے بلاک کے لیے بنیادی فیس میں اضافہ کرے گا۔ اسی طرح، اگر بلاک کا سائز ہدف بلاک کے سائز سے کم ہے تو پروٹوکول بنیادی فیس کو کم کر دے گا۔ + +جس رقم سے بنیادی فیس کو ایڈجسٹ کیا جاتا ہے وہ اس کے متناسب ہے کہ موجودہ بلاک کا سائز ہدف سے کتنا دور ہے۔ یہ ایک خالی بلاک کے لیے -12.5% سے، ہدف کے سائز پر 0%، گیس کی حد تک پہنچنے والے بلاک کے لیے +12.5% تک ایک لکیری حساب ہے۔ گیس کی حد وقت کے ساتھ ساتھ توثیق کار کے سگنلنگ کی بنیاد پر، نیز نیٹ ورک اپ گریڈ کے ذریعے بھی اتار چڑھاؤ آسکتی ہے۔ آپ [یہاں وقت کے ساتھ گیس کی حد میں ہونے والی تبدیلیاں دیکھ سکتے ہیں](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths)۔ + +[بلاک کے بارے میں مزید](/developers/docs/blocks/) + +### عملی طور پر گیس فیس کا حساب لگانا {#calculating-fees-in-practice} + +آپ واضح طور پر بتا سکتے ہیں کہ آپ اپنے ٹرانزیکشن کو انجام دینے کے لیے کتنی رقم ادا کرنے کے لیے تیار ہیں۔ تاہم، زیادہ تر والیٹ فراہم کرنے والے اپنے صارفین پر بوجھ کی پیچیدگی کو کم کرنے کے لیے خود بخود ایک تجویز کردہ ٹرانزیکشن فیس (بنیادی فیس + تجویز کردہ ترجیحی فیس) مقرر کریں گے۔ + +## گیس فیس کیوں موجود ہے؟ {#why-do-gas-fees-exist} + +مختصراً، گیس فیس ایتھیریم نیٹ ورک کو محفوظ رکھنے میں مدد کرتی ہے۔ نیٹ ورک پر کی جانے والی ہر کمپیوٹیشن کے لیے فیس کا مطالبہ کرکے، ہم برے اداکاروں کو نیٹ ورک پر اسپام کرنے سے روکتے ہیں۔ کوڈ میں حادثاتی یا مخالف لامحدود لوپس یا دیگر کمپیوٹیشنل ضیاع سے بچنے کے لیے، ہر ٹرانزیکشن کے لیے ایک حد مقرر کرنا ضروری ہے کہ وہ کوڈ پر عمل درآمد کے کتنے کمپیوٹیشنل اقدامات استعمال کر سکتا ہے۔ کمپیوٹیشن کی بنیادی اکائی "گیس" ہے۔ + +اگرچہ ایک ٹرانزیکشن میں ایک حد شامل ہوتی ہے، لیکن ٹرانزیکشن میں استعمال نہ ہونے والی کوئی بھی گیس صارف کو واپس کر دی جاتی ہے (مثال کے طور پر، `max fee - (base fee + tip)` واپس کر دیا جاتا ہے)۔ + +![ڈایاگرام جس میں دکھایا گیا ہے کہ غیر استعمال شدہ گیس کیسے واپس کی جاتی ہے](../transactions/gas-tx.png) +_ڈایاگرام [Ethereum EVM کی تصویری وضاحت](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے ماخوذ ہے_ + +## گیس کی حد کیا ہے؟ {#what-is-gas-limit} + +گیس کی حد سے مراد گیس کی وہ زیادہ سے زیادہ مقدار ہے جو آپ کسی ٹرانزیکشن پر خرچ کرنے کے لیے تیار ہیں۔ [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) پر مشتمل زیادہ پیچیدہ ٹرانزیکشنز کے لیے زیادہ کمپیوٹیشنل کام کی ضرورت ہوتی ہے، اس لیے انہیں ایک سادہ ادائیگی کے مقابلے میں زیادہ گیس کی حد کی ضرورت ہوتی ہے۔ ایک معیاری ETH منتقلی کے لیے 21,000 یونٹ گیس کی حد درکار ہوتی ہے۔ + +مثال کے طور پر، اگر آپ ایک سادہ ETH منتقلی کے لیے 50,000 کی گیس کی حد مقرر کرتے ہیں، تو EVM 21,000 استعمال کرے گا، اور آپ کو بقیہ 29,000 واپس مل جائیں گے۔ تاہم، اگر آپ بہت کم گیس کی وضاحت کرتے ہیں، مثال کے طور پر، ایک سادہ ETH منتقلی کے لیے 20,000 کی گیس کی حد، توثیق کے مرحلے کے دوران ٹرانزیکشن ناکام ہو جائے گا۔ اسے کسی بلاک میں شامل کرنے سے پہلے مسترد کر دیا جائے گا، اور کوئی گیس استعمال نہیں ہوگی۔ دوسری طرف، اگر عمل درآمد کے دوران کسی ٹرانزیکشن کی گیس ختم ہو جاتی ہے (مثال کے طور پر، ایک اسمارٹ کنٹریکٹ آدھے راستے میں تمام گیس استعمال کر لیتا ہے)، تو EVM کسی بھی تبدیلی کو واپس کر دے گا، لیکن فراہم کردہ تمام گیس پھر بھی انجام پانے والے کام کے لیے استعمال کی جائے گی۔ + +## گیس فیس اتنی زیادہ کیوں ہو سکتی ہے؟ {#why-can-gas-fees-get-so-high} + +زیادہ گیس فیس ایتھیریم کی مقبولیت کی وجہ سے ہے۔ اگر بہت زیادہ ڈیمانڈ ہے، تو صارفین کو دوسرے صارفین کے ٹرانزیکشنز سے زیادہ بولی لگانے کی کوشش کرنے کے لیے زیادہ ٹپ کی رقم پیش کرنی ہوگی۔ ایک اعلی ٹپ اس بات کا زیادہ امکان بنا سکتی ہے کہ آپ کا ٹرانزیکشن اگلے بلاک میں چلا جائے گا۔ اس کے علاوہ، زیادہ پیچیدہ اسمارٹ کنٹریکٹ ایپس اپنے فنکشنز کو سپورٹ کرنے کے لیے بہت سے آپریشنز کر رہی ہوں گی، جس کی وجہ سے وہ بہت زیادہ گیس استعمال کرتی ہیں۔ + +## گیس کے اخراجات کو کم کرنے کے اقدامات {#initiatives-to-reduce-gas-costs} + +ایتھیریم [اسکیل ایبلٹی اپ گریڈ](/roadmap/) کو بالآخر گیس فیس کے کچھ مسائل کو حل کرنا چاہیے، جو بدلے میں، پلیٹ فارم کو فی سیکنڈ ہزاروں ٹرانزیکشنز پر کارروائی کرنے اور عالمی سطح پر اسکیل کرنے کے قابل بنائے گا۔ + +لیئر 2 اسکیلنگ گیس کے اخراجات، صارف کے تجربے اور اسکیل ایبلٹی کو بہت بہتر بنانے کا ایک بنیادی اقدام ہے۔ + +[لیئر 2 اسکیلنگ پر مزید](/developers/docs/scaling/#layer-2-scaling) + +## گیس فیس کی نگرانی {#monitoring-gas-fees} + +اگر آپ گیس کی قیمتوں کی نگرانی کرنا چاہتے ہیں، تاکہ آپ اپنا ETH کم قیمت پر بھیج سکیں، تو آپ بہت سے مختلف ٹولز استعمال کر سکتے ہیں جیسے: + +- [Etherscan](https://etherscan.io/gastracker) _ٹرانزیکشن گیس کی قیمت کا تخمینہ لگانے والا_ +- [Blockscout](https://eth.blockscout.com/gas-tracker) _اوپن سورس ٹرانزیکشن گیس کی قیمت کا تخمینہ لگانے والا_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _ٹرانزیکشن فیس کو کم کرنے اور پیسے بچانے کے لیے ایتھیریم، اور L2 گیس کی قیمتوں کی نگرانی اور ٹریک کریں_ +- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _گیس کا تخمینہ لگانے والا کروم ایکسٹینشن جو ٹائپ 0 لیگیسی ٹرانزیکشنز اور ٹائپ 2 EIP-1559 ٹرانزیکشنز دونوں کو سپورٹ کرتا ہے۔_ +- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _مین نیٹ، آربیٹرم، اور پولی گون پر مختلف ٹرانزیکشن کی اقسام کے لیے اپنی مقامی کرنسی میں گیس فیس کا حساب لگائیں۔_ + +## متعلقہ ٹولز {#related-tools} + +- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _Blocknative کے عالمی میم پول ڈیٹا پلیٹ فارم سے چلنے والا گیس تخمینہ API_ +- [Gas Network](https://gas.network) آن چین گیس اوریکلز۔ 35+ چینز کے لیے سپورٹ۔ + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم گیس کی وضاحت](https://defiprime.com/gas) +- [اپنے اسمارٹ کنٹریکٹس کی گیس کی کھپت کو کم کرنا](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [ڈویلپرز کے لیے گیس کی اصلاح کی حکمت عملی](https://www.alchemy.com/overviews/solidity-gas-optimization) +- [EIP-1559 دستاویزات](https://eips.ethereum.org/EIPS/eip-1559)۔ +- [ٹم بیکو کے EIP-1559 وسائل](https://hackmd.io/@timbeiko/1559-resources) +- [EIP-1559: میکانزم کو میمز سے الگ کرنا](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) diff --git a/public/content/translations/ur/developers/docs/ides/index.md b/public/content/translations/ur/developers/docs/ides/index.md new file mode 100644 index 00000000000..d801e73e247 --- /dev/null +++ b/public/content/translations/ur/developers/docs/ides/index.md @@ -0,0 +1,64 @@ +--- +title: "مربوط ترقیاتی ماحول (IDEs)" +description: "ایتھیریم کی ترقی کے لیے ویب پر مبنی اور ڈیسک ٹاپ IDEs کے بارے میں جانیں، بشمول Remix، VS Code، اور مشہور پلگ انز۔" +lang: ur-in +--- + +جب بات [مربوط ترقیاتی ماحول (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) کو ترتیب دینے کی ہو تو، ایتھیریم پر ایپلیکیشنز کی پروگرامنگ کرنا کسی بھی دوسرے سافٹ ویئر پروجیکٹ کی پروگرامنگ کرنے کی طرح ہے۔ منتخب کرنے کے لیے بہت سے اختیارات ہیں، لہذا آخر میں، وہ IDE یا کوڈ ایڈیٹر منتخب کریں جو آپ کی ترجیحات کے مطابق بہترین ہو۔ غالباً آپ کی ایتھیریم کی ترقی کے لیے بہترین IDE کا انتخاب وہی IDE ہے جسے آپ روایتی سافٹ ویئر کی ترقی کے لیے پہلے سے استعمال کرتے ہیں۔ + +## ویب پر مبنی IDEs {#web-based-ides} + +اگر آپ [مقامی ترقیاتی ماحول ترتیب دینے](/developers/local-environment/) سے پہلے کوڈ کے ساتھ چھیڑ چھاڑ کرنا چاہتے ہیں، تو یہ ویب ایپس خاص طور پر ایتھیریم اسمارٹ کنٹریکٹ کی ترقی کے لیے بنائی گئی ہیں۔ + +**[Remix](https://remix.ethereum.org/)** - **_بلٹ ان سٹیٹک تجزیہ، اور ایک ٹیسٹ بلاک چین ورچوئل مشین کے ساتھ ویب پر مبنی IDE_** + +- [دستاویزات](https://remix-ide.readthedocs.io/en/latest/#) +- [Gitter](https://gitter.im/ethereum/remix) + +**[ChainIDE](https://chainide.com/)** - **_ایک کلاؤڈ پر مبنی ملٹی چین IDE_** + +- [دستاویزات](https://chainide.gitbook.io/chainide-english-1/) +- [مدد کا فورم](https://forum.chainide.com/) + +**[Replit (Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_ہاٹ ری لوڈنگ، خرابی کی جانچ، اور فرسٹ کلاس ٹیسٹ نیٹ سپورٹ کے ساتھ ایتھیریم کے لیے ایک حسب ضرورت ترقیاتی ماحول_** + +- [دستاویزات](https://docs.replit.com/) + +**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_ایک تیز پروٹوٹائپنگ ماحول جہاں آپ Solidity اور JavaScript کا استعمال کرتے ہوئے براؤزر میں اسمارٹ کنٹریکٹس لکھ، چلا اور ڈیبگ کر سکتے ہیں_** + +**[EthFiddle](https://ethfiddle.com/)** - **_ویب پر مبنی IDE جو آپ کو اپنے اسمارٹ کنٹریکٹ کو لکھنے، کمپائل کرنے اور ڈیبگ کرنے کی اجازت دیتا ہے_** + +- [Gitter](https://gitter.im/loomnetwork/ethfiddle) + +## ڈیسک ٹاپ IDEs {#desktop-ides} + +زیادہ تر قائم شدہ IDEs نے ایتھیریم کی ترقی کے تجربے کو بڑھانے کے لیے پلگ ان بنائے ہیں۔ کم از کم، وہ [اسمارٹ کنٹریکٹ زبانوں](/developers/docs/smart-contracts/languages/) کے لیے سنٹیکس ہائی لائٹنگ فراہم کرتے ہیں۔ + +**Visual Studio Code -** **_باضابطہ ایتھیریم سپورٹ کے ساتھ پیشہ ورانہ کراس پلیٹ فارم IDE_** + +- [Visual Studio Code](https://code.visualstudio.com/) +- [کوڈ کے نمونے](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) +- [GitHub](https://github.com/microsoft/vscode) + +**JetBrains IDEs (IntelliJ IDEA, وغیرہ)** -\*\* **_سافٹ ویئر ڈویلپرز اور ٹیموں کے لیے ضروری ٹولز_** + +- [JetBrains](https://www.jetbrains.com/) +- [GitHub](https://github.com/JetBrains) +- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/) + +**Remix Desktop -** **_اپنی مقامی مشین پر Remix IDE کا تجربہ کریں_** + +- [ڈاؤن لوڈ](https://github.com/ethereum/remix-desktop/releases) +- [GitHub](https://github.com/ethereum/remix-desktop) + +## پلگ انز اور ایکسٹینشنز {#plugins-extensions} + +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Visual Studio Code کے لیے Ethereum Solidity زبان +- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Hardhat ٹیم کی طرف سے Solidity اور Hardhat سپورٹ +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - prettier کا استعمال کرتے ہوئے کوڈ فارمیٹر + +## مزید پڑھیں {#further-reading} + +- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- ایتھیریم IDEs کی Alchemy کی فہرست_ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/index.md b/public/content/translations/ur/developers/docs/index.md new file mode 100644 index 00000000000..6d46a8e9ae6 --- /dev/null +++ b/public/content/translations/ur/developers/docs/index.md @@ -0,0 +1,25 @@ +--- +title: "ایتھیریم ڈیولپمنٹ ڈاکیومنٹیشن" +description: "ethereum.org ڈیولپر ڈاکیومنٹیشن کا تعارف۔" +lang: ur-in +--- + +یہ ڈاکیومنٹیشن آپ کو ایتھیریم کے ساتھ بلڈ کرنے میں مدد دینے کے لیے ڈیزائن کی گئی ہے۔ یہ ایتھیریم کو بطور ایک کانسپٹ کور کرتا ہے، ایتھیریم ٹیک اسٹیک کی وضاحت کرتا ہے، اور زیادہ پیچیدہ ایپلیکیشنز اور یوز کیسز کے لیے ایڈوانسڈ موضوعات کو ڈاکیومنٹ کرتا ہے۔ + +یہ ایک اوپن سورس کمیونٹی کی کوشش ہے، اس لیے بلا جھجھک نئے موضوعات تجویز کریں، نیا مواد شامل کریں، اور جہاں بھی آپ کو لگے کہ یہ مددگار ثابت ہو سکتا ہے، مثالیں فراہم کریں۔ تمام ڈاکیومنٹیشن کو GitHub کے ذریعے ایڈٹ کیا جا سکتا ہے – اگر آپ کو یقین نہیں ہے کہ یہ کیسے کرنا ہے، تو [ان ہدایات پر عمل کریں](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)۔ + +## ڈیولپمنٹ ماڈیولز {#development-modules} + +اگر یہ ایتھیریم ڈیولپمنٹ میں آپ کی پہلی کوشش ہے، تو ہم تجویز کرتے ہیں کہ آپ شروع سے شروع کریں اور ایک کتاب کی طرح اس پر عمل کرتے ہوئے آگے بڑھیں۔ + +### بنیادی موضوعات {#foundational-topics} + + + +### ایتھیریم اسٹیک {#ethereum-stack} + + + +### ایڈوانسڈ {#advanced} + + diff --git a/public/content/translations/ur/developers/docs/intro-to-ether/index.md b/public/content/translations/ur/developers/docs/intro-to-ether/index.md new file mode 100644 index 00000000000..a413caeb269 --- /dev/null +++ b/public/content/translations/ur/developers/docs/intro-to-ether/index.md @@ -0,0 +1,78 @@ +--- +title: "ایتھر کا تکنیکی تعارف" +description: "ڈیولپرز کے لیے ایتھر کرپٹو کرنسی کا تعارف۔" +lang: ur-in +--- + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہمارا مشورہ ہے کہ آپ پہلے [Introduction to Ethereum](/developers/docs/intro-to-ethereum/) پڑھیں۔ + +## کرپٹوکرنسی کیا ہے؟ {#what-is-a-cryptocurrency} + +کرپٹو کرنسی تبادلے کا ایک ذریعہ ہے جو بلاک چین پر مبنی لیجر کے ذریعے محفوظ ہے۔ + +تبادلے کا ذریعہ کوئی بھی ایسی چیز ہے جسے سامان اور خدمات کی ادائیگی کے لیے بڑے پیمانے پر قبول کیا جاتا ہے، اور ایک لیجر ایک ڈیٹا اسٹور ہے جو ٹرانزیکشنز کا حساب رکھتا ہے۔ بلاک چین ٹیکنالوجی صارفین کو لیجر کو برقرار رکھنے کے لیے کسی قابل اعتماد تیسرے فریق پر انحصار کیے بغیر لیجر پر ٹرانزیکشن کرنے کی اجازت دیتی ہے۔ + +پہلی کرپٹو کرنسی بٹ کوائن تھی، جسے ساتوشی ناکاموتو نے بنایا تھا۔ 2009 میں بٹ کوائن کے اجراء کے بعد سے، لوگوں نے کئی مختلف بلاک چینز پر ہزاروں کرپٹو کرنسیاں بنائی ہیں۔ + +## Ether کیا ہے ؟ {#what-is-ether} + +**ایتھر (ETH)** وہ کرپٹو کرنسی ہے جو Ethereum نیٹ ورک پر بہت سی چیزوں کے لیے استعمال ہوتی ہے۔ بنیادی طور پر، یہ ٹرانزیکشن فیس کی ادائیگی کی واحد قابل قبول شکل ہے، اور [The Merge](/roadmap/merge) کے بعد، Mainnet پر بلاکس کی توثیق اور تجویز کے لیے ایتھر کی ضرورت ہوتی ہے۔ ایتھر کو [DeFi](/defi) قرض دینے والی مارکیٹوں میں کولیٹرل کی بنیادی شکل کے طور پر، NFT مارکیٹ پلیسز میں اکاؤنٹ کی اکائی کے طور پر، خدمات انجام دینے یا حقیقی دنیا کا سامان بیچنے سے حاصل ہونے والی ادائیگی کے طور پر، اور مزید بہت کچھ کے لیے بھی استعمال کیا جاتا ہے۔ + +Ethereum ڈیولپرز کو [**غیر مرکزی ایپلی کیشنز (dapps)**](/developers/docs/dapps) بنانے کی اجازت دیتا ہے، جو سبھی کمپیوٹنگ پاور کا ایک پول شیئر کرتے ہیں۔ یہ مشترکہ پول محدود ہے، اس لیے Ethereum کو یہ تعین کرنے کے لیے ایک میکانزم کی ضرورت ہے کہ اسے کون استعمال کرے گا۔ ورنہ، کوئی dapp حادثاتی طور پر یا بدنیتی سے نیٹ ورک کے تمام وسائل استعمال کر سکتا ہے، جس سے دوسروں کو اس تک رسائی حاصل کرنے سے روکا جا سکتا ہے۔ + +ایتھر کرپٹو کرنسی Ethereum کی کمپیوٹنگ پاور کے لیے قیمتوں کے تعین کے ایک میکانزم کو سپورٹ کرتی ہے۔ جب صارفین کوئی ٹرانزیکشن کرنا چاہتے ہیں، تو انہیں اپنے ٹرانزیکشن کو بلاک چین پر تسلیم کروانے کے لیے ایتھر ادا کرنا پڑتا ہے۔ ان استعمال کی لاگتوں کو [گیس فیس](/developers/docs/gas/) کے نام سے جانا جاتا ہے، اور گیس فیس ٹرانزیکشن کو انجام دینے کے لیے درکار کمپیوٹنگ پاور کی مقدار اور اس وقت کمپیوٹنگ پاور کے لیے نیٹ ورک بھر میں طلب پر منحصر ہے۔ + +لہذا، یہاں تک کہ اگر کوئی بدنیتی پر مبنی dapp ایک لامحدود لوپ جمع کرتا ہے، تو ٹرانزیکشن بالآخر ایتھر سے ختم ہو جائے گا اور ختم ہو جائے گا، جس سے نیٹ ورک معمول پر آ جائے گا۔ + +Ethereum اور ایتھر کو [آپس میں ملانا عام بات ہے](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) — جب لوگ "Ethereum کی قیمت" کا حوالہ دیتے ہیں، تو وہ ایتھر کی قیمت بیان کر رہے ہوتے ہیں۔ + +## ایتھر کی منٹنگ {#minting-ether} + +منٹنگ وہ عمل ہے جس میں Ethereum لیجر پر نیا ایتھر بنایا جاتا ہے۔ بنیادی Ethereum پروٹوکول نیا ایتھر بناتا ہے، اور کسی صارف کے لیے ایتھر بنانا ممکن نہیں ہے۔ + +ایتھر ہر مجوزہ بلاک کے انعام کے طور پر اور اتفاق رائے تک پہنچنے سے متعلق دیگر ویلیڈیٹر سرگرمیوں کے لیے ہر ایپوک چیک پوائنٹ پر منٹ کیا جاتا ہے۔ جاری کردہ کل رقم ویلیڈیٹرز کی تعداد اور انہوں نے کتنے ایتھر اسٹیک کیے ہیں، اس پر منحصر ہے۔ یہ کل اجراء اس مثالی صورت میں ویلیڈیٹرز کے درمیان یکساں طور پر تقسیم کیا جاتا ہے کہ تمام ویلیڈیٹرز ایماندار اور آن لائن ہوں، لیکن حقیقت میں، یہ ویلیڈیٹر کی کارکردگی کی بنیاد پر مختلف ہوتا ہے۔ کل اجراء کا تقریباً 1/8 حصہ بلاک پروپوزر کو جاتا ہے؛ بقیہ دیگر ویلیڈیٹرز میں تقسیم کیا جاتا ہے۔ بلاک پروپوزرز ٹرانزیکشن فیس اور MEV سے متعلقہ آمدنی سے ٹپس بھی حاصل کرتے ہیں، لیکن یہ ری سائیکل شدہ ایتھر سے آتے ہیں، نئے اجراء سے نہیں۔ + +## ایتھر کو جلانا {#burning-ether} + +بلاک انعامات کے ذریعے ایتھر بنانے کے ساتھ ساتھ، ایتھر کو 'جلانے' نامی عمل کے ذریعے تباہ کیا جا سکتا ہے۔ جب ایتھر جل جاتا ہے، تو اسے مستقل طور پر گردش سے ہٹا دیا جاتا ہے۔ + +Ethereum پر ہر ٹرانزیکشن میں ایتھر جلتا ہے۔ جب صارفین اپنے ٹرانزیکشنز کے لیے ادائیگی کرتے ہیں، تو ایک بنیادی گیس فیس، جو نیٹ ورک کے ذریعے ٹرانزیکشنل طلب کے مطابق مقرر کی جاتی ہے، تباہ ہو جاتی ہے۔ یہ، متغیر بلاک سائز اور زیادہ سے زیادہ گیس فیس کے ساتھ مل کر، Ethereum پر ٹرانزیکشن فیس کے تخمینہ کو آسان بناتا ہے۔ جب نیٹ ورک کی طلب زیادہ ہوتی ہے، تو [بلاکس](https://eth.blockscout.com/block/22580057) اپنی منٹنگ سے زیادہ ایتھر جلا سکتے ہیں، جو مؤثر طریقے سے ایتھر کے اجراء کو متوازن کرتا ہے۔ + +بنیادی فیس جلانا بلاک پروڈیوسر کی ٹرانزیکشنز میں ہیرا پھیری کرنے کی صلاحیت میں رکاوٹ پیدا کرتا ہے۔ مثال کے طور پر، اگر بلاک پروڈیوسرز کو بنیادی فیس ملتی، تو وہ اپنے ٹرانزیکشنز مفت میں شامل کر سکتے تھے اور باقی سب کے لیے بنیادی فیس بڑھا سکتے تھے۔ متبادل طور پر، وہ کچھ صارفین کو آف چین بنیادی فیس واپس کر سکتے تھے، جس کے نتیجے میں ٹرانزیکشن فیس کی مارکیٹ زیادہ غیر شفاف اور پیچیدہ ہو جاتی۔ + +## ایتھر کی ڈینومینیشنز {#denominations} + +چونکہ Ethereum پر بہت سے ٹرانزیکشنز کی قدر چھوٹی ہوتی ہے، اس لیے ایتھر کی کئی ڈینومینیشنز ہیں جنہیں اکاؤنٹ کی چھوٹی اکائیوں کے طور پر حوالہ دیا جا سکتا ہے۔ ان ڈینومینیشنز میں سے، Wei اور gwei خاص طور پر اہم ہیں۔ + +Wei ایتھر کی سب سے چھوٹی ممکنہ رقم ہے، اور نتیجے کے طور پر، بہت سے تکنیکی نفاذ، جیسے کہ [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf)، تمام حسابات کی بنیاد Wei میں رکھیں گے۔ + +Gwei، جو گیگا-وائی کا مخفف ہے، اکثر Ethereum پر گیس کی لاگت کو بیان کرنے کے لیے استعمال ہوتا ہے۔ + +| ڈینومینیشن | ایتھر میں قدر | عام استعمال | +| ---------- | ---------------- | ---------------------------- | +| Wei | 10-18 | تکنیکی نفاذ | +| Gwei | 10-9 | انسانی پڑھنے کے قابل گیس فیس | + +## ایتھر کی منتقلی {#transferring-ether} + +Ethereum پر ہر ٹرانزیکشن میں ایک `value` فیلڈ ہوتا ہے، جو بھیجنے والے کے پتے سے وصول کنندہ کے پتے پر بھیجے جانے والے ایتھر کی رقم بتاتا ہے، جسے wei میں ظاہر کیا جاتا ہے۔ + +جب وصول کنندہ کا پتہ ایک [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) ہوتا ہے، تو یہ منتقل شدہ ایتھر گیس کی ادائیگی کے لیے استعمال کیا جا سکتا ہے جب اسمارٹ کنٹریکٹ اپنا کوڈ چلاتا ہے۔ + +[ٹرانزیکشنز پر مزید](/developers/docs/transactions/) + +## ایتھر کی استفسار کرنا {#querying-ether} + +صارفین کسی بھی [اکاؤنٹ](/developers/docs/accounts/) کے ایتھر بیلنس کے بارے میں اکاؤنٹ کی `balance` فیلڈ کا معائنہ کرکے استفسار کر سکتے ہیں، جو wei میں ظاہر کردہ ایتھر ہولڈنگز کو دکھاتا ہے۔ + +[Etherscan](https://etherscan.io) اور [Blockscout](https://eth.blockscout.com) ویب پر مبنی ایپلی کیشنز کے ذریعے پتے کے بیلنس کا معائنہ کرنے کے لیے مقبول ٹولز ہیں۔ مثال کے طور پر، [یہ Blockscout صفحہ](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) Ethereum فاؤنڈیشن کا بیلنس دکھاتا ہے۔ اکاؤنٹ بیلنس کے بارے میں والیٹس کا استعمال کرکے یا براہ راست نوڈس سے درخواستیں کرکے بھی استفسار کیا جا سکتا ہے۔ + +## مزید پڑھیں {#further-reading} + +- [ایتھر اور Ethereum کی تعریف](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [Ethereum وائٹ پیپر](/whitepaper/): Ethereum کے لیے اصل تجویز۔ اس دستاویز میں ایتھر کی تفصیل اور اس کی تخلیق کے پیچھے کی ترغیبات شامل ہیں۔ +- [Gwei کیلکولیٹر](https://www.alchemy.com/gwei-calculator): wei، gwei، اور ایتھر کو آسانی سے تبدیل کرنے کے لیے اس gwei کیلکولیٹر کا استعمال کریں۔ بس wei، gwei، یا ETH کی کوئی بھی رقم درج کریں اور تبدیلی کا خود بخود حساب لگائیں۔ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/intro-to-ethereum/index.md b/public/content/translations/ur/developers/docs/intro-to-ethereum/index.md new file mode 100644 index 00000000000..bee721ec36a --- /dev/null +++ b/public/content/translations/ur/developers/docs/intro-to-ethereum/index.md @@ -0,0 +1,124 @@ +--- +title: "ایتھیریم کا تکنیکی تعارف" +description: "ایتھیریم کے بنیادی تصورات کا ایک dapp ڈیولپر کا تعارف۔" +lang: ur-in +--- + +## Blockchain کیا ہے؟ {#what-is-a-blockchain} + +بلاک چین ایک عوامی ڈیٹابیس ہے جسے ایک نیٹ ورک میں بہت سے کمپیوٹرز پر اپ ڈیٹ اور شیئر کیا جاتا ہے۔ + +"بلاک" سے مراد ڈیٹا اور اسٹیٹ ہے جو "بلاکس" کے نام سے جانے جانے والے مسلسل گروپس میں محفوظ کیا جاتا ہے۔ اگر آپ کسی اور کو ETH بھیجتے ہیں، تو ٹرانزیکشن کے کامیاب ہونے کے لیے ٹرانزیکشن ڈیٹا کو ایک بلاک میں شامل کرنے کی ضرورت ہوتی ہے۔ + +"چین" سے مراد یہ حقیقت ہے کہ ہر بلاک کرپٹوگرافک طور پر اپنے پیرنٹ کا حوالہ دیتا ہے۔ دوسرے لفظوں میں، بلاکس ایک ساتھ جڑ جاتے ہیں۔ ایک بلاک میں موجود ڈیٹا بعد کے تمام بلاکس کو تبدیل کیے بغیر تبدیل نہیں ہو سکتا، جس کے لیے پورے نیٹ ورک کے اتفاق رائے کی ضرورت ہوگی۔ + +نیٹ ورک میں ہر کمپیوٹر کو ہر نئے بلاک اور مجموعی طور پر چین پر اتفاق کرنا چاہیے۔ ان کمپیوٹرز کو "نوڈس" کے نام سے جانا جاتا ہے۔ نوڈس اس بات کو یقینی بناتے ہیں کہ بلاک چین کے ساتھ تعامل کرنے والے ہر شخص کے پاس ایک ہی ڈیٹا ہو۔ اس تقسیم شدہ معاہدے کو پورا کرنے کے لیے، بلاک چینز کو ایک اتفاق رائے کے میکانزم کی ضرورت ہوتی ہے۔ + +ایتھیریم ایک [پروف-آف-اسٹیک پر مبنی اتفاق رائے کا میکانزم](/developers/docs/consensus-mechanisms/pos/) استعمال کرتا ہے۔ کوئی بھی جو چین میں نئے بلاکس شامل کرنا چاہتا ہے اسے کولیٹرل کے طور پر ETH - ایتھیریم کی مقامی کرنسی - کو اسٹیک کرنا ہوگا اور ویلیڈیٹر سافٹ ویئر چلانا ہوگا۔ ان "ویلیڈیٹرز" کو پھر تصادفی طور پر بلاکس تجویز کرنے کے لیے منتخب کیا جا سکتا ہے جنہیں دوسرے ویلیڈیٹرز چیک کرتے ہیں اور بلاک چین میں شامل کرتے ہیں۔ انعامات اور سزاؤں کا ایک ایسا نظام ہے جو شرکاء کو ایماندار رہنے اور زیادہ سے زیادہ آن لائن دستیاب رہنے کی سختی سے ترغیب دیتا ہے۔ + +اگر آپ یہ دیکھنا چاہتے ہیں کہ بلاک چین ڈیٹا کو کیسے ہیش کیا جاتا ہے اور بعد میں بلاک حوالوں کی تاریخ میں شامل کیا جاتا ہے، تو اینڈرس براؤن ورتھ کا [یہ ڈیمو](https://andersbrownworth.com/blockchain/blockchain) ضرور دیکھیں اور نیچے دی گئی ویڈیو دیکھیں۔ + +اینڈرس کو بلاک چین میں ہیشز کی وضاحت کرتے ہوئے دیکھیں: + + + +## اتھیریم کیا ہے؟ ایتھیریم کیا ہے؟ {#what-is-ethereum} + +ایتھیریم ایک بلاک چین ہے جس میں ایک کمپیوٹر ایمبیڈڈ ہے۔ یہ ایک غیر مرکزی، اجازت کے بغیر، سنسر شپ سے مزاحم طریقے سے ایپس اور تنظیمیں بنانے کی بنیاد ہے۔ + +ایتھیریم کائنات میں، ایک واحد، کینونیکل کمپیوٹر ہے (جسے ایتھیریم ورچوئل مشین، یا EVM کہا جاتا ہے) جس کی اسٹیٹ پر ایتھیریم نیٹ ورک پر ہر کوئی متفق ہے۔ ایتھیریم نیٹ ورک میں حصہ لینے والا ہر شخص (ہر ایتھیریم نوڈ) اس کمپیوٹر کی اسٹیٹ کی ایک کاپی رکھتا ہے۔ مزید برآں، کوئی بھی شریک اس کمپیوٹر سے من مانی کمپیوٹیشن کرنے کی درخواست کو براڈکاسٹ کر سکتا ہے۔ جب بھی ایسی کوئی درخواست براڈکاسٹ کی جاتی ہے، تو نیٹ ورک پر موجود دیگر شرکاء اس کمپیوٹیشن کی تصدیق، توثیق، اور انجام دیتے ہیں ("عملدرآمد کرتے ہیں")۔ یہ عملدرآمد EVM میں اسٹیٹ کی تبدیلی کا سبب بنتا ہے، جسے پورے نیٹ ورک میں کمٹ کیا جاتا ہے اور پھیلایا جاتا ہے۔ + +کمپیوٹیشن کی درخواستوں کو ٹرانزیکشن کی درخواستیں کہا جاتا ہے؛ تمام ٹرانزیکشنز کا ریکارڈ اور EVM کی موجودہ اسٹیٹ بلاک چین پر محفوظ ہو جاتی ہے، جو بدلے میں تمام نوڈس کے ذریعے محفوظ کی جاتی ہے اور اس پر اتفاق کیا جاتا ہے۔ + +کرپٹوگرافک میکانزم اس بات کو یقینی بناتے ہیں کہ ایک بار ٹرانزیکشنز کی توثیق ہو جانے اور بلاک چین میں شامل ہو جانے کے بعد، ان کے ساتھ بعد میں چھیڑ چھاڑ نہیں کی جا سکتی۔ یہی میکانزم اس بات کو بھی یقینی بناتے ہیں کہ تمام ٹرانزیکشنز پر دستخط کیے جائیں اور مناسب "اجازتوں" کے ساتھ عملدرآمد کیا جائے (ایلس کے علاوہ کوئی بھی اس کے اکاؤنٹ سے ڈیجیٹل اثاثے نہیں بھیج سکتا)۔ + +## Ether کیا ہے ؟ {#what-is-ether} + +**ایتھر (ETH)** ایتھیریم کی مقامی کرپٹو کرنسی ہے۔ ETH کا مقصد کمپیوٹیشن کے لیے ایک مارکیٹ کی اجازت دینا ہے۔ ایسی مارکیٹ شرکاء کو ٹرانزیکشن کی درخواستوں کی تصدیق اور عملدرآمد کرنے اور نیٹ ورک کو کمپیوٹیشنل وسائل فراہم کرنے کے لیے ایک معاشی ترغیب فراہم کرتی ہے۔ + +کوئی بھی شریک جو ٹرانزیکشن کی درخواست کو براڈکاسٹ کرتا ہے اسے نیٹ ورک کو باؤنٹی کے طور پر کچھ مقدار میں ETH بھی پیش کرنا ہوگا۔ نیٹ ورک باؤنٹی کا کچھ حصہ برن کر دے گا اور باقی اس شخص کو انعام دے گا جو بالآخر ٹرانزیکشن کی تصدیق کرنے، اسے عمل میں لانے، اسے بلاک چین پر کمٹ کرنے، اور اسے نیٹ ورک پر براڈکاسٹ کرنے کا کام کرتا ہے۔ + +ادا کی گئی ETH کی رقم کمپیوٹیشن کرنے کے لیے درکار وسائل سے مطابقت رکھتی ہے۔ یہ باؤنٹیز بدنیتی پر مبنی شرکاء کو لامحدود کمپیوٹیشن یا دیگر وسائل سے بھرپور اسکرپٹس کے عملدرآمد کی درخواست کرکے جان بوجھ کر نیٹ ورک کو بند کرنے سے بھی روکتی ہیں، کیونکہ ان شرکاء کو کمپیوٹیشن کے وسائل کے لیے ادائیگی کرنی ہوگی۔ + +ETH کو تین اہم طریقوں سے نیٹ ورک کو کرپٹو-معاشی سیکیورٹی فراہم کرنے کے لیے بھی استعمال کیا جاتا ہے: 1) اس کا استعمال ان ویلیڈیٹرز کو انعام دینے کے لیے کیا جاتا ہے جو بلاکس تجویز کرتے ہیں یا دوسرے ویلیڈیٹرز کے بے ایمانی پر مبنی رویے کی نشاندہی کرتے ہیں؛ 2) اسے ویلیڈیٹرز کے ذریعے اسٹیک کیا جاتا ہے، جو بے ایمانی پر مبنی رویے کے خلاف کولیٹرل کے طور پر کام کرتا ہے — اگر ویلیڈیٹرز غلط برتاؤ کرنے کی کوشش کرتے ہیں تو ان کا ETH تباہ کیا جا سکتا ہے؛ 3) اس کا استعمال نئے تجویز کردہ بلاکس کے لیے 'ووٹوں' کا وزن کرنے کے لیے کیا جاتا ہے، جو اتفاق رائے کے میکانزم کے فورک-چوائس حصے میں شامل ہوتا ہے۔ + +## Smart contracts کیا ہیں؟ اسمارٹ کنٹریکٹس کیا ہیں؟ {#what-are-smart-contracts} + +عملی طور پر، جب بھی شرکاء EVM پر کمپیوٹیشن کی درخواست کرنا چاہتے ہیں تو وہ نیا کوڈ نہیں لکھتے ہیں۔ بلکہ، ایپلیکیشن ڈیولپرز پروگرامز (کوڈ کے دوبارہ قابل استعمال ٹکڑے) کو EVM اسٹیٹ میں اپ لوڈ کرتے ہیں، اور صارفین مختلف پیرامیٹرز کے ساتھ ان کوڈ کے ٹکڑوں کو عمل میں لانے کی درخواست کرتے ہیں۔ ہم نیٹ ورک کے ذریعے اپ لوڈ اور عمل میں لائے گئے پروگراموں کو "اسمارٹ کنٹریکٹس" کہتے ہیں۔ + +ایک بہت ہی بنیادی سطح پر، آپ ایک اسمارٹ کنٹریکٹ کو ایک قسم کی وینڈنگ مشین کی طرح سمجھ سکتے ہیں: ایک اسکرپٹ جو، جب کچھ پیرامیٹرز کے ساتھ کال کیا جاتا ہے، تو کچھ شرائط پوری ہونے پر کچھ اعمال یا کمپیوٹیشن انجام دیتا ہے۔ مثال کے طور پر، ایک سادہ وینڈر اسمارٹ کنٹریکٹ ایک ڈیجیٹل اثاثے کی ملکیت بنا سکتا ہے اور تفویض کر سکتا ہے اگر کال کرنے والا کسی مخصوص وصول کنندہ کو ETH بھیجتا ہے۔ + +کوئی بھی ڈیولپر ایک اسمارٹ کنٹریکٹ بنا سکتا ہے اور اسے نیٹ ورک کے لیے عوامی بنا سکتا ہے، بلاک چین کو اس کی ڈیٹا لیئر کے طور پر استعمال کرتے ہوئے، نیٹ ورک کو ادا کی جانے والی فیس کے بدلے۔ کوئی بھی صارف پھر اسمارٹ کنٹریکٹ کو اس کے کوڈ پر عملدرآمد کرنے کے لیے کال کر سکتا ہے، پھر سے نیٹ ورک کو ادا کی جانے والی فیس کے بدلے۔ + +اس طرح، اسمارٹ کنٹریکٹس کے ساتھ، ڈیولپرز من مانی طور پر پیچیدہ صارف کا سامنا کرنے والی ایپس اور خدمات جیسے کہ: مارکیٹ پلیس، مالیاتی آلات، گیمز وغیرہ بنا اور تعینات کر سکتے ہیں۔ + +## اصطلاحات {#terminology} + +### بلاک چین {#blockchain} + +ان تمام بلاکس کا سلسلہ جو نیٹ ورک کی تاریخ میں ایتھیریم نیٹ ورک پر کمٹ کیے گئے ہیں۔ اس کا نام اس لیے رکھا گیا ہے کیونکہ ہر بلاک میں پچھلے بلاک کا حوالہ ہوتا ہے، جو ہمیں تمام بلاکس پر (اور اس طرح عین تاریخ پر) ایک ترتیب برقرار رکھنے میں مدد کرتا ہے۔ + +### ETH {#eth} + +**ایتھر (ETH)** ایتھیریم کی مقامی کرپٹو کرنسی ہے۔ صارفین اپنے کوڈ پر عملدرآمد کی درخواستوں کو پورا کروانے کے لیے دوسرے صارفین کو ETH ادا کرتے ہیں۔ + +[ETH پر مزید](/developers/docs/intro-to-ether/) + +### EVM {#evm} + +ایتھیریم ورچوئل مشین ایک عالمی ورچوئل کمپیوٹر ہے جس کی اسٹیٹ کو ایتھیریم نیٹ ورک پر ہر شریک ذخیرہ کرتا ہے اور اس پر متفق ہوتا ہے۔ کوئی بھی شریک EVM پر من مانی کوڈ کے عملدرآمد کی درخواست کر سکتا ہے؛ کوڈ پر عملدرآمد EVM کی اسٹیٹ کو تبدیل کرتا ہے۔ + +[EVM پر مزید](/developers/docs/evm/) + +### نوڈس {#nodes} + +حقیقی زندگی کی مشینیں جو EVM اسٹیٹ کو ذخیرہ کر رہی ہیں۔ نوڈس EVM اسٹیٹ اور نئی اسٹیٹ کی تبدیلیوں کے بارے میں معلومات پھیلانے کے لیے ایک دوسرے سے بات چیت کرتے ہیں۔ کوئی بھی صارف نوڈ سے کوڈ پر عملدرآمد کی درخواست کو براڈکاسٹ کرکے کوڈ پر عملدرآمد کی درخواست بھی کر سکتا ہے۔ ایتھیریم نیٹ ورک خود تمام ایتھیریم نوڈس اور ان کے مواصلات کا مجموعہ ہے۔ + +[نوڈس پر مزید](/developers/docs/nodes-and-clients/) + +### اکاؤنٹس {#accounts} + +جہاں ETH ذخیرہ کیا جاتا ہے۔ صارفین اکاؤنٹس شروع کر سکتے ہیں، اکاؤنٹس میں ETH جمع کر سکتے ہیں، اور اپنے اکاؤنٹس سے دوسرے صارفین کو ETH منتقل کر سکتے ہیں۔ اکاؤنٹس اور اکاؤنٹ بیلنس EVM میں ایک بڑی ٹیبل میں محفوظ کیے جاتے ہیں؛ وہ مجموعی EVM اسٹیٹ کا ایک حصہ ہیں۔ + +[اکاؤنٹس پر مزید](/developers/docs/accounts/) + +### ٹرانزیکشنز {#transactions} + +"ٹرانزیکشن کی درخواست" EVM پر کوڈ پر عملدرآمد کی درخواست کے لیے رسمی اصطلاح ہے، اور "ٹرانزیکشن" ایک پوری کی گئی ٹرانزیکشن کی درخواست اور EVM اسٹیٹ میں متعلقہ تبدیلی ہے۔ کوئی بھی صارف نوڈ سے نیٹ ورک پر ٹرانزیکشن کی درخواست کو براڈکاسٹ کر سکتا ہے۔ ٹرانزیکشن کی درخواست کو متفقہ EVM اسٹیٹ پر اثر انداز ہونے کے لیے، اسے دوسرے نوڈ کے ذریعے توثیق، عملدرآمد، اور "نیٹ ورک پر کمٹ" کیا جانا چاہیے۔ کسی بھی کوڈ پر عملدرآمد EVM میں اسٹیٹ کی تبدیلی کا سبب بنتا ہے؛ کمٹمنٹ پر، یہ اسٹیٹ کی تبدیلی نیٹ ورک کے تمام نوڈس کو براڈکاسٹ کی جاتی ہے۔ ٹرانزیکشنز کی کچھ مثالیں: + +- میرے اکاؤنٹ سے ایلس کے اکاؤنٹ میں X ETH بھیجیں۔ +- کچھ اسمارٹ کنٹریکٹ کوڈ کو EVM اسٹیٹ میں شائع کریں۔ +- EVM میں ایڈریس X پر اسمارٹ کنٹریکٹ کے کوڈ کو، دلائل Y کے ساتھ عمل میں لائیں۔ + +[ٹرانزیکشنز پر مزید](/developers/docs/transactions/) + +### بلاکس {#blocks} + +ٹرانزیکشنز کا حجم بہت زیادہ ہے، اس لیے ٹرانزیکشنز کو بیچوں، یا بلاکس میں "کمٹ" کیا جاتا ہے۔ بلاکس میں عام طور پر درجنوں سے سینکڑوں ٹرانزیکشنز ہوتی ہیں۔ + +[بلاک کے بارے میں مزید](/developers/docs/blocks/) + +### اسمارٹ کنٹریکٹس {#smart-contracts} + +کوڈ کا ایک دوبارہ قابل استعمال ٹکڑا (ایک پروگرام) جسے ایک ڈیولپر EVM اسٹیٹ میں شائع کرتا ہے۔ کوئی بھی ٹرانزیکشن کی درخواست کرکے اسمارٹ کنٹریکٹ کوڈ پر عملدرآمد کی درخواست کر سکتا ہے۔ کیونکہ ڈیولپرز EVM میں من مانی قابل عمل ایپلی کیشنز (گیمز، مارکیٹ پلیس، مالیاتی آلات، وغیرہ) لکھ سکتے ہیں۔ اسمارٹ کنٹریکٹس شائع کرکے، انہیں اکثر [dapps، یا غیر مرکزی ایپس](/developers/docs/dapps/) بھی کہا جاتا ہے۔ + +[اسمارٹ کنٹریکٹس پر مزید](/developers/docs/smart-contracts/) + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم وائٹ پیپر](/whitepaper/) +- [ایتھیریم آخر کام کیسے کرتا ہے؟](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _پریتی کسیریڈی_ (**NB** یہ وسیلہ اب بھی قیمتی ہے لیکن آگاہ رہیں کہ یہ [دی مرج](/roadmap/merge) سے پہلے کا ہے اور اس لیے اب بھی ایتھیریم کے پروف-آف-ورک میکانزم کا حوالہ دیتا ہے - ایتھیریم کو دراصل اب [پروف-آف-اسٹیک](/developers/docs/consensus-mechanisms/pos) کا استعمال کرتے ہوئے محفوظ کیا گیا ہے) + +### کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + +یہ ویڈیو سیریز بنیادی موضوعات کی ایک مکمل کھوج پیش کرتی ہے: + + + +[ایتھیریم کی بنیادی باتیں پلے لسٹ](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [ایتھیریم کے لیے ایک ڈیولپر کی گائیڈ، حصہ 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– پائتھن اور web3.py کا استعمال کرتے ہوئے ایتھیریم کی ایک بہت ابتدائیوں کے لیے دوستانہ کھوج_ diff --git a/public/content/translations/ur/developers/docs/mev/index.md b/public/content/translations/ur/developers/docs/mev/index.md new file mode 100644 index 00000000000..283a269f5e8 --- /dev/null +++ b/public/content/translations/ur/developers/docs/mev/index.md @@ -0,0 +1,221 @@ +--- +title: "زیادہ سے زیادہ قابل قدر قیمت (MEV)" +description: "زیادہ سے زیادہ قابل قدر قیمت (MEV) کا تعارف" +lang: ur-in +--- + +زیادہ سے زیادہ قابل قدر قیمت (MEV) سے مراد وہ زیادہ سے زیادہ قیمت ہے جو ایک بلاک میں ٹرانزیکشنز کی ترتیب کو شامل کرنے، خارج کرنے، اور تبدیل کرنے کے ذریعے معیاری بلاک انعام اور گیس فیس کے علاوہ بلاک پروڈکشن سے نکالی جا سکتی ہے۔ + +## زیادہ سے زیادہ قابل قدر قیمت {#maximal-extractable-value} + +زیادہ سے زیادہ قابل قدر قیمت کا اطلاق سب سے پہلے [ثبوتِ کار](/developers/docs/consensus-mechanisms/pow/) کے تناظر میں کیا گیا تھا، اور ابتدائی طور پر اسے \"مائنر ایکسٹریکٹ ایبل ویلیو\" کہا جاتا تھا۔ اس کی وجہ یہ ہے کہ ثبوتِ کار میں، مائنرز ٹرانزیکشن کی شمولیت، اخراج اور ترتیب کو کنٹرول کرتے ہیں۔ تاہم، [دی مرج](/roadmap/merge) کے ذریعے ثبوتِ حصص میں منتقلی کے بعد سے تصدیق کنندگان ان کرداروں کے ذمہ دار ہیں، اور مائننگ اب Ethereum پروٹوکول کا حصہ نہیں ہے۔ تاہم، قیمت نکالنے کے طریقے اب بھی موجود ہیں، اس لیے اب اس کی بجائے \"زیادہ سے زیادہ قابل قدر قیمت\" کی اصطلاح استعمال کی جاتی ہے۔ + +## شرائط {#prerequisites} + +یقینی بنائیں کہ آپ [ٹرانزیکشنز](/developers/docs/transactions/)، [بلاکس](/developers/docs/blocks/)، [ثبوتِ حصص](/developers/docs/consensus-mechanisms/pos) اور [گیس](/developers/docs/gas/) سے واقف ہیں۔ [ڈی ایپس](/apps/) اور [DeFi](/defi/) سے واقفیت بھی مددگار ہے۔ + +## MEV ایکسٹریکشن {#mev-extraction} + +نظریاتی طور پر MEV مکمل طور پر تصدیق کنندگان کو حاصل ہوتا ہے کیونکہ وہ واحد پارٹی ہیں جو ایک منافع بخش MEV موقع کی تکمیل کی ضمانت دے سکتے ہیں۔ تاہم، عملی طور پر، MEV کا ایک بڑا حصہ آزاد نیٹ ورک کے شرکاء کے ذریعے نکالا جاتا ہے جنہیں \"سرچرز\" کہا جاتا ہے۔ سرچرز بلاک چین ڈیٹا پر پیچیدہ الگورتھم چلاتے ہیں تاکہ منافع بخش MEV مواقع کا پتہ لگایا جا سکے اور ان کے پاس بوٹس ہوتے ہیں جو خود بخود ان منافع بخش ٹرانزیکشنز کو نیٹ ورک پر جمع کر دیتے ہیں۔ + +تصدیق کنندگان کو پھر بھی مکمل MEV رقم کا ایک حصہ ملتا ہے کیونکہ سرچرز ایک بلاک میں اپنے منافع بخش ٹرانزیکشنز کی شمولیت کے زیادہ امکان کے بدلے میں زیادہ گیس فیس (جو تصدیق کنندہ کو جاتی ہے) ادا کرنے کو تیار رہتے ہیں۔ یہ مانتے ہوئے کہ سرچرز معاشی طور پر عقلی ہیں، گیس فیس جو ایک سرچر ادا کرنے کو تیار ہوگا وہ سرچر کے MEV کے 100% تک کی رقم ہوگی (کیونکہ اگر گیس فیس زیادہ ہوتی تو سرچر کو نقصان ہوتا)۔ + +اس کے ساتھ، کچھ انتہائی مسابقتی MEV مواقع کے لیے، جیسے کہ [DEX آربٹریج](#mev-examples-dex-arbitrage)، سرچرز کو تصدیق کنندہ کو گیس فیس میں اپنی کل MEV آمدنی کا 90% یا اس سے بھی زیادہ ادا کرنا پڑ سکتا ہے کیونکہ بہت سے لوگ ایک ہی منافع بخش آربٹریج ٹریڈ چلانا چاہتے ہیں۔ اس کی وجہ یہ ہے کہ اس بات کی ضمانت دینے کا واحد طریقہ ہے کہ ان کا آربٹریج ٹرانزیکشن چلے گا یہ ہے کہ وہ سب سے زیادہ گیس کی قیمت کے ساتھ ٹرانزیکشن جمع کرائیں۔ + +### گیس گولفنگ {#mev-extraction-gas-golfing} + +اس ڈائنامک نے \"گیس گولفنگ\" میں اچھا ہونا - یعنی ٹرانزیکشنز کو اس طرح پروگرام کرنا کہ وہ کم سے کم گیس استعمال کریں - ایک مسابقتی فائدہ بنا دیا ہے، کیونکہ یہ سرچرز کو اپنی کل گیس فیس کو مستقل رکھتے ہوئے زیادہ گیس کی قیمت مقرر کرنے کی اجازت دیتا ہے (کیونکہ گیس فیس = گیس کی قیمت \* استعمال شدہ گیس)۔ + +کچھ مشہور گیس گولف تکنیکوں میں شامل ہیں: ایسے پتے استعمال کرنا جو صفر کی لمبی سٹرنگ سے شروع ہوتے ہیں (مثال کے طور پر، [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)) کیونکہ وہ ذخیرہ کرنے کے لیے کم جگہ (اور اس وجہ سے گیس) لیتے ہیں؛ اور معاہدوں میں چھوٹے [ERC-20](/developers/docs/standards/tokens/erc-20/) ٹوکن بیلنس چھوڑنا، کیونکہ اسٹوریج سلاٹ کو شروع کرنے میں زیادہ گیس لگتی ہے (اگر بیلنس 0 ہو) بہ نسبت اسٹوریج سلاٹ کو اپ ڈیٹ کرنے کے۔ گیس کے استعمال کو کم کرنے کے لیے مزید تکنیکیں تلاش کرنا سرچرز کے درمیان تحقیق کا ایک فعال شعبہ ہے۔ + +### عمومی فرنٹ رنرز {#mev-extraction-generalized-frontrunners} + +منافع بخش MEV مواقع کا پتہ لگانے کے لیے پیچیدہ الگورتھم پروگرام کرنے کے بجائے، کچھ سرچرز عمومی فرنٹ رنرز چلاتے ہیں۔ عمومی فرنٹ رنرز ایسے بوٹس ہیں جو منافع بخش ٹرانزیکشنز کا پتہ لگانے کے لیے میم پول پر نظر رکھتے ہیں۔ فرنٹ رنر ممکنہ طور پر منافع بخش ٹرانزیکشن کے کوڈ کو کاپی کرے گا، پتوں کو فرنٹ رنر کے پتے سے بدل دے گا، اور ٹرانزیکشن کو مقامی طور پر چلائے گا تاکہ یہ دو بار چیک کیا جا سکے کہ ترمیم شدہ ٹرانزیکشن فرنٹ رنر کے پتے پر منافع کا باعث بنتا ہے۔ اگر ٹرانزیکشن واقعی منافع بخش ہے، تو فرنٹ رنر تبدیل شدہ پتے اور زیادہ گیس کی قیمت کے ساتھ ترمیم شدہ ٹرانزیکشن جمع کرائے گا، اصل ٹرانزیکشن کو \"فرنٹ رننگ\" کرے گا اور اصل سرچر کا MEV حاصل کرے گا۔ + +### فلیش بوٹس {#mev-extraction-flashbots} + +Flashbots ایک آزاد پروجیکٹ ہے جو ایگزیکیوشن کلائنٹس کو ایک ایسی سروس کے ساتھ توسیع دیتا ہے جو سرچرز کو عوامی میم پول میں ظاہر کیے بغیر تصدیق کنندگان کو MEV ٹرانزیکشنز جمع کرانے کی اجازت دیتا ہے۔ یہ ٹرانزیکشنز کو عمومی فرنٹ رنرز کے ذریعے فرنٹ رن ہونے سے روکتا ہے۔ + +## MEV کی مثالیں {#mev-examples} + +MEV بلاک چین پر چند طریقوں سے ابھرتا ہے۔ + +### DEX آربٹریج {#mev-examples-dex-arbitrage} + +[غیر مرکزی تبادلہ](/glossary/#dex) (DEX) آربٹریج سب سے آسان اور سب سے مشہور MEV موقع ہے۔ نتیجے کے طور پر، یہ سب سے زیادہ مسابقتی بھی ہے۔ + +یہ اس طرح کام کرتا ہے: اگر دو DEXs ایک ٹوکن کو دو مختلف قیمتوں پر پیش کر رہے ہیں، تو کوئی شخص کم قیمت والے DEX پر ٹوکن خرید سکتا ہے اور اسے زیادہ قیمت والے DEX پر ایک ہی، ایٹمی ٹرانزیکشن میں بیچ سکتا ہے۔ بلاک چین کے میکانکس کی بدولت، یہ سچ ہے، بغیر خطرے کے آربٹریج ہے۔ + +یہاں ایک منافع بخش آربٹریج ٹرانزیکشن کی [ایک مثال](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) ہے جہاں ایک سرچر نے Uniswap بمقابلہ Sushiswap پر ETH/DAI جوڑی کی مختلف قیمتوں کا فائدہ اٹھا کر 1,000 ETH کو 1,045 ETH میں تبدیل کیا۔ + +### لیکویڈیشنز {#mev-examples-liquidations} + +ادھار دینے والے پروٹوکول لیکویڈیشنز ایک اور مشہور MEV موقع پیش کرتے ہیں۔ + +Maker اور Aave جیسے ادھار دینے والے پروٹوکولز صارفین سے کچھ کولیٹرل (مثلاً ETH) جمع کرانے کا مطالبہ کرتے ہیں۔ یہ جمع شدہ کولیٹرل پھر دوسرے صارفین کو ادھار دینے کے لیے استعمال کیا جاتا ہے۔ + +صارفین پھر اپنی ضرورت کے مطابق دوسروں سے اثاثے اور ٹوکن ادھار لے سکتے ہیں (مثال کے طور پر، اگر آپ MakerDAO گورننس کی تجویز میں ووٹ دینا چاہتے ہیں تو آپ MKR ادھار لے سکتے ہیں) اپنے جمع شدہ کولیٹرل کے ایک خاص فیصد تک۔ مثال کے طور پر، اگر ادھار لینے کی رقم زیادہ سے زیادہ 30% ہے، تو ایک صارف جو پروٹوکول میں 100 DAI جمع کرتا ہے، وہ 30 DAI مالیت کا دوسرا اثاثہ ادھار لے سکتا ہے۔ پروٹوکول ادھار لینے کی طاقت کا قطعی فیصد طے کرتا ہے۔ + +جیسے جیسے قرض لینے والے کے کولیٹرل کی قیمت میں اتار چڑھاؤ آتا ہے، اسی طرح ان کی ادھار لینے کی طاقت میں بھی اتار چڑھاؤ آتا ہے۔ اگر، مارکیٹ میں اتار چڑھاؤ کی وجہ سے، ادھار لیے گئے اثاثوں کی قیمت ان کے کولیٹرل کی قیمت کے 30% سے تجاوز کر جاتی ہے (دوبارہ، قطعی فیصد پروٹوکول کے ذریعے طے کیا جاتا ہے)، تو پروٹوکول عام طور پر کسی کو بھی کولیٹرل کو لیکویڈیٹ کرنے کی اجازت دیتا ہے، فوری طور پر قرض دہندگان کو ادائیگی کرتا ہے (یہ روایتی مالیات میں [مارجن کالز](https://www.investopedia.com/terms/m/margincall.asp) کے کام کرنے کے طریقے سے ملتا جلتا ہے)۔ اگر لیکویڈیٹ کیا جاتا ہے، تو قرض لینے والے کو عام طور پر ایک بھاری لیکویڈیشن فیس ادا کرنی پڑتی ہے، جس میں سے کچھ لیکویڈیٹر کو جاتا ہے — یہی وہ جگہ ہے جہاں MEV کا موقع آتا ہے۔ + +سرچرز بلاک چین ڈیٹا کو جتنی جلدی ممکن ہو پارس کرنے کے لیے مقابلہ کرتے ہیں تاکہ یہ معلوم کیا جا سکے کہ کن قرض لینے والوں کو لیکویڈیٹ کیا جا سکتا ہے اور لیکویڈیشن ٹرانزیکشن جمع کرانے والے پہلے شخص بنیں اور اپنے لیے لیکویڈیشن فیس جمع کریں۔ + +### سینڈوچ ٹریڈنگ {#mev-examples-sandwich-trading} + +سینڈوچ ٹریڈنگ MEV نکالنے کا ایک اور عام طریقہ ہے۔ + +سینڈوچ کرنے کے لیے، ایک سرچر بڑی DEX ٹریڈز کے لیے میم پول پر نظر رکھے گا۔ مثال کے طور پر، فرض کریں کہ کوئی Uniswap پر DAI کے ساتھ 10,000 UNI خریدنا چاہتا ہے۔ اس شدت کی ایک ٹریڈ کا UNI/DAI جوڑی پر ایک بامعنی اثر پڑے گا، جو ممکنہ طور پر DAI کے مقابلے میں UNI کی قیمت میں نمایاں اضافہ کرے گا۔ + +ایک سرچر UNI/DAI جوڑی پر اس بڑی ٹریڈ کے تخمینی قیمت کے اثر کا حساب لگا سکتا ہے اور بڑی ٹریڈ سے فوراً _پہلے_ ایک بہترین خرید کا آرڈر دے سکتا ہے، سستے میں UNI خرید کر، پھر بڑی ٹریڈ کے فوراً _بعد_ ایک فروخت کا آرڈر دے سکتا ہے، اسے بڑی آرڈر کی وجہ سے پیدا ہونے والی زیادہ قیمت پر بیچ سکتا ہے۔ + +تاہم، سینڈوچنگ زیادہ خطرناک ہے کیونکہ یہ ایٹمی نہیں ہے (جیسا کہ اوپر بیان کیا گیا ہے، DEX آربٹریج کے برعکس) اور [سالمونیلا حملے](https://github.com/Defi-Cartel/salmonella) کا شکار ہے۔ + +### NFT MEV {#mev-examples-nfts} + +NFT اسپیس میں MEV ایک ابھرتا ہوا رجحان ہے، اور ضروری نہیں کہ منافع بخش ہو۔ + +تاہم، چونکہ NFT ٹرانزیکشنز اسی بلاک چین پر ہوتی ہیں جو دیگر تمام Ethereum ٹرانزیکشنز کے ذریعے شیئر کی جاتی ہیں، اس لیے سرچرز NFT مارکیٹ میں بھی روایتی MEV مواقع میں استعمال ہونے والی تکنیکوں جیسی تکنیکیں استعمال کر سکتے ہیں۔ + +مثال کے طور پر، اگر کوئی مشہور NFT ڈراپ ہے اور ایک سرچر ایک مخصوص NFT یا NFTs کا سیٹ چاہتا ہے، تو وہ ایک ٹرانزیکشن پروگرام کر سکتے ہیں تاکہ وہ NFT خریدنے کے لیے لائن میں پہلے ہوں، یا وہ ایک ہی ٹرانزیکشن میں NFTs کا پورا سیٹ خرید سکتے ہیں۔ یا اگر کوئی NFT [غلطی سے کم قیمت پر درج](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent) ہو جاتا ہے، تو ایک سرچر دوسرے خریداروں کو فرنٹ رن کر کے اسے سستے میں حاصل کر سکتا ہے۔ + +NFT MEV کی ایک نمایاں مثال اس وقت پیش آئی جب ایک سرچر نے قیمت کی نچلی سطح پر ہر ایک Cryptopunk کو [خریدنے](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) کے لیے 7 ملین ڈالر خرچ کیے۔ ایک بلاک چین محقق نے [ٹویٹر پر وضاحت کی](https://twitter.com/IvanBogatyy/status/1422232184493121538) کہ خریدار نے اپنی خریداری کو خفیہ رکھنے کے لیے ایک MEV فراہم کنندہ کے ساتھ کیسے کام کیا۔ + +### لمبی دُم {#mev-examples-long-tail} + +DEX آربٹریج، لیکویڈیشنز، اور سینڈوچ ٹریڈنگ سبھی بہت مشہور MEV مواقع ہیں اور نئے سرچرز کے لیے منافع بخش ہونے کا امکان نہیں ہے۔ تاہم، کم معروف MEV مواقع کی ایک لمبی دُم ہے (NFT MEV دلیل کے طور پر ایسا ہی ایک موقع ہے)۔ + +وہ سرچرز جو ابھی شروعات کر رہے ہیں وہ اس لمبی دُم میں MEV کی تلاش کر کے مزید کامیابی حاصل کر سکتے ہیں۔ فلیش بوٹ کا [MEV جاب بورڈ](https://github.com/flashbots/mev-job-board) کچھ ابھرتے ہوئے مواقع کی فہرست دیتا ہے۔ + +## MEV کے اثرات {#effects-of-mev} + +MEV سب برا نہیں ہے — Ethereum پر MEV کے مثبت اور منفی دونوں نتائج ہیں۔ + +### اچھا {#effects-of-mev-the-good} + +بہت سے DeFi پروجیکٹس اپنے پروٹوکولز کی افادیت اور استحکام کو یقینی بنانے کے لیے معاشی طور پر عقلی اداکاروں پر انحصار کرتے ہیں۔ مثال کے طور پر، DEX آربٹریج اس بات کو یقینی بناتا ہے کہ صارفین کو اپنے ٹوکنز کے لیے بہترین، سب سے صحیح قیمتیں ملیں، اور ادھار دینے والے پروٹوکولز اس وقت تیز رفتار لیکویڈیشنز پر انحصار کرتے ہیں جب قرض لینے والے کولیٹرلائزیشن کے تناسب سے نیچے گر جاتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ قرض دہندگان کو ادائیگی واپس مل جائے۔ + +عقلی سرچرز کے بغیر جو معاشی ناکارہیوں کو تلاش کرتے اور ٹھیک کرتے ہیں اور پروٹوکولز کے معاشی مراعات کا فائدہ اٹھاتے ہیں، DeFi پروٹوکولز اور dapps عام طور پر اتنے مضبوط نہیں ہوسکتے ہیں جتنے آج ہیں۔ + +### برا {#effects-of-mev-the-bad} + +ایپلیکیشن لیئر پر، MEV کی کچھ شکلیں، جیسے سینڈوچ ٹریڈنگ، صارفین کے لیے غیر واضح طور پر بدتر تجربے کا باعث بنتی ہیں۔ وہ صارفین جو سینڈوچ ہوتے ہیں انہیں اپنی ٹریڈز پر بڑھی ہوئی سلیپیج اور بدتر ایگزیکیوشن کا سامنا کرنا پڑتا ہے۔ + +نیٹ ورک لیئر پر، عمومی فرنٹ رنرز اور گیس کی قیمتوں کی نیلامیاں جن میں وہ اکثر مشغول رہتے ہیں (جب دو یا دو سے زیادہ فرنٹ رنرز اپنے ٹرانزیکشن کو اگلے بلاک میں شامل کرنے کے لیے مقابلہ کرتے ہیں، بتدریج اپنے ٹرانزیکشنز کی گیس کی قیمت بڑھاتے ہوئے) نیٹ ورک کی بھیڑ اور باقی سب کے لیے زیادہ گیس کی قیمتوں کا باعث بنتے ہیں جو باقاعدہ ٹرانزیکشنز چلانے کی کوشش کر رہے ہیں۔ + +بلاکس _کے اندر_ جو ہو رہا ہے اس سے آگے، MEV کا بلاکس _کے درمیان_ بھی نقصان دہ اثرات ہو سکتے ہیں۔ اگر کسی بلاک میں دستیاب MEV معیاری بلاک انعام سے نمایاں طور پر تجاوز کر جاتا ہے، تو تصدیق کنندگان کو بلاکس کو دوبارہ منظم کرنے اور اپنے لیے MEV حاصل کرنے کی ترغیب دی جا سکتی ہے، جس سے بلاک چین کی دوبارہ تنظیم اور اتفاق رائے میں عدم استحکام پیدا ہوتا ہے۔ + +بلاک چین کی دوبارہ تنظیم کے اس امکان کو [پہلے بٹ کوائن بلاک چین پر تلاش کیا گیا ہے](https://dl.acm.org/doi/10.1145/2976749.2978408)۔ جیسے جیسے بٹ کوائن کا بلاک انعام آدھا ہوتا جاتا ہے اور ٹرانزیکشن فیس بلاک انعام کا ایک بڑا حصہ بناتی جاتی ہے، ایسی صورتحال پیدا ہوتی ہے جہاں مائنرز کے لیے اگلے بلاک کا انعام چھوڑ دینا اور اس کے بجائے زیادہ فیس والے ماضی کے بلاکس کو دوبارہ مائن کرنا معاشی طور پر عقلی ہو جاتا ہے۔ MEV کی ترقی کے ساتھ، اسی طرح کی صورتحال Ethereum میں بھی ہو سکتی ہے، جو بلاک چین کی سالمیت کو خطرے میں ڈالتی ہے۔ + +## MEV کی حالت {#state-of-mev} + +MEV ایکسٹریکشن 2021 کے اوائل میں بہت بڑھ گیا، جس کے نتیجے میں سال کے پہلے چند مہینوں میں گیس کی قیمتیں انتہائی زیادہ ہو گئیں۔ Flashbots کے MEV ریلے کے ابھرنے نے عمومی فرنٹ رنرز کی تاثیر کو کم کر دیا ہے اور گیس کی قیمتوں کی نیلامیوں کو آف چین لے گیا ہے، جس سے عام صارفین کے لیے گیس کی قیمتیں کم ہو گئی ہیں۔ + +جبکہ بہت سے سرچرز اب بھی MEV سے اچھا پیسہ کما رہے ہیں، جیسے جیسے مواقع زیادہ مشہور ہوتے جاتے ہیں اور زیادہ سے زیادہ سرچرز اسی موقع کے لیے مقابلہ کرتے ہیں، تصدیق کنندگان کل MEV آمدنی کا زیادہ سے زیادہ حصہ حاصل کریں گے (کیونکہ اسی طرح کی گیس نیلامیاں جیسا کہ اصل میں اوپر بیان کیا گیا ہے Flashbots میں بھی ہوتی ہیں، اگرچہ نجی طور پر، اور تصدیق کنندگان نتیجے میں آنے والی گیس کی آمدنی حاصل کریں گے)۔ MEV بھی Ethereum کے لیے منفرد نہیں ہے، اور جیسے جیسے Ethereum پر مواقع زیادہ مسابقتی ہوتے جاتے ہیں، سرچرز Binance Smart Chain جیسے متبادل بلاک چینز کی طرف بڑھ رہے ہیں، جہاں Ethereum جیسے ہی MEV مواقع کم مقابلے کے ساتھ موجود ہیں۔ + +دوسری طرف، ثبوتِ کار سے ثبوتِ حصص میں منتقلی اور رول اپس کا استعمال کرتے ہوئے Ethereum کو اسکیل کرنے کی جاری کوششیں سبھی MEV کے منظر نامے کو ایسے طریقوں سے تبدیل کرتی ہیں جو ابھی تک کسی حد تک غیر واضح ہیں۔ ابھی تک یہ اچھی طرح سے معلوم نہیں ہے کہ پہلے سے تھوڑا سا معلوم گارنٹی شدہ بلاک پروپوزرز کا ہونا ثبوتِ کار میں امکانی ماڈل کے مقابلے میں MEV ایکسٹریکشن کی حرکیات کو کیسے تبدیل کرتا ہے یا جب [سنگل سیکرٹ لیڈر الیکشن](https://ethresear.ch/t/secret-non-single-leader-election/11789) اور [ڈسٹری بیوٹڈ ویلیڈیٹر ٹیکنالوجی](/staking/dvt/) نافذ کی جاتی ہیں تو یہ کیسے متاثر ہوگا۔ اسی طرح، یہ دیکھنا باقی ہے کہ جب زیادہ تر صارف کی سرگرمی Ethereum سے ہٹا کر اس کے لیئر 2 رول اپس اور شارڈز پر منتقل کر دی جاتی ہے تو MEV کے کیا مواقع موجود ہوتے ہیں۔ + +## Ethereum پروف-آف-اسٹیک (PoS) میں MEV {#mev-in-ethereum-proof-of-stake} + +جیسا کہ وضاحت کی گئی ہے، MEV کے مجموعی صارف کے تجربے اور کنسنسس لیئر کی سیکیورٹی کے لیے منفی مضمرات ہیں۔ لیکن Ethereum کا پروف-آف-اسٹیک کنسنسس (جسے \"دی مرج\" کہا جاتا ہے) میں منتقلی ممکنہ طور پر MEV سے متعلق نئے خطرات متعارف کراتی ہے۔ + +### تصدیق کنندہ مرکزیت {#validator-centralization} + +مرج کے بعد کے Ethereum میں، تصدیق کنندگان (32 ETH کی سیکیورٹی ڈپازٹ کرنے کے بعد) بیکن چین میں شامل کیے گئے بلاکس کی صداقت پر اتفاق رائے پر آتے ہیں۔ چونکہ 32 ETH بہت سے لوگوں کی پہنچ سے باہر ہو سکتا ہے، اس لیے [اسٹیکنگ پول میں شامل ہونا](/staking/pools/) ایک زیادہ قابل عمل آپشن ہو سکتا ہے۔ اس کے باوجود، [سولو اسٹیکرز](/staking/solo/) کی صحت مند تقسیم مثالی ہے، کیونکہ یہ تصدیق کنندگان کی مرکزیت کو کم کرتی ہے اور Ethereum کی سیکیورٹی کو بہتر بناتی ہے۔ + +تاہم، یہ خیال کیا جاتا ہے کہ MEV ایکسٹریکشن تصدیق کنندہ مرکزیت کو تیز کرنے کی صلاحیت رکھتا ہے۔ اس کی وجہ جزوی طور پر یہ ہے کہ، چونکہ تصدیق کنندگان [بلاکس تجویز کرنے کے لیے کم کماتے ہیں](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) بہ نسبت مائنرز کے، MEV ایکسٹریکشن نے [دی مرج](/roadmap/merge/) کے بعد سے [تصدیق کنندہ کی کمائیوں کو بہت متاثر کیا ہے](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb)۔ + +بڑے اسٹیکنگ پولز کے پاس ممکنہ طور پر MEV مواقع کو حاصل کرنے کے لیے ضروری اصلاحات میں سرمایہ کاری کے لیے زیادہ وسائل ہوں گے۔ یہ پولز جتنا زیادہ MEV نکالتے ہیں، ان کے پاس اپنی MEV نکالنے کی صلاحیتوں کو بہتر بنانے (اور مجموعی آمدنی میں اضافہ کرنے) کے لیے اتنے ہی زیادہ وسائل ہوتے ہیں، جو بنیادی طور پر [پیمانے کی معیشتیں](https://www.investopedia.com/terms/e/economiesofscale.asp#) پیدا کرتے ہیں۔ + +کم وسائل کے ساتھ، سولو اسٹیکرز MEV مواقع سے فائدہ اٹھانے سے قاصر ہو سکتے ہیں۔ یہ آزاد تصدیق کنندگان پر اپنی کمائی کو بڑھانے کے لیے طاقتور اسٹیکنگ پولز میں شامل ہونے کے لیے دباؤ بڑھا سکتا ہے، جس سے Ethereum میں غیر مرکزیت کم ہو سکتی ہے۔ + +### اجازت یافتہ میم پولز {#permissioned-mempools} + +سینڈوچنگ اور فرنٹ رننگ حملوں کے جواب میں، تاجر ٹرانزیکشن کی رازداری کے لیے تصدیق کنندگان کے ساتھ آف چین سودے کرنا شروع کر سکتے ہیں۔ ایک ممکنہ MEV ٹرانزیکشن کو عوامی میم پول میں بھیجنے کے بجائے، تاجر اسے براہ راست تصدیق کنندہ کو بھیجتا ہے، جو اسے ایک بلاک میں شامل کرتا ہے اور تاجر کے ساتھ منافع تقسیم کرتا ہے۔ + +\"ڈارک پولز\" اس انتظام کا ایک بڑا ورژن ہیں اور اجازت یافتہ، صرف رسائی والے میم پولز کے طور پر کام کرتے ہیں جو کچھ فیس ادا کرنے کے لیے تیار صارفین کے لیے کھلے ہیں۔ یہ رجحان Ethereum کی اجازت کے بغیر اور اعتماد کے بغیر ہونے کو کم کرے گا اور ممکنہ طور پر بلاک چین کو ایک \"پے-ٹو-پلے\" میکانزم میں تبدیل کر دے گا جو سب سے زیادہ بولی لگانے والے کے حق میں ہو۔ + +اجازت یافتہ میم پولز پچھلے حصے میں بیان کردہ مرکزیت کے خطرات کو بھی تیز کریں گے۔ متعدد تصدیق کنندگان چلانے والے بڑے پولز کو تاجروں اور صارفین کو ٹرانزیکشن کی رازداری کی پیشکش سے فائدہ ہونے کا امکان ہے، جس سے ان کی MEV آمدنی میں اضافہ ہوگا۔ + +مرج کے بعد کے Ethereum میں MEV سے متعلق ان مسائل کا مقابلہ کرنا تحقیق کا ایک بنیادی شعبہ ہے۔ آج تک، دی مرج کے بعد Ethereum کی غیر مرکزیت اور سیکیورٹی پر MEV کے منفی اثرات کو کم کرنے کے لیے تجویز کردہ دو حل [**پروپوزر-بلڈر سیپریشن (PBS)**](/roadmap/pbs/) اور [**بلڈر API**](https://github.com/ethereum/builder-specs) ہیں۔ + +### پروپوزر-بلڈر سیپریشن {#proposer-builder-separation} + +ثبوتِ کار اور ثبوتِ حصص دونوں میں، ایک نوڈ جو ایک بلاک بناتا ہے وہ اسے اتفاق رائے میں حصہ لینے والے دوسرے نوڈز کو چین میں شامل کرنے کے لیے تجویز کرتا ہے۔ ایک نیا بلاک کینونیکل چین کا حصہ بن جاتا ہے جب کوئی دوسرا مائنر اس کے اوپر بناتا ہے (PoW میں) یا اسے تصدیق کنندگان کی اکثریت سے تصدیقیں ملتی ہیں (PoS میں)۔ + +بلاک پروڈیوسر اور بلاک پروپوزر کے کرداروں کا امتزاج وہی ہے جو پہلے بیان کردہ MEV سے متعلق زیادہ تر مسائل کو متعارف کراتا ہے۔ مثال کے طور پر، کنسنسس نوڈز کو MEV کی کمائی کو زیادہ سے زیادہ کرنے کے لیے [ٹائم-بینڈٹ حملوں](https://www.mev.wiki/attack-examples/time-bandit-attack) میں چین کی دوبارہ تنظیموں کو متحرک کرنے کی ترغیب دی جاتی ہے۔ + +[پروپوزر-بلڈر سیپریشن](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) کو MEV کے اثرات کو کم کرنے کے لیے ڈیزائن کیا گیا ہے، خاص طور پر کنسنسس لیئر پر۔ PBS کی بڑی خصوصیت بلاک پروڈیوسر اور بلاک پروپوزر کے قواعد کی علیحدگی ہے۔ تصدیق کنندگان اب بھی بلاکس کی تجویز اور ووٹنگ کے ذمہ دار ہیں، لیکن خصوصی اداروں کی ایک نئی کلاس، جسے **بلاک بلڈرز** کہا جاتا ہے، کو ٹرانزیکشنز کی ترتیب اور بلاکس کی تعمیر کا کام سونپا گیا ہے۔ + +PBS کے تحت، ایک بلاک بلڈر ایک ٹرانزیکشن بنڈل بناتا ہے اور اسے بیکن چین بلاک میں شامل کرنے کے لیے ایک بولی لگاتا ہے (بطور \"ایگزیکیوشن پے لوڈ\")۔ اگلے بلاک کی تجویز کے لیے منتخب کیا گیا تصدیق کنندہ پھر مختلف بولیوں کی جانچ کرتا ہے اور سب سے زیادہ فیس والے بنڈل کا انتخاب کرتا ہے۔ PBS بنیادی طور پر ایک نیلامی مارکیٹ بناتا ہے، جہاں بلڈرز بلاک اسپیس بیچنے والے تصدیق کنندگان کے ساتھ بات چیت کرتے ہیں۔ + +موجودہ PBS ڈیزائن [کمٹ-ریویل اسکیم](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) کا استعمال کرتے ہیں جس میں بلڈرز صرف اپنی بولیوں کے ساتھ بلاک کے مواد (بلاک ہیڈر) کے لیے ایک کرپٹوگرافک کمٹمنٹ شائع کرتے ہیں۔ جیتنے والی بولی کو قبول کرنے کے بعد، پروپوزر ایک دستخط شدہ بلاک پروپوزل بناتا ہے جس میں بلاک ہیڈر شامل ہوتا ہے۔ بلاک بلڈر سے توقع کی جاتی ہے کہ وہ دستخط شدہ بلاک پروپوزل دیکھنے کے بعد مکمل بلاک باڈی شائع کرے گا، اور اسے حتمی شکل دینے سے پہلے تصدیق کنندگان سے کافی [تصدیقیں](/glossary/#attestation) بھی حاصل کرنی ہوں گی۔ + +#### پروپوزر-بلڈر سیپریشن MEV کے اثرات کو کیسے کم کرتا ہے؟ {#how-does-pbs-curb-mev-impact} + +ان-پروٹوکول پروپوزر-بلڈر سیپریشن تصدیق کنندگان کے دائرہ کار سے MEV ایکسٹریکشن کو ہٹا کر کنسنسس پر MEV کے اثر کو کم کرتا ہے۔ اس کے بجائے، خصوصی ہارڈویئر چلانے والے بلاک بلڈرز آگے بڑھ کر MEV کے مواقع حاصل کریں گے۔ + +تاہم، یہ تصدیق کنندگان کو MEV سے متعلق آمدنی سے مکمل طور پر خارج نہیں کرتا، کیونکہ بلڈرز کو اپنے بلاکس کو تصدیق کنندگان سے قبول کروانے کے لیے اونچی بولی لگانی پڑتی ہے۔ اس کے باوجود، چونکہ تصدیق کنندگان اب براہ راست MEV آمدنی کو بہتر بنانے پر توجہ مرکوز نہیں کرتے، ٹائم-بینڈٹ حملوں کا خطرہ کم ہو جاتا ہے۔ + +پروپوزر-بلڈر سیپریشن MEV کے مرکزیت کے خطرات کو بھی کم کرتا ہے۔ مثال کے طور پر، کمٹ-ریویل اسکیم کا استعمال بلڈرز کو اس بات پر بھروسہ کرنے کی ضرورت کو ختم کرتا ہے کہ تصدیق کنندگان MEV کا موقع نہیں چرائیں گے یا اسے دوسرے بلڈرز کے سامنے ظاہر نہیں کریں گے۔ یہ سولو اسٹیکرز کے لیے MEV سے فائدہ اٹھانے کی رکاوٹ کو کم کرتا ہے، ورنہ، بلڈرز آف چین ساکھ والے بڑے پولز کی حمایت کرنے اور ان کے ساتھ آف چین سودے کرنے کا رجحان رکھتے۔ + +اسی طرح، تصدیق کنندگان کو بلڈرز پر بھروسہ کرنے کی ضرورت نہیں ہے کہ وہ بلاک باڈیز کو نہ روکیں یا غلط بلاکس شائع نہ کریں کیونکہ ادائیگی غیر مشروط ہے۔ تصدیق کنندہ کی فیس اب بھی پراسیس ہوتی ہے چاہے مجوزہ بلاک دستیاب نہ ہو یا دوسرے تصدیق کنندگان کی طرف سے غلط قرار دیا جائے۔ بعد کے معاملے میں، بلاک کو صرف ضائع کر دیا جاتا ہے، جس سے بلاک بلڈر کو تمام ٹرانزیکشن فیس اور MEV آمدنی سے محروم ہونا پڑتا ہے۔ + +### بلڈر API {#builder-api} + +جبکہ پروپوزر-بلڈر سیپریشن MEV ایکسٹریکشن کے اثرات کو کم کرنے کا وعدہ کرتا ہے، اسے نافذ کرنے کے لیے کنسنسس پروٹوکول میں تبدیلیوں کی ضرورت ہے۔ خاص طور پر، بیکن چین پر [فورک چوائس](/developers/docs/consensus-mechanisms/pos/#fork-choice) کے اصول کو اپ ڈیٹ کرنے کی ضرورت ہوگی۔ [بلڈر API](https://github.com/ethereum/builder-specs) ایک عارضی حل ہے جس کا مقصد پروپوزر-بلڈر سیپریشن کا ایک ورکنگ نفاذ فراہم کرنا ہے، اگرچہ زیادہ اعتماد کے مفروضوں کے ساتھ۔ + +بلڈر API [انجن API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) کا ایک ترمیم شدہ ورژن ہے جسے کنسنسس لیئر کلائنٹس ایگزیکیوشن لیئر کلائنٹس سے ایگزیکیوشن پے لوڈز کی درخواست کرنے کے لیے استعمال کرتے ہیں۔ جیسا کہ [ایماندار تصدیق کنندہ کی تفصیلات](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) میں بیان کیا گیا ہے، بلاک تجویز کرنے کے فرائض کے لیے منتخب کیے گئے تصدیق کنندگان ایک منسلک ایگزیکیوشن کلائنٹ سے ایک ٹرانزیکشن بنڈل کی درخواست کرتے ہیں، جسے وہ مجوزہ بیکن چین بلاک میں شامل کرتے ہیں۔ + +بلڈر API تصدیق کنندگان اور ایگزیکیوشن لیئر کلائنٹس کے درمیان ایک مڈل ویئر کے طور پر بھی کام کرتا ہے؛ لیکن یہ مختلف ہے کیونکہ یہ بیکن چین پر تصدیق کنندگان کو بیرونی اداروں سے بلاکس حاصل کرنے کی اجازت دیتا ہے (ایک ایگزیکیوشن کلائنٹ کا استعمال کرتے ہوئے مقامی طور پر بلاک بنانے کے بجائے)۔ + +ذیل میں بلڈر API کے کام کرنے کے طریقے کا ایک جائزہ ہے: + +1. بلڈر API تصدیق کنندہ کو ایگزیکیوشن لیئر کلائنٹس چلانے والے بلاک بلڈرز کے نیٹ ورک سے جوڑتا ہے۔ PBS کی طرح، بلڈرز خصوصی پارٹیاں ہیں جو وسائل سے بھرپور بلاک-بلڈنگ میں سرمایہ کاری کرتے ہیں اور MEV + ترجیحی ٹپس سے حاصل ہونے والی آمدنی کو زیادہ سے زیادہ کرنے کے لیے مختلف حکمت عملیوں کا استعمال کرتے ہیں۔ + +2. ایک تصدیق کنندہ (ایک کنسنسس لیئر کلائنٹ چلا رہا ہے) بلڈرز کے نیٹ ورک سے بولیوں کے ساتھ ایگزیکیوشن پے لوڈز کی درخواست کرتا ہے۔ بلڈرز کی بولیوں میں ایگزیکیوشن پے لوڈ ہیڈر — پے لوڈ کے مواد کے لیے ایک کرپٹوگرافک کمٹمنٹ — اور تصدیق کنندہ کو ادا کی جانے والی فیس شامل ہوگی۔ + +3. تصدیق کنندہ آنے والی بولیوں کا جائزہ لیتا ہے اور سب سے زیادہ فیس والے ایگزیکیوشن پے لوڈ کا انتخاب کرتا ہے۔ بلڈر API کا استعمال کرتے ہوئے، تصدیق کنندہ ایک \"بلائنڈڈ\" بیکن بلاک پروپوزل بناتا ہے جس میں صرف ان کے دستخط اور ایگزیکیوشن پے لوڈ ہیڈر شامل ہوتے ہیں اور اسے بلڈر کو بھیجتا ہے۔ + +4. بلڈر API چلانے والے بلڈر سے توقع کی جاتی ہے کہ وہ بلائنڈڈ بلاک پروپوزل دیکھنے پر مکمل ایگزیکیوشن پے لوڈ کے ساتھ جواب دے گا۔ یہ تصدیق کنندہ کو ایک \"دستخط شدہ\" بیکن بلاک بنانے کی اجازت دیتا ہے، جسے وہ پورے نیٹ ورک میں پھیلاتے ہیں۔ + +5. بلڈر API کا استعمال کرنے والے ایک تصدیق کنندہ سے اب بھی توقع کی جاتی ہے کہ اگر بلاک بلڈر فوری طور پر جواب دینے میں ناکام رہتا ہے تو وہ مقامی طور پر ایک بلاک بنائے گا، تاکہ وہ بلاک پروپوزل انعامات سے محروم نہ ہوں۔ تاہم، تصدیق کنندہ اب ظاہر کردہ ٹرانزیکشنز یا کسی دوسرے سیٹ کا استعمال کرتے ہوئے ایک اور بلاک نہیں بنا سکتا، کیونکہ یہ _ equivocation_ (ایک ہی سلاٹ میں دو بلاکس پر دستخط کرنا) کے مترادف ہوگا، جو ایک سلیش ایبل جرم ہے۔ + +بلڈر API کا ایک مثال نفاذ [MEV بوسٹ](https://github.com/flashbots/mev-boost) ہے، جو [فلیش بوٹس نیلامی میکانزم](https://docs.flashbots.net/Flashbots-auction/overview) پر ایک بہتری ہے جو Ethereum پر MEV کے منفی بیرونی عوامل کو روکنے کے لیے ڈیزائن کیا گیا ہے۔ Flashbots نیلامی پروف-آف-اسٹیک میں تصدیق کنندگان کو منافع بخش بلاکس بنانے کا کام **سرچرز** نامی خصوصی پارٹیوں کو آؤٹ سورس کرنے کی اجازت دیتی ہے۔ +![ایک ڈایاگرام جو تفصیل سے MEV کے بہاؤ کو دکھاتا ہے](./mev.png) + +سرچرز منافع بخش MEV مواقع کی تلاش کرتے ہیں اور بلاک میں شمولیت کے لیے [سیلڈ-پرائس بولی](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) کے ساتھ بلاک پروپوزرز کو ٹرانزیکشن بنڈل بھیجتے ہیں۔ mev-geth چلانے والے تصدیق کنندہ، جو go-ethereum (Geth) کلائنٹ کا ایک فورکڈ ورژن ہے، کو صرف سب سے زیادہ منافع والے بنڈل کا انتخاب کرنا ہوتا ہے اور اسے نئے بلاک کے حصے کے طور پر شامل کرنا ہوتا ہے۔ بلاک پروپوزرز (تصدیق کنندگان) کو سپیم اور غلط ٹرانزیکشنز سے بچانے کے لیے، ٹرانزیکشن بنڈل پروپوزر تک پہنچنے سے پہلے توثیق کے لیے **ریلیئرز** سے گزرتے ہیں۔ + +MEV بوسٹ اصل فلیش بوٹس نیلامی کے وہی کام کو برقرار رکھتا ہے، اگرچہ نئی خصوصیات کے ساتھ جو Ethereum کے پروف-آف-اسٹیک میں سوئچ کے لیے ڈیزائن کی گئی ہیں۔ سرچرز اب بھی بلاکس میں شمولیت کے لیے منافع بخش MEV ٹرانزیکشنز تلاش کرتے ہیں، لیکن خصوصی پارٹیوں کی ایک نئی کلاس، جسے **بلڈرز** کہا جاتا ہے، ٹرانزیکشنز اور بنڈلز کو بلاکس میں جمع کرنے کے ذمہ دار ہیں۔ ایک بلڈر سرچرز سے سیلڈ-پرائس بولیاں قبول کرتا ہے اور سب سے زیادہ منافع بخش ترتیب تلاش کرنے کے لیے اصلاحات چلاتا ہے۔ + +ریلیئر اب بھی ٹرانزیکشن بنڈلز کو پروپوزر کو بھیجنے سے پہلے ان کی توثیق کرنے کا ذمہ دار ہے۔ تاہم، MEV بوسٹ **ایسکروز** متعارف کراتا ہے جو بلڈرز کے ذریعے بھیجے گئے بلاک باڈیز اور تصدیق کنندگان کے ذریعے بھیجے گئے بلاک ہیڈرز کو ذخیرہ کرکے [ڈیٹا کی دستیابی](/developers/docs/data-availability/) فراہم کرنے کے ذمہ دار ہیں۔ یہاں، ایک ریلے سے منسلک ایک تصدیق کنندہ دستیاب ایگزیکیوشن پے لوڈز کا مطالبہ کرتا ہے اور سب سے زیادہ بولی + MEV ٹپس کے ساتھ پے لوڈ ہیڈر کو منتخب کرنے کے لیے MEV بوسٹ کے ترتیب دینے والے الگورتھم کا استعمال کرتا ہے۔ + +#### بلڈر API MEV کے اثرات کو کیسے کم کرتا ہے؟ {#how-does-builder-api-curb-mev-impact} + +بلڈر API کا بنیادی فائدہ MEV مواقع تک رسائی کو جمہوری بنانے کی اس کی صلاحیت ہے۔ کمٹ-ریویل اسکیموں کا استعمال اعتماد کے مفروضوں کو ختم کرتا ہے اور MEV سے فائدہ اٹھانے کے خواہاں تصدیق کنندگان کے لیے داخلے کی رکاوٹوں کو کم کرتا ہے۔ اس سے سولو اسٹیکرز پر MEV منافع کو بڑھانے کے لیے بڑے اسٹیکنگ پولز کے ساتھ ضم ہونے کا دباؤ کم ہونا چاہیے۔ + +بلڈر API کے وسیع پیمانے پر نفاذ سے بلاک بلڈرز کے درمیان زیادہ مقابلے کی حوصلہ افزائی ہوگی، جس سے سنسرشپ مزاحمت میں اضافہ ہوگا۔ چونکہ تصدیق کنندگان متعدد بلڈرز کی بولیوں کا جائزہ لیتے ہیں، ایک یا زیادہ صارف ٹرانزیکشنز کو سنسر کرنے کا ارادہ رکھنے والے بلڈر کو کامیاب ہونے کے لیے دیگر تمام غیر سنسر کرنے والے بلڈرز سے زیادہ بولی لگانی ہوگی۔ یہ صارفین کو سنسر کرنے کی لاگت میں ڈرامائی طور پر اضافہ کرتا ہے اور اس عمل کی حوصلہ شکنی کرتا ہے۔ + +کچھ پروجیکٹس، جیسے MEV بوسٹ، بلڈر API کو ایک مجموعی ڈھانچے کے حصے کے طور پر استعمال کرتے ہیں جو کچھ پارٹیوں کو ٹرانزیکشن کی رازداری فراہم کرنے کے لیے ڈیزائن کیا گیا ہے، جیسے کہ فرنٹ رننگ/سینڈوچنگ حملوں سے بچنے کی کوشش کرنے والے تاجر۔ یہ صارفین اور بلاک بلڈرز کے درمیان ایک نجی مواصلاتی چینل فراہم کرکے حاصل کیا جاتا ہے۔ پہلے بیان کردہ اجازت یافتہ میم پولز کے برعکس، یہ نقطہ نظر درج ذیل وجوہات کی بنا پر فائدہ مند ہے: + +1. مارکیٹ میں متعدد بلڈرز کی موجودگی سنسرنگ کو ناقابل عمل بناتی ہے، جس سے صارفین کو فائدہ ہوتا ہے۔ اس کے برعکس، مرکزی اور اعتماد پر مبنی ڈارک پولز کی موجودگی چند بلاک بلڈرز کے ہاتھوں میں طاقت کو مرکوز کرے گی اور سنسرنگ کے امکان کو بڑھا دے گی۔ + +2. بلڈر API سافٹ ویئر اوپن سورس ہے، جو کسی کو بھی بلاک-بلڈر خدمات پیش کرنے کی اجازت دیتا ہے۔ اس کا مطلب ہے کہ صارفین کو کسی خاص بلاک بلڈر کا استعمال کرنے پر مجبور نہیں کیا جاتا اور یہ Ethereum کی غیر جانبداری اور اجازت کے بغیر ہونے کو بہتر بناتا ہے۔ مزید یہ کہ، MEV کے خواہاں تاجر نجی ٹرانزیکشن چینلز کا استعمال کرکے نادانستہ طور پر مرکزیت میں حصہ نہیں ڈالیں گے۔ + +## متعلقہ وسائل {#related-resources} + +- [فلیش بوٹس دستاویزات](https://docs.flashbots.net/) +- [فلیش بوٹس گٹ ہب](https://github.com/flashbots/pm) +- [mevboost.org](https://www.mevboost.org/) - _MEV-بوسٹ ریلے اور بلاک بلڈرز کے لیے حقیقی وقت کے اعدادوشمار کے ساتھ ٹریکر_ + +## مزید پڑھیں {#further-reading} + +- [مائنر-ایکسٹریکٹ ایبل ویلیو (MEV) کیا ہے؟](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [MEV اور میں](https://www.paradigm.xyz/2021/02/mev-and-me) +- [Ethereum ایک تاریک جنگل ہے](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [تاریک جنگل سے فرار](https://samczsun.com/escaping-the-dark-forest/) +- [فلیش بوٹس: MEV بحران کو فرنٹ رننگ کرنا](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [@bertcmiller's MEV تھریڈز](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-بوسٹ: مرج کے لیے تیار فلیش بوٹس آرکیٹیکچر](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [MEV بوسٹ کیا ہے](https://www.alchemy.com/overviews/mev-boost) +- [mev-boost کیوں چلائیں؟](https://writings.flashbots.net/writings/why-run-mevboost/) +- [ایتھیریم کے لیے ہچ ہائیکر کا گائیڈ](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/ur/developers/docs/networking-layer/index.md b/public/content/translations/ur/developers/docs/networking-layer/index.md new file mode 100644 index 00000000000..13ca35e5efe --- /dev/null +++ b/public/content/translations/ur/developers/docs/networking-layer/index.md @@ -0,0 +1,163 @@ +--- +title: "نیٹ ورکنگ پرت" +description: "Ethereum کی نیٹ ورکنگ پرت کا تعارف۔" +lang: ur-in +sidebarDepth: 2 +--- + +Ethereum ایک پیئر-ٹو-پیئر نیٹ ورک ہے جس میں ہزاروں نوڈز ہیں جنہیں معیاری پروٹوکولز کا استعمال کرتے ہوئے ایک دوسرے کے ساتھ بات چیت کرنے کے قابل ہونا چاہیے۔ "نیٹ ورکنگ پرت" پروٹوکولز کا ایک اسٹیک ہے جو ان نوڈز کو ایک دوسرے کو تلاش کرنے اور معلومات کا تبادلہ کرنے کی اجازت دیتا ہے۔ اس میں نیٹ ورک پر معلومات کی "گوسپنگ" (ایک سے کئی تک مواصلات) کے ساتھ ساتھ مخصوص نوڈز کے درمیان درخواستوں اور جوابات کا تبادلہ (ایک سے ایک مواصلات) شامل ہے۔ ہر نوڈ کو مخصوص نیٹ ورکنگ قوانین پر عمل کرنا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ وہ صحیح معلومات بھیج اور وصول کر رہے ہیں۔ + +کلائنٹ سافٹ ویئر کے دو حصے ہیں (ایگزیکیوشن کلائنٹس اور کنسینسس کلائنٹس)، ہر ایک کا اپنا الگ نیٹ ورکنگ اسٹیک ہے۔ دیگر Ethereum نوڈز کے ساتھ مواصلات کرنے کے ساتھ ساتھ، ایگزیکیوشن اور کنسینسس کلائنٹس کو ایک دوسرے کے ساتھ بھی مواصلات کرنا ہوتا ہے۔ یہ صفحہ ان پروٹوکولز کی تعارفی وضاحت فراہم کرتا ہے جو اس مواصلات کو ممکن بناتے ہیں۔ + +ایگزیکیوشن کلائنٹس ایگزیکیوشن-لیئر پیئر-ٹو-پیئر نیٹ ورک پر ٹرانزیکشنز کی گوسپنگ کرتے ہیں۔ اس کے لیے تصدیق شدہ پیئرز کے درمیان انکرپٹڈ مواصلات کی ضرورت ہوتی ہے۔ جب کسی بلاک کی تجویز کے لیے کسی ویلیڈیٹر کا انتخاب کیا جاتا ہے، تو نوڈ کے مقامی ٹرانزیکشن پول سے ٹرانزیکشنز کو ایک مقامی RPC کنکشن کے ذریعے کنسینسس کلائنٹس کو بھیجا جائے گا، جنہیں بیکن بلاکس میں پیکج کیا جائے گا۔ کنسینسس کلائنٹس پھر اپنے p2p نیٹ ورک پر بیکن بلاکس کی گوسپنگ کریں گے۔ اس کے لیے دو الگ الگ p2p نیٹ ورکس کی ضرورت ہوتی ہے: ایک ٹرانزیکشن گوسپ کے لیے ایگزیکیوشن کلائنٹس کو جوڑتا ہے اور دوسرا بلاک گوسپ کے لیے کنسینسس کلائنٹس کو جوڑتا ہے۔ + +## شرائط {#prerequisites} + +اس صفحے کو سمجھنے کے لیے Ethereum [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) کا کچھ علم مددگار ثابت ہوگا۔ + +## ایگزیکیوشن پرت {#execution-layer} + +ایگزیکیوشن پرت کے نیٹ ورکنگ پروٹوکولز کو دو اسٹیکس میں تقسیم کیا گیا ہے: + +- ڈسکوری اسٹیک: UDP کے اوپر بنایا گیا ہے اور ایک نئے نوڈ کو جڑنے کے لیے پیئرز تلاش کرنے کی اجازت دیتا ہے + +- DevP2P اسٹیک: TCP کے اوپر بیٹھتا ہے اور نوڈز کو معلومات کا تبادلہ کرنے کے قابل بناتا ہے + +دونوں اسٹیکس متوازی طور پر کام کرتے ہیں۔ ڈسکوری اسٹیک نئے نیٹ ورک شرکاء کو نیٹ ورک میں فیڈ کرتا ہے، اور DevP2P اسٹیک ان کے تعاملات کو قابل بناتا ہے۔ + +### ڈسکوری {#discovery} + +ڈسکوری نیٹ ورک میں دیگر نوڈز کو تلاش کرنے کا عمل ہے۔ اسے بوٹ نوڈز کے ایک چھوٹے سیٹ کا استعمال کرتے ہوئے بوٹسٹریپ کیا جاتا ہے (وہ نوڈز جن کے پتے کلائنٹ میں [ہارڈ کوڈڈ](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) ہوتے ہیں تاکہ انہیں فوری طور پر پایا جا سکے اور کلائنٹ کو پیئرز سے جوڑا جا سکے)۔ یہ بوٹ نوڈز صرف ایک نئے نوڈ کو پیئرز کے ایک سیٹ سے متعارف کرانے کے لیے موجود ہیں - یہی ان کا واحد مقصد ہے، وہ عام کلائنٹ کے کاموں جیسے کہ چین کو مطابقت پذیر بنانے میں حصہ نہیں لیتے ہیں، اور وہ صرف پہلی بار استعمال ہوتے ہیں جب کسی کلائنٹ کو شروع کیا جاتا ہے۔ + +نوڈ-بوٹ نوڈ تعاملات کے لیے استعمال ہونے والا پروٹوکول [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) کی ایک ترمیم شدہ شکل ہے جو نوڈز کی فہرستیں شیئر کرنے کے لیے ایک [تقسیم شدہ ہیش ٹیبل](https://en.wikipedia.org/wiki/Distributed_hash_table) کا استعمال کرتا ہے۔ ہر نوڈ کے پاس اس ٹیبل کا ایک ورژن ہوتا ہے جس میں اس کے قریب ترین پیئرز سے جڑنے کے لیے درکار معلومات ہوتی ہیں۔ یہ 'قربت' جغرافیائی نہیں ہے - فاصلے کی تعریف نوڈ کی ID کی مماثلت سے ہوتی ہے۔ ہر نوڈ کی ٹیبل کو سیکیورٹی فیچر کے طور پر باقاعدگی سے تازہ کیا جاتا ہے۔ مثال کے طور پر، [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) میں، ڈسکوری پروٹوکول نوڈز 'اشتہارات' بھیجنے کے قابل ہوتے ہیں جو ان سب پروٹوکولز کو دکھاتے ہیں جنہیں کلائنٹ سپورٹ کرتا ہے، جس سے پیئرز کو ان پروٹوکولز کے بارے میں گفت و شنید کرنے کی اجازت ملتی ہے جنہیں وہ دونوں مواصلات کے لیے استعمال کر سکتے ہیں۔ + +ڈسکوری PING-PONG کے کھیل سے شروع ہوتی ہے۔ ایک کامیاب PING-PONG نئے نوڈ کو بوٹ نوڈ سے "بونڈ" کرتا ہے۔ ابتدائی پیغام جو ایک بوٹ نوڈ کو نیٹ ورک میں داخل ہونے والے نئے نوڈ کی موجودگی سے آگاہ کرتا ہے وہ ایک `PING` ہے۔ اس `PING` میں نئے نوڈ، بوٹ نوڈ اور ایک ایکسپائری ٹائم اسٹیمپ کے بارے میں ہیش شدہ معلومات شامل ہوتی ہیں۔ بوٹ نوڈ `PING` وصول کرتا ہے اور ایک `PONG` واپس کرتا ہے جس میں `PING` ہیش ہوتا ہے۔ اگر `PING` اور `PONG` ہیشز مماثل ہوں تو نئے نوڈ اور بوٹ نوڈ کے درمیان کنکشن کی تصدیق ہو جاتی ہے اور کہا جاتا ہے کہ وہ "بونڈڈ" ہو گئے ہیں۔ + +ایک بار بونڈڈ ہونے کے بعد، نیا نوڈ بوٹ نوڈ کو ایک `FIND-NEIGHBOURS` درخواست بھیج سکتا ہے۔ بوٹ نوڈ کے ذریعے واپس کیا گیا ڈیٹا ان پیئرز کی ایک فہرست پر مشتمل ہوتا ہے جن سے نیا نوڈ جڑ سکتا ہے۔ اگر نوڈز بونڈڈ نہیں ہیں، تو `FIND-NEIGHBOURS` کی درخواست ناکام ہو جائے گی، لہذا نیا نوڈ نیٹ ورک میں داخل نہیں ہو سکے گا۔ + +ایک بار جب نیا نوڈ بوٹ نوڈ سے پڑوسیوں کی فہرست وصول کر لیتا ہے، تو وہ ان میں سے ہر ایک کے ساتھ PING-PONG کا تبادلہ شروع کر دیتا ہے۔ کامیاب PING-PONGs نئے نوڈ کو اس کے پڑوسیوں کے ساتھ بونڈ کرتے ہیں، جس سے پیغام کا تبادلہ ممکن ہوتا ہے۔ + +``` +کلائنٹ شروع کریں --> بوٹ نوڈ سے جڑیں --> بوٹ نوڈ سے بونڈ کریں --> پڑوسی تلاش کریں --> پڑوسیوں سے بونڈ کریں +``` + +ایگزیکیوشن کلائنٹس فی الحال [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) ڈسکوری پروٹوکول استعمال کر رہے ہیں اور [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) پروٹوکول پر منتقل ہونے کی ایک فعال کوشش جاری ہے۔ + +#### ENR: Ethereum نوڈ ریکارڈز {#enr} + +[Ethereum نوڈ ریکارڈ (ENR)](/developers/docs/networking-layer/network-addresses/) ایک آبجیکٹ ہے جس میں تین بنیادی عناصر ہوتے ہیں: ایک دستخط (کسی متفقہ شناختی اسکیم کے مطابق بنائے گئے ریکارڈ کے مواد کا ہیش)، ایک ترتیب نمبر جو ریکارڈ میں تبدیلیوں کو ٹریک کرتا ہے، اور کلیدی: قدر کے جوڑوں کی ایک من مانی فہرست۔ یہ ایک مستقبل کا ثبوت فارمیٹ ہے جو نئے پیئرز کے درمیان شناختی معلومات کے آسان تبادلے کی اجازت دیتا ہے اور Ethereum نوڈز کے لیے ترجیحی [نیٹ ورک ایڈریس](/developers/docs/networking-layer/network-addresses) فارمیٹ ہے۔ + +#### ڈسکوری UDP پر کیوں بنائی گئی ہے؟ {#why-udp} + +UDP کسی بھی خرابی کی جانچ، ناکام پیکٹوں کو دوبارہ بھیجنے، یا متحرک طور پر کنکشن کھولنے اور بند کرنے کی حمایت نہیں کرتا ہے - اس کے بجائے یہ صرف ایک ہدف پر معلومات کا ایک مسلسل سلسلہ فائر کرتا ہے، چاہے وہ کامیابی سے موصول ہو یا نہ ہو۔ یہ کم سے کم فعالیت بھی کم سے کم اوور ہیڈ میں ترجمہ کرتی ہے، جس سے اس قسم کا کنکشن بہت تیز ہو جاتا ہے۔ ڈسکوری کے لیے، جہاں ایک نوڈ صرف اپنی موجودگی کو ظاہر کرنا چاہتا ہے تاکہ پھر ایک پیئر کے ساتھ رسمی کنکشن قائم کیا جا سکے، UDP کافی ہے۔ تاہم، باقی نیٹ ورکنگ اسٹیک کے لیے، UDP مقصد کے لیے موزوں نہیں ہے۔ نوڈز کے درمیان معلوماتی تبادلہ کافی پیچیدہ ہے اور اس لیے اسے ایک زیادہ مکمل خصوصیات والے پروٹوکول کی ضرورت ہے جو دوبارہ بھیجنے، خرابی کی جانچ وغیرہ کی حمایت کر سکے۔ TCP سے وابستہ اضافی اوور ہیڈ اضافی فعالیت کے قابل ہے۔ لہذا، P2P اسٹیک کی اکثریت TCP پر کام کرتی ہے۔ + +### DevP2P {#devp2p} + +DevP2P خود پروٹوکولز کا ایک پورا اسٹیک ہے جسے Ethereum پیئر-ٹو-پیئر نیٹ ورک کو قائم کرنے اور برقرار رکھنے کے لیے نافذ کرتا ہے۔ نئے نوڈز کے نیٹ ورک میں داخل ہونے کے بعد، ان کے تعاملات [DevP2P](https://github.com/ethereum/devp2p) اسٹیک میں پروٹوکولز کے ذریعے چلائے جاتے ہیں۔ یہ سب TCP کے اوپر بیٹھتے ہیں اور ان میں RLPx ٹرانسپورٹ پروٹوکول، وائر پروٹوکول اور کئی سب پروٹوکول شامل ہیں۔ [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) نوڈز کے درمیان سیشنز کو شروع کرنے، تصدیق کرنے اور برقرار رکھنے کا پروٹوکول ہے۔ RLPx RLP (ریکرسیو لینتھ پریفکس) کا استعمال کرتے ہوئے پیغامات کو انکوڈ کرتا ہے جو نوڈز کے درمیان بھیجنے کے لیے ڈیٹا کو کم سے کم ڈھانچے میں انکوڈ کرنے کا ایک بہت ہی جگہ-موثر طریقہ ہے۔ + +دو نوڈز کے درمیان ایک RLPx سیشن ایک ابتدائی کرپٹوگرافک ہینڈ شیک سے شروع ہوتا ہے۔ اس میں نوڈ ایک تصدیقی پیغام بھیجتا ہے جسے پھر پیئر کے ذریعے تصدیق کیا جاتا ہے۔ کامیاب تصدیق پر، پیئر ایک تصدیقی-اعترافی پیغام تیار کرتا ہے تاکہ اسے شروع کرنے والے نوڈ کو واپس کیا جا سکے۔ یہ ایک کلیدی-تبادلہ کا عمل ہے جو نوڈز کو نجی اور محفوظ طریقے سے مواصلات کرنے کے قابل بناتا ہے۔ ایک کامیاب کرپٹوگرافک ہینڈ شیک پھر دونوں نوڈز کو ایک دوسرے کو "تار پر" ایک "ہیلو" پیغام بھیجنے کے لیے متحرک کرتا ہے۔ وائر پروٹوکول ہیلو پیغامات کے کامیاب تبادلے سے شروع ہوتا ہے۔ + +ہیلو پیغامات میں شامل ہیں: + +- پروٹوکول ورژن +- کلائنٹ ID +- پورٹ +- نوڈ ID +- حمایت یافتہ سب-پروٹوکولز کی فہرست + +یہ ایک کامیاب تعامل کے لیے درکار معلومات ہے کیونکہ یہ اس بات کی وضاحت کرتی ہے کہ دونوں نوڈز کے درمیان کون سی صلاحیتیں مشترک ہیں اور مواصلات کو ترتیب دیتی ہیں۔ سب-پروٹوکول مذاکرات کا ایک عمل ہے جہاں ہر نوڈ کے ذریعے حمایت یافتہ سب-پروٹوکولز کی فہرستوں کا موازنہ کیا جاتا ہے اور جو دونوں نوڈز کے لیے مشترک ہیں وہ سیشن میں استعمال کی جا سکتی ہیں۔ + +ہیلو پیغامات کے ساتھ، وائر پروٹوکول ایک "ڈس کنیکٹ" پیغام بھی بھیج سکتا ہے جو ایک پیئر کو انتباہ دیتا ہے کہ کنکشن بند کر دیا جائے گا۔ وائر پروٹوکول میں PING اور PONG پیغامات بھی شامل ہیں جو سیشن کو کھلا رکھنے کے لیے وقتاً فوقتاً بھیجے جاتے ہیں۔ RLPx اور وائر پروٹوکول تبادلے اس لیے نوڈز کے درمیان مواصلات کی بنیادیں قائم کرتے ہیں، جو ایک مخصوص سب-پروٹوکول کے مطابق مفید معلومات کے تبادلے کے لیے اسکافولڈنگ فراہم کرتے ہیں۔ + +### سب-پروٹوکولز {#sub-protocols} + +#### وائر پروٹوکول {#wire-protocol} + +ایک بار جب پیئرز جڑ جاتے ہیں، اور ایک RLPx سیشن شروع ہو جاتا ہے، تو وائر پروٹوکول یہ بتاتا ہے کہ پیئرز کیسے مواصلات کرتے ہیں۔ ابتدائی طور پر، وائر پروٹوکول نے تین اہم کاموں کی تعریف کی: چین کی ہم آہنگی، بلاک کی تشہیر اور ٹرانزیکشن کا تبادلہ۔ تاہم، ایک بار جب Ethereum پروف-آف-اسٹیک پر منتقل ہو گیا، تو بلاک کی تشہیر اور چین کی ہم آہنگی کنسینسس پرت کا حصہ بن گئیں۔ ٹرانزیکشن کا تبادلہ اب بھی ایگزیکیوشن کلائنٹس کے دائرہ کار میں ہے۔ ٹرانزیکشن کا تبادلہ نوڈز کے درمیان زیر التواء ٹرانزیکشنز کے تبادلے سے مراد ہے تاکہ بلاک بنانے والے ان میں سے کچھ کو اگلے بلاک میں شامل کرنے کے لیے منتخب کر سکیں۔ ان کاموں کے بارے میں تفصیلی معلومات [یہاں](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) دستیاب ہیں۔ وہ کلائنٹس جو ان سب-پروٹوکولز کو سپورٹ کرتے ہیں وہ انہیں [JSON-RPC](/developers/docs/apis/json-rpc/) کے ذریعے ظاہر کرتے ہیں۔ + +#### les (لائٹ Ethereum سب پروٹوکول) {#les} + +یہ لائٹ کلائنٹس کو مطابقت پذیر بنانے کے لیے ایک کم سے کم پروٹوکول ہے۔ روایتی طور پر یہ پروٹوکول شاذ و نادر ہی استعمال کیا جاتا ہے کیونکہ مکمل نوڈز کو بغیر کسی ترغیب کے لائٹ کلائنٹس کو ڈیٹا فراہم کرنے کی ضرورت ہوتی ہے۔ ایگزیکیوشن کلائنٹس کا پہلے سے طے شدہ رویہ les پر لائٹ کلائنٹ ڈیٹا فراہم کرنا نہیں ہے۔ مزید معلومات les [spec](https://github.com/ethereum/devp2p/blob/master/caps/les.md) میں دستیاب ہے۔ + +#### Snap {#snap} + +[اسنیپ پروٹوکول](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) ایک اختیاری توسیع ہے جو پیئرز کو حالیہ ریاستوں کے اسنیپ شاٹس کا تبادلہ کرنے کی اجازت دیتی ہے، جس سے پیئرز کو درمیانی Merkle ٹرائی نوڈز کو ڈاؤن لوڈ کیے بغیر اکاؤنٹ اور اسٹوریج ڈیٹا کی تصدیق کرنے کی اجازت ملتی ہے۔ + +#### Wit (وٹنس پروٹوکول) {#wit} + +[وٹنس پروٹوکول](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) ایک اختیاری توسیع ہے جو پیئرز کے درمیان اسٹیٹ وٹنسز کے تبادلے کو قابل بناتی ہے، جس سے کلائنٹس کو چین کے سرے تک مطابقت پذیر بنانے میں مدد ملتی ہے۔ + +#### Whisper {#whisper} + +Whisper ایک پروٹوکول تھا جس کا مقصد بلاک چین پر کوئی معلومات لکھے بغیر پیئرز کے درمیان محفوظ پیغام رسانی فراہم کرنا تھا۔ یہ DevP2P وائر پروٹوکول کا حصہ تھا لیکن اب اسے فرسودہ کر دیا گیا ہے۔ اسی طرح کے مقاصد کے ساتھ دیگر [متعلقہ منصوبے](https://wakunetwork.com/) موجود ہیں۔ + +## کنسینسس پرت {#consensus-layer} + +کنسینسس کلائنٹس ایک مختلف تفصیلات کے ساتھ ایک علیحدہ پیئر-ٹو-پیئر نیٹ ورک میں حصہ لیتے ہیں۔ کنسینسس کلائنٹس کو بلاک گوسپ میں حصہ لینے کی ضرورت ہوتی ہے تاکہ وہ پیئرز سے نئے بلاکس وصول کر سکیں اور جب ان کی باری ہو تو انہیں بلاک پروپوزر کے طور پر براڈکاسٹ کر سکیں۔ ایگزیکیوشن پرت کی طرح، اس کے لیے پہلے ایک ڈسکوری پروٹوکول کی ضرورت ہوتی ہے تاکہ ایک نوڈ پیئرز تلاش کر سکے اور بلاکس، اٹیسٹیشنز وغیرہ کے تبادلے کے لیے محفوظ سیشنز قائم کر سکے۔ + +### ڈسکوری {#consensus-discovery} + +ایگزیکیوشن کلائنٹس کی طرح، کنسینسس کلائنٹس پیئرز کو تلاش کرنے کے لیے UDP پر [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) کا استعمال کرتے ہیں۔ discv5 کا کنسینسس پرت کا نفاذ ایگزیکیوشن کلائنٹس سے صرف اس لحاظ سے مختلف ہے کہ اس میں ایک اڈاپٹر شامل ہے جو discv5 کو [libP2P](https://libp2p.io/) اسٹیک سے جوڑتا ہے، جس سے DevP2P فرسودہ ہو جاتا ہے۔ ایگزیکیوشن پرت کے RLPx سیشنز کو libP2P کے نائز سیکیور چینل ہینڈ شیک کے حق میں فرسودہ کر دیا گیا ہے۔ + +### ENRs {#consensus-enr} + +کنسینسس نوڈز کے لیے ENR میں نوڈ کی پبلک کی، IP ایڈریس، UDP اور TCP پورٹس اور دو کنسینسس-مخصوص فیلڈز شامل ہیں: اٹیسٹیشن سب نیٹ بٹ فیلڈ اور `eth2` کلید۔ سابقہ نوڈز کے لیے مخصوص اٹیسٹیشن گوسپ سب-نیٹ ورکس میں حصہ لینے والے پیئرز کو تلاش کرنا آسان بناتا ہے۔ `eth2` کلید میں اس بارے میں معلومات ہوتی ہیں کہ نوڈ کون سا Ethereum فورک ورژن استعمال کر رہا ہے، جس سے یہ یقینی ہوتا ہے کہ پیئرز صحیح Ethereum سے جڑ رہے ہیں۔ + +### libP2P {#libp2p} + +libP2P اسٹیک ڈسکوری کے بعد تمام مواصلات کی حمایت کرتا ہے۔ کلائنٹس اپنے ENR میں بیان کردہ کے مطابق IPv4 اور/یا IPv6 پر ڈائل اور سن سکتے ہیں۔ libP2P پرت پر موجود پروٹوکولز کو گوسپ اور req/resp ڈومینز میں تقسیم کیا جا سکتا ہے۔ + +### گوسپ {#gossip} + +گوسپ ڈومین میں وہ تمام معلومات شامل ہیں جنہیں پورے نیٹ ورک میں تیزی سے پھیلانا ہوتا ہے۔ اس میں بیکن بلاکس، ثبوت، اٹیسٹیشنز، ایگزٹس اور سلیشنگز شامل ہیں۔ یہ libP2P gossipsub v1 کا استعمال کرتے ہوئے منتقل کیا جاتا ہے اور ہر نوڈ پر مقامی طور پر ذخیرہ شدہ مختلف میٹا ڈیٹا پر انحصار کرتا ہے، بشمول وصول کرنے اور منتقل کرنے کے لیے گوسپ پے لوڈز کا زیادہ سے زیادہ سائز۔ گوسپ ڈومین کے بارے میں تفصیلی معلومات [یہاں](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub) دستیاب ہیں۔ + +### درخواست-جواب {#request-response} + +درخواست-جواب ڈومین میں کلائنٹس کے لیے ان کے پیئرز سے مخصوص معلومات کی درخواست کرنے کے لیے پروٹوکولز شامل ہیں۔ مثالوں میں مخصوص بیکن بلاکس کی درخواست کرنا شامل ہے جو کچھ روٹ ہیشز سے مماثل ہوں یا سلاٹس کی ایک رینج کے اندر ہوں۔ جوابات ہمیشہ اسنیپی-کمپریسڈ SSZ انکوڈڈ بائٹس کے طور پر واپس کیے جاتے ہیں۔ + +## کنسینسس کلائنٹ RLP کے بجائے SSZ کو کیوں ترجیح دیتا ہے؟ {#ssz-vs-rlp} + +SSZ کا مطلب ہے سادہ سیریلائزیشن۔ یہ فکسڈ آفسیٹس کا استعمال کرتا ہے جو پورے ڈھانچے کو ڈی کوڈ کیے بغیر انکوڈڈ پیغام کے انفرادی حصوں کو ڈی کوڈ کرنا آسان بناتا ہے، جو کنسینسس کلائنٹ کے لیے بہت مفید ہے کیونکہ یہ انکوڈڈ پیغامات سے معلومات کے مخصوص ٹکڑوں کو مؤثر طریقے سے حاصل کر سکتا ہے۔ اسے خاص طور پر Merkle پروٹوکولز کے ساتھ ضم کرنے کے لیے بھی ڈیزائن کیا گیا ہے، جس میں Merkleization کے لیے متعلقہ کارکردگی میں اضافہ ہوتا ہے۔ چونکہ کنسینسس پرت میں تمام ہیشز Merkle روٹس ہیں، اس لیے یہ ایک اہم بہتری کا باعث بنتا ہے۔ SSZ قدروں کی منفرد نمائندگی کی بھی ضمانت دیتا ہے۔ + +## ایگزیکیوشن اور کنسینسس کلائنٹس کو جوڑنا {#connecting-clients} + +دونوں کنسینسس اور ایگزیکیوشن کلائنٹس متوازی طور پر چلتے ہیں۔ انہیں جڑنے کی ضرورت ہے تاکہ کنسینسس کلائنٹ ایگزیکیوشن کلائنٹ کو ہدایات فراہم کر سکے، اور ایگزیکیوشن کلائنٹ ٹرانزیکشنز کے بنڈل کنسینسس کلائنٹ کو بیکن بلاکس میں شامل کرنے کے لیے بھیج سکے۔ دو کلائنٹس کے درمیان مواصلات کو مقامی RPC کنکشن کا استعمال کرتے ہوئے حاصل کیا جا سکتا ہے۔ ایک API جسے ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) کہا جاتا ہے، دو کلائنٹس کے درمیان بھیجی گئی ہدایات کی وضاحت کرتا ہے۔ چونکہ دونوں کلائنٹس ایک ہی نیٹ ورک شناخت کے پیچھے بیٹھتے ہیں، وہ ایک ENR (Ethereum نوڈ ریکارڈ) شیئر کرتے ہیں جس میں ہر کلائنٹ کے لیے ایک الگ کلید ہوتی ہے (eth1 کلید اور eth2 کلید)۔ + +کنٹرول فلو کا خلاصہ ذیل میں دکھایا گیا ہے، جس میں متعلقہ نیٹ ورکنگ اسٹیک بریکٹ میں ہے۔ + +### جب کنسینسس کلائنٹ بلاک پروڈیوسر نہ ہو: {#when-consensus-client-is-not-block-producer} + +- کنسینسس کلائنٹ بلاک گوسپ پروٹوکول (کنسینسس p2p) کے ذریعے ایک بلاک وصول کرتا ہے +- کنسینسس کلائنٹ بلاک کی پہلے سے تصدیق کرتا ہے، یعنی یہ یقینی بناتا ہے کہ یہ درست میٹا ڈیٹا کے ساتھ ایک درست بھیجنے والے سے آیا ہے +- بلاک میں موجود ٹرانزیکشنز کو ایگزیکیوشن پے لوڈ کے طور پر ایگزیکیوشن پرت کو بھیجا جاتا ہے (مقامی RPC کنکشن) +- ایگزیکیوشن پرت ٹرانزیکشنز پر عمل درآمد کرتی ہے اور بلاک ہیڈر میں حالت کی توثیق کرتی ہے (یعنی، ہیشز کے مماثل ہونے کی جانچ کرتی ہے) +- ایگزیکیوشن پرت توثیق کا ڈیٹا واپس کنسینسس پرت کو بھیجتی ہے، بلاک کو اب توثیق شدہ سمجھا جاتا ہے (مقامی RPC کنکشن) +- کنسینسس پرت بلاک کو اپنے بلاک چین کے سرے میں شامل کرتی ہے اور اس کی تصدیق کرتی ہے، نیٹ ورک پر اٹیسٹیشن کو براڈکاسٹ کرتی ہے (کنسینسس p2p) + +### جب کنسینسس کلائنٹ بلاک پروڈیوسر ہو: {#when-consensus-client-is-block-producer} + +- کنسینسس کلائنٹ کو نوٹس ملتا ہے کہ وہ اگلا بلاک پروڈیوسر ہے (کنسینسس p2p) +- کنسینسس پرت ایگزیکیوشن کلائنٹ میں `create block` طریقہ کو کال کرتی ہے (مقامی RPC) +- ایگزیکیوشن پرت ٹرانزیکشن میم پول تک رسائی حاصل کرتی ہے جسے ٹرانزیکشن گوسپ پروٹوکول (ایگزیکیوشن p2p) کے ذریعے آباد کیا گیا ہے +- ایگزیکیوشن کلائنٹ ٹرانزیکشنز کو ایک بلاک میں بنڈل کرتا ہے، ٹرانزیکشنز پر عمل درآمد کرتا ہے اور ایک بلاک ہیش تیار کرتا ہے +- کنسینسس کلائنٹ ایگزیکیوشن کلائنٹ سے ٹرانزیکشنز اور بلاک ہیش حاصل کرتا ہے اور انہیں بیکن بلاک میں شامل کرتا ہے (مقامی RPC) +- کنسینسس کلائنٹ بلاک گوسپ پروٹوکول (کنسینسس p2p) پر بلاک کو براڈکاسٹ کرتا ہے +- دیگر کلائنٹس مجوزہ بلاک کو بلاک گوسپ پروٹوکول کے ذریعے وصول کرتے ہیں اور جیسا کہ اوپر بیان کیا گیا ہے توثیق کرتے ہیں (کنسینسس p2p) + +ایک بار جب بلاک کی کافی ویلیڈیٹرز کے ذریعے تصدیق ہو جاتی ہے تو اسے چین کے سرے میں شامل کیا جاتا ہے، جواز پیش کیا جاتا ہے اور آخر کار حتمی شکل دی جاتی ہے۔ + +![](cons_client_net_layer.png) +![](exe_client_net_layer.png) + +کنسینسس اور ایگزیکیوشن کلائنٹس کے لیے نیٹ ورک پرت کا اسکیمیٹک، [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) سے + +## مزید مطالعہ {#further-reading} + +[DevP2P](https://github.com/ethereum/devp2p) +[LibP2p](https://github.com/libp2p/specs) +[کنسینسس پرت نیٹ ورک کی تفصیلات](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) +[kademlia to discv5](https://vac.dev/kademlia-to-discv5) +[kademlia پیپر](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) +[Ethereum p2p کا تعارف](https://p2p.paris/en/talks/intro-ethereum-networking/) +[eth1/eth2 تعلق](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) +[مرج اور eth2 کلائنٹ کی تفصیلات کی ویڈیو](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/ur/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/ur/developers/docs/networking-layer/network-addresses/index.md new file mode 100644 index 00000000000..f0ea2bf809e --- /dev/null +++ b/public/content/translations/ur/developers/docs/networking-layer/network-addresses/index.md @@ -0,0 +1,39 @@ +--- +title: "نیٹ ورک پتے" +description: "نیٹ ورک پتوں کا تعارف۔" +lang: ur-in +sidebarDepth: 2 +--- + +Ethereum نوڈس کو پیئرز سے جڑنے کے لیے کچھ بنیادی معلومات کے ساتھ خود کی شناخت کرنی ہوتی ہے۔ یہ یقینی بنانے کے لیے کہ کوئی بھی ممکنہ پیئر اس معلومات کی تشریح کر سکے، اسے تین معیاری فارمیٹس میں سے ایک میں ریلے کیا جاتا ہے جسے کوئی بھی Ethereum نوڈ سمجھ سکتا ہے: multiaddr، enode، یا Ethereum Node Records (ENRs)۔ ENRs Ethereum نیٹ ورک پتوں کے لیے موجودہ معیار ہیں۔ + +## شرائط {#prerequisites} + +اس صفحہ کو سمجھنے کے لیے Ethereum کی [نیٹ ورکنگ لیئر](/developers/docs/networking-layer/) کی کچھ سمجھ ضروری ہے۔ + +## Multiaddr {#multiaddr} + +اصل Ethereum نوڈ ایڈریس فارمیٹ 'multiaddr' ('multi-addresses' کا مخفف) تھا۔ Multiaddr ایک یونیورسل فارمیٹ ہے جسے پیئر-ٹو-پیئر نیٹ ورکس کے لیے ڈیزائن کیا گیا ہے۔ پتوں کی نمائندگی کلیدی قدر کے جوڑوں کے طور پر کی جاتی ہے جس میں کلیدوں اور قدروں کو ایک فارورڈ سلیش کے ساتھ الگ کیا جاتا ہے۔ مثال کے طور پر، IPv4 پتے `192.168.22.27` والے نوڈ کا multiaddr جو TCP پورٹ `33000` کو سن رہا ہے، کچھ اس طرح نظر آتا ہے: + +`/ip4/192.168.22.27/tcp/33000` + +ایک Ethereum نوڈ کے لیے، multiaddr میں نوڈ-ID (ان کی پبلک کلید کا ہیش) شامل ہوتا ہے: + +`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` + +## Enode {#enode} + +Enode ایک URL ایڈریس فارمیٹ کا استعمال کرتے ہوئے Ethereum نوڈ کی شناخت کرنے کا ایک طریقہ ہے۔ ہیکسا ڈیسیمل نوڈ-ID کو URL کے یوزر نیم والے حصے میں انکوڈ کیا جاتا ہے، جسے @ نشان کا استعمال کرتے ہوئے ہوسٹ سے الگ کیا جاتا ہے۔ ہوسٹ نام صرف IP پتے کے طور پر دیا جا سکتا ہے؛ DNS ناموں کی اجازت نہیں ہے۔ ہوسٹ نام والے حصے میں پورٹ TCP لسننگ پورٹ ہے۔ اگر TCP اور UDP (ڈسکوری) پورٹس مختلف ہیں، تو UDP پورٹ کو ایک استفساری پیرامیٹر "discport" کے طور پر مخصوص کیا جاتا ہے۔ + +مندرجہ ذیل مثال میں، نوڈ URL ایک ایسے نوڈ کی وضاحت کرتا ہے جس کا IP پتہ `10.3.58.6`، TCP پورٹ `30303` اور UDP ڈسکوری پورٹ `30301` ہے۔ + +`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` + +## Ethereum نوڈ ریکارڈز (ENRs) {#enr} + +Ethereum نوڈ ریکارڈز (ENRs) Ethereum پر نیٹ ورک پتوں کے لیے ایک معیاری فارمیٹ ہیں۔ یہ multiaddr's اور enodes کی جگہ لیتے ہیں۔ یہ خاص طور پر مفید ہیں کیونکہ یہ نوڈس کے درمیان زیادہ معلوماتی تبادلے کی اجازت دیتے ہیں۔ ENR میں ایک دستخط، سلسلہ نمبر اور شناختی اسکیم کی تفصیل دینے والے فیلڈز شامل ہوتے ہیں جو دستخط بنانے اور ان کی توثیق کرنے کے لیے استعمال ہوتی ہے۔ ENR کو من مانے ڈیٹا سے بھی بھرا جا سکتا ہے جسے کلیدی قدر کے جوڑوں کے طور پر منظم کیا گیا ہو۔ ان کلیدی قدر کے جوڑوں میں نوڈ کا IP پتہ اور ان ذیلی پروٹوکولز کے بارے میں معلومات شامل ہوتی ہیں جنہیں نوڈ استعمال کرنے کے قابل ہے۔ اتفاق رائے کلائنٹس بوٹ نوڈس کی شناخت کے لیے ایک [مخصوص ENR ڈھانچے](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) کا استعمال کرتے ہیں اور اس میں ایک `eth2` فیلڈ بھی شامل ہوتا ہے جس میں موجودہ Ethereum فورک اور توثیقی گپ شپ سب نیٹ (یہ نوڈ کو پیئرز کے ایک خاص سیٹ سے جوڑتا ہے جن کی تصدیقیں ایک ساتھ جمع کی جاتی ہیں) کے بارے میں معلومات ہوتی ہیں۔ + +## مزید مطالعہ {#further-reading} + +- [EIP-778: Ethereum نوڈ ریکارڈز (ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/ur/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/ur/developers/docs/networking-layer/portal-network/index.md new file mode 100644 index 00000000000..61c20bc98a2 --- /dev/null +++ b/public/content/translations/ur/developers/docs/networking-layer/portal-network/index.md @@ -0,0 +1,89 @@ +--- +title: "پورٹل نیٹ ورک" +description: "پورٹل نیٹ ورک کا ایک جائزہ - ایک زیر ترقی نیٹ ورک جو کم وسائل والے کلائنٹس کو سپورٹ کرنے کے لیے ڈیزائن کیا گیا ہے۔" +lang: ur-in +--- + +ایتھیریم ایک نیٹ ورک ہے جو ایسے کمپیوٹرز سے بنا ہے جو ایتھیریم کلائنٹ سافٹ ویئر چلاتے ہیں۔ ان میں سے ہر کمپیوٹر کو 'نوڈ' کہا جاتا ہے۔ کلائنٹ سافٹ ویئر ایک نوڈ کو ایتھیریم نیٹ ورک پر ڈیٹا بھیجنے اور وصول کرنے کی اجازت دیتا ہے، اور ایتھیریم پروٹوکول کے اصولوں کے خلاف ڈیٹا کی تصدیق کرتا ہے۔ نوڈز اپنی ڈسک اسٹوریج میں بہت سارا تاریخی ڈیٹا رکھتے ہیں اور جب وہ نیٹ ورک پر دوسرے نوڈز سے معلومات کے نئے پیکٹ، جنہیں بلاکس کہا جاتا ہے، وصول کرتے ہیں تو اس میں اضافہ کرتے ہیں۔ یہ ہمیشہ اس بات کو یقینی بنانے کے لیے ضروری ہے کہ نوڈ کے پاس باقی نیٹ ورک کے ساتھ مطابقت رکھنے والی معلومات موجود ہوں۔ اس کا مطلب ہے کہ ایک نوڈ چلانے کے لیے بہت زیادہ ڈسک اسپیس کی ضرورت پڑ سکتی ہے۔ کچھ نوڈ آپریشنز کے لیے بہت زیادہ RAM کی بھی ضرورت پڑ سکتی ہے۔ + +اس ڈسک اسٹوریج کے مسئلے سے نمٹنے کے لیے، 'لائٹ' نوڈز تیار کیے گئے ہیں جو خود تمام معلومات کو اسٹور کرنے کے بجائے فل نوڈز سے معلومات کی درخواست کرتے ہیں۔ تاہم، اس کا مطلب ہے کہ لائٹ نوڈ آزادانہ طور پر معلومات کی تصدیق نہیں کر رہا ہے اور اس کے بجائے دوسرے نوڈ پر بھروسہ کر رہا ہے۔ اس کا یہ بھی مطلب ہے کہ فل نوڈز کو ان لائٹ نوڈز کی خدمت کے لیے اضافی کام کرنے کی ضرورت ہوتی ہے۔ + +پورٹل نیٹ ورک ایتھیریم کے لیے ایک نیا نیٹ ورکنگ ڈیزائن ہے جس کا مقصد "لائٹ" نوڈز کے لیے ڈیٹا کی دستیابی کے مسئلے کو حل کرنا ہے بغیر فل نوڈز پر بھروسہ کیے یا اضافی دباؤ ڈالے، اور یہ نیٹ ورک میں ضروری ڈیٹا کو چھوٹے چھوٹے ٹکڑوں میں شیئر کرکے کیا جاتا ہے۔ + +[نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) پر مزید + +## ہمیں پورٹل نیٹ ورک کی ضرورت کیوں ہے {#why-do-we-need-portal-network} + +ایتھیریم نوڈز ایتھیریم بلاک چین کی اپنی مکمل یا جزوی کاپی اسٹور کرتے ہیں۔ یہ مقامی کاپی ٹرانزیکشنز کی توثیق کرنے اور یہ یقینی بنانے کے لیے استعمال ہوتی ہے کہ نوڈ صحیح چین کو فالو کر رہا ہے۔ یہ مقامی طور پر ذخیرہ شدہ ڈیٹا نوڈز کو کسی دوسرے ادارے پر بھروسہ کیے بغیر آزادانہ طور پر یہ تصدیق کرنے کی اجازت دیتا ہے کہ آنے والا ڈیٹا درست اور صحیح ہے۔ + +بلاک چین کی یہ مقامی کاپی اور اس سے وابستہ اسٹیٹ اور رسید کا ڈیٹا نوڈ کی ہارڈ ڈسک پر بہت زیادہ جگہ لیتا ہے۔ مثال کے طور پر، [Geth](https://geth.ethereum.org) کا استعمال کرتے ہوئے ایک نوڈ چلانے کے لیے 2TB ہارڈ ڈسک کی سفارش کی جاتی ہے جو ایک کنسینسس کلائنٹ کے ساتھ جوڑا گیا ہو۔ اسنیپ سنک کا استعمال کرتے ہوئے، جو صرف بلاکس کے نسبتاً حالیہ سیٹ سے چین ڈیٹا اسٹور کرتا ہے، Geth عام طور پر تقریباً 650GB ڈسک اسپیس لیتا ہے لیکن تقریباً 14GB/ہفتہ کی شرح سے بڑھتا ہے (آپ وقتاً فوقتاً نوڈ کو چھانٹ کر 650GB تک واپس لا سکتے ہیں)۔ + +اس کا مطلب ہے کہ نوڈز چلانا مہنگا ہو سکتا ہے، کیونکہ ڈسک کی ایک بڑی جگہ ایتھیریم کے لیے وقف کرنی پڑتی ہے۔ ایتھیریم روڈ میپ پر اس مسئلے کے کئی حل ہیں، جن میں [ہسٹری ایکسپائری](/roadmap/statelessness/#history-expiry)، [اسٹیٹ ایکسپائری](/roadmap/statelessness/#state-expiry) اور [اسٹیٹ لیسنیس](/roadmap/statelessness/) شامل ہیں۔ تاہم، ان کو نافذ ہونے میں شاید کئی سال لگ جائیں گے۔ ایسے [لائٹ نوڈز](/developers/docs/nodes-and-clients/light-clients/) بھی ہیں جو چین ڈیٹا کی اپنی کاپی محفوظ نہیں کرتے، وہ فل نوڈز سے اپنی ضرورت کا ڈیٹا طلب کرتے ہیں۔ تاہم، اس کا مطلب یہ ہے کہ لائٹ نوڈز کو ایماندار ڈیٹا فراہم کرنے کے لیے فل نوڈز پر بھروسہ کرنا پڑتا ہے اور یہ ان فل نوڈز پر بھی دباؤ ڈالتا ہے جنہیں لائٹ نوڈز کے لیے ضروری ڈیٹا فراہم کرنا ہوتا ہے۔ + +پورٹل نیٹ ورک کا مقصد لائٹ نوڈز کو اپنا ڈیٹا حاصل کرنے کا ایک متبادل طریقہ فراہم کرنا ہے جس کے لیے فل نوڈز پر بھروسہ کرنے یا ان کے کام میں خاطر خواہ اضافہ کرنے کی ضرورت نہیں ہے۔ یہ کام کرنے کا طریقہ یہ ہے کہ ایتھیریم نوڈز کے لیے نیٹ ورک میں ڈیٹا شیئر کرنے کا ایک نیا طریقہ متعارف کرایا جائے۔ + +## پورٹل نیٹ ورک کیسے کام کرتا ہے؟ {#how-does-portal-network-work} + +ایتھیریم نوڈز کے سخت پروٹوکول ہوتے ہیں جو یہ بتاتے ہیں کہ وہ ایک دوسرے سے کیسے بات چیت کرتے ہیں۔ ایگزیکیوشن کلائنٹس [DevP2P](/developers/docs/networking-layer/#devp2p) کے نام سے جانے جانے والے سب پروٹوکولز کے ایک سیٹ کا استعمال کرتے ہوئے بات چیت کرتے ہیں، جبکہ کنسینسس کلائنٹس [libP2P](/developers/docs/networking-layer/#libp2p) کہلانے والے سب پروٹوکولز کا ایک مختلف اسٹیک استعمال کرتے ہیں۔ یہ ان ڈیٹا کی اقسام کی وضاحت کرتے ہیں جو نوڈز کے درمیان منتقل کی جا سکتی ہیں۔ + +![devP2P and libP2P](portal-network-devp2p-libp2p.png) + +نوڈز [JSON-RPC API](/developers/docs/apis/json-rpc/) کے ذریعے مخصوص ڈیٹا بھی فراہم کر سکتے ہیں، جس کے ذریعے ایپس اور والٹس ایتھیریم نوڈز کے ساتھ معلومات کا تبادلہ کرتے ہیں۔ تاہم، ان میں سے کوئی بھی لائٹ کلائنٹس کو ڈیٹا فراہم کرنے کے لیے مثالی پروٹوکول نہیں ہے۔ + +لائٹ کلائنٹس فی الحال DevP2P یا libP2p پر چین ڈیٹا کے مخصوص ٹکڑوں کی درخواست نہیں کر سکتے کیونکہ وہ پروٹوکول صرف چین کی ہم آہنگی اور بلاکس اور ٹرانزیکشنز کی گپ شپ کو فعال کرنے کے لیے بنائے گئے ہیں۔ لائٹ کلائنٹس یہ معلومات ڈاؤن لوڈ نہیں کرنا چاہتے کیونکہ اس سے وہ "لائٹ" نہیں رہیں گے۔ + +JSON-RPC API بھی لائٹ کلائنٹ ڈیٹا کی درخواستوں کے لیے ایک مثالی انتخاب نہیں ہے، کیونکہ یہ ایک مخصوص فل نوڈ یا سنٹرلائزڈ RPC فراہم کنندہ سے کنکشن پر انحصار کرتا ہے جو ڈیٹا فراہم کر سکتا ہے۔ اس کا مطلب یہ ہے کہ لائٹ کلائنٹ کو اس مخصوص نوڈ/فراہم کنندہ پر بھروسہ کرنا پڑتا ہے کہ وہ ایماندار ہے، اور فل نوڈ کو بھی بہت سے لائٹ کلائنٹس سے بہت سی درخواستوں کو ہینڈل کرنا پڑ سکتا ہے، جس سے ان کی بینڈوڈتھ کی ضروریات میں اضافہ ہوتا ہے۔ + +پورٹل نیٹ ورک کا مقصد پورے ڈیزائن پر نظر ثانی کرنا ہے، خاص طور پر موجودہ ایتھیریم کلائنٹس کے ڈیزائن کی رکاوٹوں سے باہر، ہلکے پن کے لیے تعمیر کرنا ہے۔ + +پورٹل نیٹ ورک کا بنیادی خیال موجودہ نیٹ ورکنگ اسٹیک کے بہترین حصوں کو لینا ہے، جس میں لائٹ کلائنٹس کے لیے درکار معلومات، جیسے تاریخی ڈیٹا اور چین کے موجودہ ہیڈ کی شناخت، کو ایک ہلکے پھلکے DevP2P طرز کے پیئر ٹو پیئر ڈی سینٹرلائزڈ نیٹ ورک کے ذریعے پیش کیا جائے گا جو [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (بٹ ٹورینٹ کی طرح) کا استعمال کرتا ہے۔ + +خیال یہ ہے کہ ہر نوڈ میں کل تاریخی ایتھیریم ڈیٹا کے چھوٹے حصے اور کچھ مخصوص نوڈ ذمہ داریاں شامل کی جائیں۔ پھر، درخواستوں کو ان نوڈز کو تلاش کرکے پورا کیا جاتا ہے جو درخواست کردہ مخصوص ڈیٹا کو اسٹور کر رہے ہیں اور ان سے اسے بازیافت کرتے ہیں۔ + +یہ لائٹ نوڈز کے ایک واحد نوڈ کو تلاش کرنے اور ان سے بڑی مقدار میں ڈیٹا کو فلٹر اور پیش کرنے کی درخواست کرنے کے عام ماڈل کو الٹ دیتا ہے؛ اس کے بجائے، وہ تیزی سے نوڈز کے ایک بڑے نیٹ ورک کو فلٹر کرتے ہیں جن میں سے ہر ایک چھوٹی مقدار میں ڈیٹا کو ہینڈل کرتا ہے۔ + +مقصد یہ ہے کہ ہلکے پورٹل کلائنٹس کے ایک ڈی سینٹرلائزڈ نیٹ ورک کو اجازت دی جائے کہ وہ: + +- چین کے ہیڈ کو ٹریک کریں +- حالیہ اور تاریخی چین ڈیٹا کو سنک کریں +- اسٹیٹ ڈیٹا بازیافت کریں +- ٹرانزیکشنز کو براڈکاسٹ کریں +- [EVM](/developers/docs/evm/) کا استعمال کرتے ہوئے ٹرانزیکشنز کو ایگزیکیوٹ کریں + +اس نیٹ ورک ڈیزائن کے فوائد یہ ہیں: + +- مرکزی فراہم کنندگان پر انحصار کم کریں +- انٹرنیٹ بینڈوڈتھ کا استعمال کم کریں +- کم سے کم یا صفر سنکنگ +- وسائل کی کمی والے آلات کے لیے قابل رسائی (\<1 GB RAM, \<100 MB disk space, 1 CPU) + +نیچے دی گئی جدول موجودہ کلائنٹس کے ان فنکشنز کو دکھاتی ہے جو پورٹل نیٹ ورک کے ذریعے فراہم کیے جا سکتے ہیں، جس سے صارفین بہت کم وسائل والے آلات پر ان فنکشنز تک رسائی حاصل کر سکتے ہیں۔ + +### پورٹل نیٹ ورکس + +| بیکن لائٹ کلائنٹ | اسٹیٹ نیٹ ورک | ٹرانزیکشن گپ شپ | ہسٹری نیٹ ورک | +| ---------------- | -------------------------- | ----------------- | ------------- | +| بیکن چین لائٹ | اکاؤنٹ اور کنٹریکٹ اسٹوریج | ہلکا پھلکا میمپول | ہیڈرز | +| پروٹوکول ڈیٹا | | | بلاک باڈیز | +| | | | رسیدیں | + +## بطور ڈیفالٹ کلائنٹ ڈائیورسٹی {#client-diversity-as-default} + +پورٹل نیٹ ورک کے ڈویلپرز نے پہلے دن سے ہی چار الگ الگ پورٹل نیٹ ورک کلائنٹس بنانے کا ڈیزائن کا انتخاب بھی کیا۔ + +پورٹل نیٹ ورک کلائنٹس یہ ہیں: + +- [Trin](https://github.com/ethereum/trin): Rust میں لکھا گیا +- [Fluffy](https://fluffy.guide): Nim میں لکھا گیا +- [Ultralight](https://github.com/ethereumjs/ultralight): Typescript میں لکھا گیا +- [Shisui](https://github.com/zen-eth/shisui): Go میں لکھا گیا + +متعدد آزاد کلائنٹ امپلیمنٹیشنز کا ہونا ایتھیریم نیٹ ورک کی لچک اور ڈی سینٹرلائزیشن کو بڑھاتا ہے۔ + +اگر ایک کلائنٹ کو مسائل یا کمزوریوں کا سامنا کرنا پڑتا ہے، تو دوسرے کلائنٹس آسانی سے کام کرتے رہ سکتے ہیں، جس سے ناکامی کے ایک نقطہ کو روکا جا سکتا ہے۔ اس کے علاوہ، متنوع کلائنٹ امپلیمنٹیشنز جدت اور مسابقت کو فروغ دیتی ہیں، بہتری لاتی ہیں اور ماحولیاتی نظام کے اندر مونو کلچر کے خطرے کو کم کرتی ہیں۔ + +## مزید پڑھیں {#further-reading} + +- [پورٹل نیٹ ورک (پائپر میریم بمقام ڈیوکون بوگوٹا)](https://www.youtube.com/watch?v=0stc9jnQLXA)۔ +- [پورٹل نیٹ ورک ڈسکارڈ](https://discord.gg/CFFnmE7Hbs) +- [پورٹل نیٹ ورک ویب سائٹ](https://www.ethportal.net/) diff --git a/public/content/translations/ur/developers/docs/networks/index.md b/public/content/translations/ur/developers/docs/networks/index.md new file mode 100644 index 00000000000..8141c540deb --- /dev/null +++ b/public/content/translations/ur/developers/docs/networks/index.md @@ -0,0 +1,216 @@ +--- +title: "نیٹورکس" +description: "ایتھیریم کے نیٹ ورکس کا ایک جائزہ اور اپنی ایپلیکیشن کی جانچ کے لیے ٹیسٹ نیٹ ایتھر (ETH) کہاں سے حاصل کریں۔" +lang: ur-in +--- + +ایتھیریم نیٹ ورکس منسلک کمپیوٹرز کے گروپس ہیں جو ایتھیریم پروٹوکول کا استعمال کرتے ہوئے مواصلت کرتے ہیں۔ صرف ایک ایتھیریم مین نیٹ ہے، لیکن اسی پروٹوکول کے اصولوں کے مطابق آزاد نیٹ ورکس جانچ اور ترقی کے مقاصد کے لیے بنائے جا سکتے ہیں۔ بہت سے آزاد "نیٹ ورکس" ہیں جو ایک دوسرے کے ساتھ تعامل کیے بغیر پروٹوکول کے مطابق ہیں۔ آپ اپنے اسمارٹ کانٹریکٹس اور ویب 3 ایپس کی جانچ کے لیے اپنے کمپیوٹر پر مقامی طور پر ایک شروع بھی کر سکتے ہیں۔ + +آپ کا ایتھیریم اکاؤنٹ مختلف نیٹ ورکس پر کام کرے گا، لیکن آپ کے اکاؤنٹ کا بیلنس اور ٹرانزیکشن کی تاریخ مرکزی ایتھیریم نیٹ ورک سے آگے نہیں بڑھے گی۔ جانچ کے مقاصد کے لیے، یہ جاننا مفید ہے کہ کون سے نیٹ ورکس دستیاب ہیں اور اس کے ساتھ کھیلنے کے لیے ٹیسٹ نیٹ ETH کیسے حاصل کیا جائے۔ عام طور پر، حفاظتی تحفظات کے لیے، ٹیسٹ نیٹس پر مین نیٹ اکاؤنٹس کو دوبارہ استعمال کرنے یا اس کے برعکس کرنے کی سفارش نہیں کی جاتی ہے۔ + +## شرائط {#prerequisites} + +مختلف نیٹ ورکس کے بارے میں پڑھنے سے پہلے آپ کو [ایتھیریم کی بنیادی باتیں](/developers/docs/intro-to-ethereum/) سمجھنا چاہئے، کیونکہ ٹیسٹ نیٹ ورکس آپ کو ایتھیریم کا ایک سستا، محفوظ ورژن دیں گے جس کے ساتھ آپ کھیل سکتے ہیں۔ + +## عوامی نیٹ ورکس {#public-networks} + +عوامی نیٹ ورکس دنیا میں کسی کے لیے بھی قابل رسائی ہیں جس کے پاس انٹرنیٹ کنکشن ہے۔ کوئی بھی عوامی بلاک چین پر لین دین پڑھ سکتا ہے یا بنا سکتا ہے اور عمل میں لائے جانے والے لین دین کی توثیق کر سکتا ہے۔ ساتھیوں کے درمیان اتفاق رائے لین دین کی شمولیت اور نیٹ ورک کی حالت کا فیصلہ کرتا ہے۔ + +### ایتھیریم مین نیٹ {#ethereum-mainnet} + +مین نیٹ بنیادی عوامی ایتھیریم پروڈکشن بلاک چین ہے، جہاں تقسیم شدہ لیجر پر حقیقی قدر کے لین دین ہوتے ہیں۔ + +جب لوگ اور ایکسچینجز ETH کی قیمتوں پر تبادلہ خیال کرتے ہیں، تو وہ مین نیٹ ETH کے بارے میں بات کر رہے ہوتے ہیں۔ + +### ایتھیریم ٹیسٹ نیٹس {#ethereum-testnets} + +مین نیٹ کے علاوہ، عوامی ٹیسٹ نیٹس بھی ہیں۔ یہ وہ نیٹ ورکس ہیں جو پروٹوکول ڈیولپرز یا اسمارٹ کانٹریکٹ ڈیولپرز کے ذریعے مین نیٹ پر تعیناتی سے پہلے پروڈکشن جیسے ماحول میں پروٹوکول اپ گریڈز اور ممکنہ اسمارٹ کانٹریکٹس دونوں کی جانچ کے لیے استعمال کیے جاتے ہیں۔ اسے پروڈکشن بمقابلہ اسٹیجنگ سرورز کے ایک اینالاگ کے طور پر سوچیں۔ + +آپ کو مین نیٹ پر تعینات کرنے سے پہلے ٹیسٹ نیٹ پر لکھے گئے کسی بھی کنٹریکٹ کوڈ کی جانچ کرنی چاہیے۔ موجودہ اسمارٹ کانٹریکٹس کے ساتھ مربوط ہونے والے dapps میں، زیادہ تر پروجیکٹس کی کاپیاں ٹیسٹ نیٹس پر تعینات ہوتی ہیں۔ + +زیادہ تر ٹیسٹ نیٹس کا آغاز ایک اجازت یافتہ پروف آف اتھارٹی اتفاق رائے کے طریقہ کار کا استعمال کرتے ہوئے ہوا۔ اس کا مطلب ہے کہ نوڈس کی ایک چھوٹی تعداد کا انتخاب لین دین کی توثیق کرنے اور نئے بلاکس بنانے کے لیے کیا جاتا ہے – اس عمل میں اپنی شناخت کو داؤ پر لگاتے ہوئے۔ متبادل کے طور پر، کچھ ٹیسٹ نیٹس میں ایک اوپن پروف آف اسٹیک اتفاق رائے کا طریقہ کار ہوتا ہے جہاں ہر کوئی ایک توثیق کار کو چلا کر جانچ کر سکتا ہے، بالکل ایتھیریم مین نیٹ کی طرح۔ + +ٹیسٹ نیٹس پر ETH کی کوئی حقیقی قیمت نہیں ہونی چاہیے؛ تاہم، کچھ قسم کے ٹیسٹ نیٹ ETH کے لیے مارکیٹیں بنائی گئی ہیں جو نایاب یا حاصل کرنا مشکل ہو گئی ہیں۔ چونکہ آپ کو ایتھیریم کے ساتھ حقیقت میں تعامل کرنے کے لیے ETH کی ضرورت ہے (یہاں تک کہ ٹیسٹ نیٹس پر بھی)، زیادہ تر لوگ ٹیسٹ نیٹ ETH مفت میں faucets سے حاصل کرتے ہیں۔ زیادہ تر faucets ویب ایپس ہیں جہاں آپ ایک پتہ درج کر سکتے ہیں جس پر آپ ETH بھیجنے کی درخواست کرتے ہیں۔ + +#### مجھے کون سا ٹیسٹ نیٹ استعمال کرنا چاہیے؟ + +دو عوامی ٹیسٹ نیٹس جن کی کلائنٹ ڈیولپرز فی الحال دیکھ بھال کر رہے ہیں وہ Sepolia اور Hoodi ہیں۔ Sepolia کنٹریکٹ اور ایپلیکیشن ڈیولپرز کے لیے ایک نیٹ ورک ہے تاکہ وہ اپنی ایپلیکیشنز کی جانچ کر سکیں۔ Hoodi نیٹ ورک پروٹوکول ڈیولپرز کو نیٹ ورک اپ گریڈ کی جانچ کرنے دیتا ہے، اور stakers کو چلانے والے توثیق کاروں کی جانچ کرنے دیتا ہے۔ + +#### Sepolia {#sepolia} + +**Sepolia ایپلیکیشن ڈیولپمنٹ کے لیے تجویز کردہ ڈیفالٹ ٹیسٹ نیٹ ہے**۔ Sepolia نیٹ ورک ایک اجازت یافتہ توثیق کار سیٹ کا استعمال کرتا ہے جو کلائنٹ اور ٹیسٹنگ ٹیموں کے زیر کنٹرول ہے۔ + +##### وسائل + +- [ویب سائٹ](https://sepolia.dev/) +- [GitHub](https://github.com/eth-clients/sepolia) +- [Otterscan](https://sepolia.otterscan.io/) +- [Etherscan](https://sepolia.etherscan.io) +- [Blockscout](https://eth-sepolia.blockscout.com/) + +##### Faucets + +- [Alchemy Sepolia Faucet](https://www.alchemy.com/faucets/ethereum-sepolia) +- [Chain Platform Sepolia Faucet](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) +- [Chainstack Sepolia Faucet](https://faucet.chainstack.com/sepolia-testnet-faucet) +- [ایتھیریم ایکو سسٹم Faucet](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [ethfaucet.com Sepolia Faucet](https://ethfaucet.com/networks/ethereum) +- [Google Cloud Web3 Sepolia Faucet](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) +- [Grabteeth](https://grabteeth.xyz/) +- [Infura Sepolia Faucet](https://www.infura.io/faucet) +- [PoW Faucet](https://sepolia-faucet.pk910.de/) +- [QuickNode Sepolia Faucet](https://faucet.quicknode.com/ethereum/sepolia) + +#### Hoodi {#hoodi} + +Hoodi توثیق اور اسٹیکنگ کی جانچ کے لیے ایک ٹیسٹ نیٹ ہے۔ Hoodi نیٹ ورک ان صارفین کے لیے کھلا ہے جو ایک ٹیسٹ نیٹ توثیق کار چلانا چاہتے ہیں۔ وہ Stakers جو پروٹوکول اپ گریڈز کی جانچ کرنا چاہتے ہیں، انہیں مین نیٹ پر تعینات ہونے سے پہلے Hoodi کا استعمال کرنا چاہیے۔ + +- اوپن ویلیڈیٹر سیٹ، stakers نیٹ ورک اپ گریڈز کی جانچ کر سکتے ہیں +- بڑی حالت، پیچیدہ اسمارٹ کانٹریکٹ تعاملات کی جانچ کے لیے مفید +- مطابقت پذیری میں زیادہ وقت لگتا ہے اور نوڈ چلانے کے لیے زیادہ اسٹوریج کی ضرورت ہوتی ہے + +##### وسائل + +- [ویب سائٹ](https://hoodi.ethpandaops.io/) +- [GitHub](https://github.com/eth-clients/hoodi) +- [ایکسپلورر](https://explorer.hoodi.ethpandaops.io/) +- [چیک پوائنٹ مطابقت پذیری](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Otterscan](https://hoodi.otterscan.io/) +- [Etherscan](https://hoodi.etherscan.io/) + +##### Faucets + +- [Chain Platform Hoodi Faucet](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) +- [Hoodi Faucet](https://hoodi.ethpandaops.io/) +- [PoW Faucet](https://hoodi-faucet.pk910.de/) + +#### Ephemery {#ephemery} + +Ephemery ایک منفرد قسم کا ٹیسٹ نیٹ ہے جو ہر مہینے مکمل طور پر دوبارہ ترتیب دیا جاتا ہے۔ عملدرآمد اور اتفاق رائے کی حالت ہر 28 دن میں جینیسس پر واپس چلی جاتی ہے، جس کا مطلب ہے کہ ٹیسٹ نیٹ پر ہونے والی کوئی بھی چیز عارضی ہوتی ہے۔ یہ اسے مختصر مدت کی جانچ، تیز نوڈ بوٹسٹریپ اور 'ہیلو ورلڈ' قسم کی ایپلیکیشنز کے لیے مثالی بناتا ہے جنہیں مستقل مزاجی کی ضرورت نہیں ہوتی۔ + +- ہمیشہ تازہ حالت، توثیق کاروں اور ایپس کی مختصر مدت کی جانچ +- صرف معاہدوں کا بنیادی سیٹ شامل ہے +- اوپن ویلیڈیٹر سیٹ اور بڑی مقدار میں فنڈز تک آسان رسائی +- سب سے چھوٹی نوڈ کی ضروریات اور تیز ترین مطابقت پذیری، اوسطاً <5GB + +##### وسائل + +- [ویب سائٹ](https://ephemery.dev/) +- [Github](https://github.com/ephemery-testnet/ephemery-resources) +- [کمیونٹی چیٹ](https://matrix.to/#/#staker-testnet:matrix.org) +- [Blockscout](https://explorer.ephemery.dev/) +- [Otterscan](https://otter.bordel.wtf/) +- [بیکن ایکسپلورر](https://beaconlight.ephemery.dev/) +- [چیک پوائنٹ مطابقت پذیری](https://checkpoint-sync.ephemery.ethpandaops.io) +- [Launchpad](https://launchpad.ephemery.dev/) + +#### Faucets + +- [Bordel Faucet](https://faucet.bordel.wtf/) +- [Pk910 PoW Faucet](https://ephemery-faucet.pk910.de/) + +#### Holesky (متروک) {#holesky} + +Holesky ٹیسٹ نیٹ ستمبر 2025 سے متروک ہے۔ اسٹیکنگ آپریٹرز اور انفراسٹرکچر فراہم کنندگان کو اس کے بجائے توثیق کار کی جانچ کے لیے Hoodi کا استعمال کرنا چاہیے۔ + +- [Holesky ٹیسٹ نیٹ شٹ ڈاؤن کا اعلان](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _EF بلاگ، 1-ستمبر-2025_ +- [Holesky اور Hoodi ٹیسٹ نیٹ اپ ڈیٹس](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) - _EF بلاگ، 18-مارچ-2025_ + +### لیئر 2 ٹیسٹ نیٹس {#layer-2-testnets} + +[لیئر 2 (L2)](/layer-2/) ایک اجتماعی اصطلاح ہے جو ایتھیریم اسکیلنگ حلوں کے ایک مخصوص سیٹ کو بیان کرنے کے لیے استعمال ہوتی ہے۔ لیئر 2 ایک علیحدہ بلاک چین ہے جو ایتھیریم کو توسیع دیتی ہے اور ایتھیریم کی حفاظتی ضمانتوں کو ورثے میں حاصل کرتی ہے۔ لیئر 2 ٹیسٹ نیٹس عام طور پر عوامی ایتھیریم ٹیسٹ نیٹس سے مضبوطی سے جڑے ہوتے ہیں۔ + +#### Arbitrum Sepolia {#arbitrum-sepolia} + +[Arbitrum](https://arbitrum.io/) کے لیے ایک ٹیسٹ نیٹ۔ + +##### وسائل + +- [Etherscan](https://sepolia.arbiscan.io/) +- [Blockscout](https://sepolia-explorer.arbitrum.io/) + +##### Faucets + +- [Alchemy Arbitrum Sepolia Faucet](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Chainlink Arbitrum Sepolia faucet](https://faucets.chain.link/arbitrum-sepolia) +- [ethfaucet.com Arbitrum Sepolia Faucet](https://ethfaucet.com/networks/arbitrum) +- [QuickNode Arbitrum Sepolia Faucet](https://faucet.quicknode.com/arbitrum/sepolia) + +#### Optimistic Sepolia {#optimistic-sepolia} + +[Optimism](https://www.optimism.io/) کے لیے ایک ٹیسٹ نیٹ۔ + +##### وسائل + +- [Etherscan](https://sepolia-optimistic.etherscan.io/) +- [Blockscout](https://optimism-sepolia.blockscout.com/) + +##### Faucets + +- [Alchemy Faucet](https://www.alchemy.com/faucets/optimism-sepolia) +- [Chainlink Faucet](https://faucets.chain.link/optimism-sepolia) +- [ethfaucet.com Optimism Sepolia Faucet](https://ethfaucet.com/networks/optimism) +- [ٹیسٹ نیٹ Faucet](https://docs.optimism.io/builders/tools/build/faucets) + +#### Starknet Sepolia {#starknet-sepolia} + +[Starknet](https://www.starknet.io) کے لیے ایک ٹیسٹ نیٹ۔ + +##### وسائل + +- [Starkscan](https://sepolia.starkscan.co/) + +##### Faucets + +- [Alchemy Faucet](https://www.alchemy.com/faucets/starknet-sepolia) +- [Blast Starknet Sepolia Faucet](https://blastapi.io/faucets/starknet-sepolia-eth) +- [Starknet Faucet](https://starknet-faucet.vercel.app/) + +## نجی نیٹ ورکس {#private-networks} + +ایک ایتھیریم نیٹ ورک ایک نجی نیٹ ورک ہے اگر اس کے نوڈس کسی عوامی نیٹ ورک (یعنی مین نیٹ یا ٹیسٹ نیٹ) سے منسلک نہیں ہیں۔ اس تناظر میں، نجی کا مطلب صرف مخصوص یا الگ تھلگ ہے، نہ کہ محفوظ یا مامون۔ + +### ترقیاتی نیٹ ورکس {#development-networks} + +ایک ایتھیریم ایپلیکیشن تیار کرنے کے لیے، آپ اسے تعینات کرنے سے پہلے یہ دیکھنے کے لیے ایک نجی نیٹ ورک پر چلانا چاہیں گے کہ یہ کیسے کام کرتا ہے۔ جس طرح آپ ویب ڈیولپمنٹ کے لیے اپنے کمپیوٹر پر ایک مقامی سرور بناتے ہیں، اسی طرح آپ اپنے dapp کی جانچ کے لیے ایک مقامی بلاک چین مثال بنا سکتے ہیں۔ یہ ایک عوامی ٹیسٹ نیٹ کے مقابلے میں بہت تیز تکرار کی اجازت دیتا ہے۔ + +اس میں مدد کے لیے وقف منصوبے اور اوزار موجود ہیں۔ [ترقیاتی نیٹ ورکس](/developers/docs/development-networks/) کے بارے میں مزید جانیں۔ + +### کنسورشیم نیٹ ورکس {#consortium-networks} + +اتفاق رائے کا عمل نوڈس کے پہلے سے طے شدہ سیٹ کے ذریعے کنٹرول کیا جاتا ہے جن پر بھروسہ کیا جاتا ہے۔ مثال کے طور پر، معروف تعلیمی اداروں کا ایک نجی نیٹ ورک جن میں سے ہر ایک ایک نوڈ پر حکومت کرتا ہے، اور بلاکس کو نیٹ ورک کے اندر دستخط کنندگان کی ایک حد کے ذریعے توثیق کیا جاتا ہے۔ + +اگر ایک عوامی ایتھیریم نیٹ ورک عوامی انٹرنیٹ کی طرح ہے، تو ایک کنسورشیم نیٹ ورک ایک نجی انٹرانیٹ کی طرح ہے۔ + +## ایتھیریم ٹیسٹ نیٹس کا نام میٹرو اسٹیشنوں کے نام پر کیوں رکھا گیا ہے؟ {#why-naming} + +بہت سے ایتھیریم ٹیسٹ نیٹس کا نام حقیقی دنیا کے میٹرو یا ٹرین اسٹیشنوں کے نام پر رکھا گیا ہے۔ یہ نام رکھنے کی روایت جلد شروع ہوئی اور ان عالمی شہروں کی عکاسی کرتی ہے جہاں تعاون کنندگان نے رہائش یا کام کیا ہے۔ یہ علامتی، یادگار، اور عملی ہے۔ جس طرح ٹیسٹ نیٹس ایتھیریم مین نیٹ سے الگ تھلگ ہیں، اسی طرح میٹرو لائنیں سطحی ٹریفک سے الگ چلتی ہیں۔ + +### عام طور پر استعمال ہونے والے اور میراثی ٹیسٹ نیٹس {#common-and-legacy-testnets} + +- **Sepolia** - ایتھنز، یونان میں ایک میٹرو سے منسلک پڑوس۔ فی الحال اسمارٹ کانٹریکٹ اور dApp کی جانچ کے لیے استعمال کیا جاتا ہے۔ +- **Hoodi** - بنگلورو، ہندوستان میں Hoodi میٹرو اسٹیشن کے نام پر رکھا گیا۔ توثیق کار اور پروٹوکول اپ گریڈ کی جانچ کے لیے استعمال کیا جاتا ہے۔ +- **Goerli** _(متروک)_ - برلن، جرمنی میں Görlitzer Bahnhof کے نام پر رکھا گیا۔ +- **Rinkeby** _(متروک)_ - اسٹاک ہوم کے ایک مضافاتی علاقے کے نام پر رکھا گیا جہاں میٹرو اسٹیشن ہے۔ +- **Ropsten** _(متروک)_ - اسٹاک ہوم میں ایک علاقے اور سابقہ فیری/میٹرو ٹرمینل کا حوالہ دیتا ہے۔ +- **Kovan** _(متروک)_ - سنگاپور کے ایک MRT اسٹیشن کے نام پر رکھا گیا۔ +- **Morden** _(متروک)_ - لندن انڈر گراؤنڈ اسٹیشن کے نام پر رکھا گیا۔ ایتھیریم کا پہلا عوامی ٹیسٹ نیٹ۔ + +### دیگر خصوصی ٹیسٹ نیٹس {#other-testnets} + +کچھ ٹیسٹ نیٹس مختصر مدت یا اپ گریڈ کے لیے مخصوص جانچ کے لیے بنائے گئے تھے اور ضروری نہیں کہ وہ میٹرو تھیم والے ہوں: + +- **Holesky** _(متروک)_ - پراگ میں Holešovice اسٹیشن کے نام پر رکھا گیا۔ توثیق کار کی جانچ کے لیے استعمال کیا گیا؛ 2025 میں متروک ہو گیا۔ +- **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(سبھی متروک)_ اور **Ephemery** - The Merge، شنگھائی، یا توثیق کار کے تجربات جیسے اپ گریڈ سیمولیشنز کے لیے مقصد سے بنایا گیا۔ کچھ نام میٹرو پر مبنی ہونے کے بجائے علاقائی یا موضوعاتی ہیں۔ + +میٹرو اسٹیشن کے ناموں کا استعمال ڈیولپرز کو بغیر عددی چین آئی ڈیز پر انحصار کیے ٹیسٹ نیٹس کو تیزی سے شناخت کرنے اور یاد رکھنے میں مدد کرتا ہے۔ یہ ایتھیریم کی ثقافت کی بھی عکاسی کرتا ہے: عملی، عالمی، اور انسان مرکز۔ + +## متعلقہ ٹولز {#related-tools} + +- [Chainlist](https://chainlist.org/) _EVM نیٹ ورکس کی فہرست جو بٹوے اور فراہم کنندگان کو مناسب چین آئی ڈی اور نیٹ ورک آئی ڈی سے جوڑتی ہے_ +- [EVM پر مبنی چینز](https://github.com/ethereum-lists/chains) _چین میٹا ڈیٹا کا GitHub ریپو جو Chainlist کو طاقت دیتا ہے_ + +## مزید پڑھیں {#further-reading} + +- [تجویز: پیش قیاسی ایتھیریم ٹیسٹ نیٹ لائف سائیکل](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) +- [ایتھیریم ٹیسٹ نیٹس کا ارتقاء](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/archive-nodes/index.md new file mode 100644 index 00000000000..676dc12b561 --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -0,0 +1,81 @@ +--- +title: "ایتھیریم آرکائیو نوڈ" +description: "آرکائیو نوڈز کا ایک جائزہ" +lang: ur-in +sidebarDepth: 2 +--- + +ایک آرکائیو نوڈ ایتھیریم کلائنٹ کی ایک مثال ہے جسے تمام تاریخی اسٹیٹس کا آرکائیو بنانے کے لیے کنفیگر کیا گیا ہے۔ یہ کچھ استعمال کے معاملات کے لیے ایک مفید ٹول ہے لیکن اسے ایک مکمل نوڈ کے مقابلے میں چلانا زیادہ مشکل ہو سکتا ہے۔ + +## شرائط {#prerequisites} + +آپ کو ایک [ایتھیریم نوڈ](/developers/docs/nodes-and-clients/) کے تصور، [اس کے فن تعمیر](/developers/docs/nodes-and-clients/node-architecture/)، [سنک حکمت عملی](/developers/docs/nodes-and-clients/#sync-modes)، اسے [چلانے](/developers/docs/nodes-and-clients/run-a-node/) اور [اسے استعمال کرنے](/developers/docs/apis/json-rpc/) کے طریقوں کو سمجھنا چاہیے۔ + +## آرکائیو نوڈ کیا ہے + +آرکائیو نوڈ کی اہمیت کو سمجھنے کے لیے، آئیے \"اسٹیٹ\" کے تصور کو واضح کریں۔ ایتھیریم کو _ٹرانزیکشن پر مبنی اسٹیٹ مشین_ کہا جا سکتا ہے۔ یہ اکاؤنٹس اور ایپلیکیشنز پر مشتمل ہے جو ٹرانزیکشنز کو انجام دیتے ہیں جو ان کی اسٹیٹ کو بدل رہے ہیں۔ ہر اکاؤنٹ اور کنٹریکٹ کے بارے میں معلومات کے ساتھ عالمی ڈیٹا اسٹیٹ نامی ٹرائی ڈیٹا بیس میں محفوظ کیا جاتا ہے۔ یہ ایگزیکیوشن لیئر (EL) کلائنٹ کے ذریعے سنبھالا جاتا ہے اور اس میں شامل ہیں: + +- اکاؤنٹ بیلنس اور نانسز +- کنٹریکٹ کوڈ اور اسٹوریج +- اتفاق رائے سے متعلق ڈیٹا، مثال کے طور پر، اسٹیکنگ ڈپازٹ کنٹریکٹ + +نیٹ ورک کے ساتھ تعامل کرنے، نئے بلاکس کی تصدیق کرنے اور تیار کرنے کے لیے، ایتھیریم کلائنٹس کو تازہ ترین تبدیلیوں (چین کی نوک) اور اس لیے موجودہ اسٹیٹ سے باخبر رہنا پڑتا ہے۔ ایک مکمل نوڈ کے طور پر کنفیگر کردہ ایک ایگزیکیوشن لیئر کلائنٹ نیٹ ورک کی تازہ ترین اسٹیٹ کی تصدیق کرتا ہے اور اس کی پیروی کرتا ہے لیکن صرف پچھلی چند اسٹیٹس کو کیش کرتا ہے، مثال کے طور پر، آخری 128 بلاکس سے وابستہ اسٹیٹ، تاکہ یہ چین ری آرگس کو سنبھال سکے اور حالیہ ڈیٹا تک تیز رسائی فراہم کر سکے۔ حالیہ اسٹیٹ وہ ہے جس کی تمام کلائنٹس کو آنے والے ٹرانزیکشنز کی تصدیق کرنے اور نیٹ ورک استعمال کرنے کے لیے ضرورت ہے۔ + +آپ اسٹیٹ کو ایک دیے گئے بلاک پر ایک لمحاتی نیٹ ورک اسنیپ شاٹ کے طور پر اور آرکائیو کو ہسٹری ری پلے کے طور پر تصور کر سکتے ہیں۔ + +تاریخی اسٹیٹس کو محفوظ طریقے سے پرون کیا جا سکتا ہے کیونکہ وہ نیٹ ورک کے کام کرنے کے لیے ضروری نہیں ہیں اور کلائنٹ کے لیے تمام پرانے ڈیٹا کو رکھنا بے کار طور پر فالتو ہوگا۔ کچھ حالیہ بلاک سے پہلے موجود اسٹیٹس (مثال کے طور پر، ہیڈ سے 128 بلاک پہلے) کو مؤثر طریقے سے ضائع کر دیا جاتا ہے۔ مکمل نوڈز صرف تاریخی بلاک چین ڈیٹا (بلاکس اور ٹرانزیکشنز) اور کبھی کبھار تاریخی اسنیپ شاٹس رکھتے ہیں جنہیں وہ درخواست پر پرانی اسٹیٹس کو دوبارہ بنانے کے لیے استعمال کر سکتے ہیں۔ وہ یہ EVM میں ماضی کے ٹرانزیکشنز کو دوبارہ چلا کر کرتے ہیں، جو کمپیوٹیشنل طور پر مطالبہ کر سکتا ہے جب مطلوبہ اسٹیٹ قریب ترین اسنیپ شاٹ سے دور ہو۔ + +تاہم، اس کا مطلب ہے کہ ایک مکمل نوڈ پر تاریخی اسٹیٹ تک رسائی میں بہت زیادہ کمپیوٹیشن صرف ہوتی ہے۔ کلائنٹ کو تمام ماضی کے ٹرانزیکشنز کو انجام دینے اور جینیسس سے ایک تاریخی اسٹیٹ کا حساب لگانے کی ضرورت پڑ سکتی ہے۔ آرکائیو نوڈز نہ صرف تازہ ترین اسٹیٹس کو بلکہ ہر بلاک کے بعد بنائی گئی ہر تاریخی اسٹیٹ کو بھی ذخیرہ کرکے اس مسئلے کو حل کرتے ہیں۔ یہ بنیادی طور پر بڑی ڈسک اسپیس کی ضرورت کے ساتھ ایک سمجھوتہ کرتا ہے۔ + +یہ نوٹ کرنا ضروری ہے کہ نیٹ ورک تمام تاریخی ڈیٹا کو رکھنے اور فراہم کرنے کے لیے آرکائیو نوڈز پر انحصار نہیں کرتا ہے۔ جیسا کہ اوپر بتایا گیا ہے، تمام تاریخی عبوری اسٹیٹس کو ایک مکمل نوڈ پر حاصل کیا جا سکتا ہے۔ ٹرانزیکشنز کسی بھی مکمل نوڈ (فی الحال 400G سے کم) کے ذریعے ذخیرہ کی جاتی ہیں اور پورے آرکائیو کو بنانے کے لیے انہیں دوبارہ چلایا جا سکتا ہے۔ + +### کیسز استعمال کریں + +ایتھیریم کے باقاعدہ استعمال جیسے ٹرانزیکشنز بھیجنا، کنٹریکٹس ڈیپلائے کرنا، اتفاق رائے کی تصدیق کرنا وغیرہ کے لیے تاریخی اسٹیٹس تک رسائی کی ضرورت نہیں ہوتی۔ صارفین کو نیٹ ورک کے ساتھ معیاری تعامل کے لیے کبھی بھی آرکائیو نوڈ کی ضرورت نہیں ہوتی۔ + +اسٹیٹ آرکائیو کا بنیادی فائدہ تاریخی اسٹیٹس کے بارے میں سوالات تک فوری رسائی ہے۔ مثال کے طور پر، آرکائیو نوڈ فوری طور پر اس طرح کے نتائج واپس کرے گا: + +- _اکاؤنٹ 0x1337... کا ETH بیلنس کیا تھا_ _بلاک 15537393 پر؟_ +- _بلاک 1920000 پر کنٹریکٹ 0x میں ٹوکن 0x کا بیلنس کیا ہے؟_ + +جیسا کہ اوپر بتایا گیا ہے، ایک مکمل نوڈ کو EVM ایگزیکیوشن کے ذریعے یہ ڈیٹا تیار کرنے کی ضرورت ہوگی جو CPU کا استعمال کرتا ہے اور وقت لیتا ہے۔ آرکائیو نوڈز ڈسک پر ان تک رسائی حاصل کرتے ہیں اور فوری طور پر جوابات دیتے ہیں۔ یہ انفراسٹرکچر کے کچھ حصوں کے لیے ایک مفید خصوصیت ہے، مثال کے طور پر: + +- سروس فراہم کرنے والے جیسے بلاک ایکسپلوررز +- محققین +- سیکورٹی تجزیہ کار +- Dapp ڈویلپرز +- آڈیٹنگ اور تعمیل + +مختلف مفت [سروسز](/developers/docs/nodes-and-clients/nodes-as-a-service/) ہیں جو تاریخی ڈیٹا تک رسائی کی بھی اجازت دیتی ہیں۔ چونکہ آرکائیو نوڈ چلانا زیادہ مشکل ہے، یہ رسائی زیادہ تر محدود ہے اور صرف کبھی کبھار رسائی کے لیے کام کرتی ہے۔ اگر آپ کے پروجیکٹ کو تاریخی ڈیٹا تک مسلسل رسائی کی ضرورت ہے، تو آپ کو خود ایک چلانے پر غور کرنا چاہیے۔ + +## نفاذ اور استعمال + +اس تناظر میں آرکائیو نوڈ کا مطلب صارف کا سامنا کرنے والے ایگزیکیوشن لیئر کلائنٹس کے ذریعہ پیش کردہ ڈیٹا ہے کیونکہ وہ اسٹیٹ ڈیٹا بیس کو سنبھالتے ہیں اور JSON-RPC اینڈ پوائنٹس فراہم کرتے ہیں۔ کنفیگریشن کے اختیارات، سنک کا وقت اور ڈیٹا بیس کا سائز کلائنٹ کے لحاظ سے مختلف ہو سکتے ہیں۔ تفصیلات کے لیے، براہ کرم اپنے کلائنٹ کی طرف سے فراہم کردہ دستاویزات دیکھیں۔ + +اپنا آرکائیو نوڈ شروع کرنے سے پہلے، کلائنٹس کے درمیان فرق اور خاص طور پر مختلف [ہارڈ ویئر کی ضروریات](/developers/docs/nodes-and-clients/run-a-node/#requirements) کے بارے میں جانیں۔ زیادہ تر کلائنٹس اس خصوصیت کے لیے موزوں نہیں ہیں اور ان کے آرکائیوز کو 12TB سے زیادہ جگہ کی ضرورت ہوتی ہے۔ اس کے برعکس، Erigon جیسے نفاذ اسی ڈیٹا کو 3TB سے کم میں ذخیرہ کر سکتے ہیں جو انہیں آرکائیو نوڈ چلانے کا سب سے مؤثر طریقہ بناتا ہے۔ + +## تجویز کردہ طریقے + +[نوڈ چلانے کے لیے عمومی سفارشات](/developers/docs/nodes-and-clients/run-a-node/) کے علاوہ، ایک آرکائیو نوڈ ہارڈ ویئر اور دیکھ بھال کے لحاظ سے زیادہ مطالبہ کر سکتا ہے۔ Erigon کی [کلیدی خصوصیات](https://github.com/ledgerwatch/erigon#key-features) کو مدنظر رکھتے ہوئے، سب سے عملی طریقہ [Erigon](/developers/docs/nodes-and-clients/#erigon) کلائنٹ کے نفاذ کا استعمال ہے۔ + +### ہارڈ ویئر + +ہمیشہ کلائنٹ کی دستاویزات میں دیے گئے موڈ کے لیے ہارڈ ویئر کی ضروریات کی تصدیق کرنا یقینی بنائیں۔ +آرکائیو نوڈز کے لیے سب سے بڑی ضرورت ڈسک کی جگہ ہے۔ کلائنٹ پر منحصر، یہ 3TB سے 12TB تک مختلف ہوتا ہے۔ اگرچہ HDD کو بڑی مقدار میں ڈیٹا کے لیے ایک بہتر حل سمجھا جا سکتا ہے، لیکن اسے سنک کرنے اور چین کے ہیڈ کو مسلسل اپ ڈیٹ کرنے کے لیے SSD ڈرائیوز کی ضرورت ہوگی۔ [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) ڈرائیوز کافی اچھی ہیں لیکن یہ ایک قابل اعتماد معیار کی ہونی چاہیے، کم از کم [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences)۔ ڈسک کو ڈیسک ٹاپ کمپیوٹر یا سرور میں کافی سلاٹ کے ساتھ لگایا جا سکتا ہے۔ ایسے وقف شدہ آلات اعلی اپ ٹائم نوڈ چلانے کے لیے مثالی ہیں۔ اسے لیپ ٹاپ پر چلانا بالکل ممکن ہے لیکن پورٹیبلٹی اضافی قیمت پر آئے گی۔ + +تمام ڈیٹا کو ایک والیوم میں فٹ ہونے کی ضرورت ہے، اس لیے ڈسک کو جوڑنا پڑتا ہے، مثال کے طور پر، [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) یا LVM کے ساتھ۔ [ZFS](https://en.wikipedia.org/wiki/ZFS) کا استعمال بھی قابل غور ہو سکتا ہے کیونکہ یہ \"کاپی-آن-رائٹ\" کو سپورٹ کرتا ہے جو اس بات کو یقینی بناتا ہے کہ ڈیٹا کسی بھی نچلی سطح کی غلطیوں کے بغیر ڈسک پر صحیح طریقے سے لکھا گیا ہے۔ + +حادثاتی ڈیٹا بیس کے کرپشن کو روکنے میں مزید استحکام اور سیکورٹی کے لیے، خاص طور پر ایک پیشہ ورانہ سیٹ اپ میں، اگر آپ کا سسٹم اسے سپورٹ کرتا ہے تو [ECC میموری](https://en.wikipedia.org/wiki/ECC_memory) استعمال کرنے پر غور کریں۔ RAM کا سائز عام طور پر ایک مکمل نوڈ کے برابر رکھنے کا مشورہ دیا جاتا ہے لیکن زیادہ RAM سنکرونائزیشن کو تیز کرنے میں مدد کر سکتی ہے۔ + +ابتدائی سنک کے دوران، آرکائیو موڈ میں کلائنٹس جینیسس سے ہر ٹرانزیکشن کو انجام دیں گے۔ ایگزیکیوشن کی رفتار زیادہ تر CPU سے محدود ہوتی ہے، اس لیے ایک تیز CPU ابتدائی سنک کے وقت میں مدد کر سکتا ہے۔ ایک اوسط صارف کمپیوٹر پر، ابتدائی سنک میں ایک مہینہ تک لگ سکتا ہے۔ + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم مکمل نوڈ بمقابلہ آرکائیو نوڈ](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode، ستمبر 2022_ +- [اپنا خود کا ایتھیریم آرکائیو نوڈ بنانا](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _تھامس جے رش، اگست 2021_ +- [Erigon، Erigon کے RPC اور TrueBlocks (scrape and API) کو بطور سروس کیسے سیٹ اپ کریں](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– میگنس ہینسن، اپ ڈیٹ شدہ ستمبر 2022_ + +## متعلقہ موضوعات {#related-topics} + +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) +- [ایک نوڈ چلانا](/developers/docs/nodes-and-clients/run-a-node/) diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/bootnodes/index.md new file mode 100644 index 00000000000..2f302d533d4 --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/bootnodes/index.md @@ -0,0 +1,31 @@ +--- +title: "Ethereum بوٹ نوڈس کا تعارف" +description: "بوٹ نوڈس کو سمجھنے کے لئے درکار بنیادی معلومات" +lang: ur-in +--- + +جب کوئی نیا نوڈ Ethereum نیٹ ورک میں شامل ہوتا ہے تو اسے نئے پیئرز دریافت کرنے کے لیے نیٹ ورک پر پہلے سے موجود نوڈس سے جڑنے کی ضرورت ہوتی ہے۔ Ethereum نیٹ ورک میں ان انٹری پوائنٹس کو بوٹ نوڈس کہا جاتا ہے۔ کلائنٹس میں عام طور پر بوٹ نوڈس کی ایک فہرست ہارڈ کوڈ کی ہوتی ہے۔ یہ بوٹ نوڈس عام طور پر Ethereum فاؤنڈیشن کی devops ٹیم یا خود کلائنٹ ٹیموں کے ذریعے چلائے جاتے ہیں۔ نوٹ کریں کہ بوٹ نوڈس سٹیٹک نوڈس کی طرح نہیں ہیں۔ سٹیٹک نوڈس کو بار بار کال کیا جاتا ہے، جبکہ بوٹ نوڈس کو صرف اس وقت کال کیا جاتا ہے جب جڑنے کے لیے کافی پیئرز نہ ہوں اور کسی نوڈ کو کچھ نئے کنکشنز کو بوٹسٹریپ کرنے کی ضرورت ہو۔ + +## بوٹ نوڈ سے جڑیں {#connect-to-a-bootnode} + +زیادہ تر کلائنٹس میں بوٹ نوڈس کی ایک بلٹ ان فہرست ہوتی ہے، لیکن آپ اپنا بوٹ نوڈ بھی چلانا چاہ سکتے ہیں، یا کوئی ایسا بوٹ نوڈ استعمال کر سکتے ہیں جو کلائنٹ کی ہارڈ کوڈڈ فہرست کا حصہ نہ ہو۔ اس صورت میں، آپ اپنے کلائنٹ کو شروع کرتے وقت انہیں درج ذیل طریقے سے متعین کر سکتے ہیں (مثال Geth کے لیے ہے، براہ کرم اپنے کلائنٹ کی دستاویزات دیکھیں): + +``` +geth --bootnodes "enode://@:" +``` + +## بوٹ نوڈ چلائیں {#run-a-bootnode} + +بوٹ نوڈس مکمل نوڈس ہیں جو NAT ([نیٹ ورک ایڈریس ٹرانسلیشن](https://www.geeksforgeeks.org/network-address-translation-nat/)) کے پیچھے نہیں ہیں۔ ہر مکمل نوڈ ایک بوٹ نوڈ کے طور پر کام کر سکتا ہے جب تک کہ یہ عوامی طور پر دستیاب ہو۔ + +جب آپ ایک نوڈ شروع کرتے ہیں تو اسے آپ کے [enode](/developers/docs/networking-layer/network-addresses/#enode) کو لاگ کرنا چاہیے، جو ایک عوامی شناخت کنندہ ہے جسے دوسرے آپ کے نوڈ سے جڑنے کے لیے استعمال کر سکتے ہیں۔ + +enode عام طور پر ہر دوبارہ شروع ہونے پر دوبارہ تیار کیا جاتا ہے، لہذا یہ یقینی بنائیں کہ آپ اپنے کلائنٹ کی دستاویزات کو دیکھیں کہ آپ اپنے بوٹ نوڈ کے لیے ایک مستقل enode کیسے تیار کر سکتے ہیں۔ + +ایک اچھا بوٹ نوڈ بننے کے لیے، اس سے جڑ سکنے والے پیئرز کی زیادہ سے زیادہ تعداد میں اضافہ کرنا ایک اچھا خیال ہے۔ بہت سے پیئرز کے ساتھ بوٹ نوڈ چلانے سے بینڈوتھ کی ضرورت میں نمایاں طور پر اضافہ ہوگا۔ + +## دستیاب بوٹ نوڈس {#available-bootnodes} + +go-ethereum کے اندر بلٹ ان بوٹ نوڈس کی ایک فہرست [یہاں](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) مل سکتی ہے۔ ان بوٹ نوڈس کو Ethereum فاؤنڈیشن اور go-ethereum ٹیم کے ذریعے برقرار رکھا جاتا ہے۔ + +رضاکاروں کے ذریعے برقرار رکھی گئی بوٹ نوڈس کی دیگر فہرستیں بھی دستیاب ہیں۔ براہ کرم یقینی بنائیں کہ ہمیشہ کم از کم ایک آفیشل بوٹ نوڈ شامل کریں، ورنہ آپ پر ایکلپس حملہ ہو سکتا ہے۔ diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/client-diversity/index.md new file mode 100644 index 00000000000..11751174f4a --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/client-diversity/index.md @@ -0,0 +1,132 @@ +--- +title: "کلائنٹ تنوع" +description: "ایتھیریم کلائنٹ کے تنوع کی اہمیت کی اعلی سطحی وضاحت۔" +lang: ur-in +sidebarDepth: 2 +--- + +ایتھیریم نوڈ کا برتاؤ اس کلائنٹ سافٹ ویئر کے ذریعے کنٹرول کیا جاتا ہے جسے وہ چلاتا ہے۔ کئی پروڈکشن-لیول ایتھیریم کلائنٹس ہیں، جن میں سے ہر ایک کو الگ الگ ٹیموں کے ذریعے مختلف زبانوں میں تیار اور برقرار رکھا جاتا ہے۔ کلائنٹس کو ایک مشترکہ اسپیک پر بنایا گیا ہے جو اس بات کو یقینی بناتا ہے کہ کلائنٹس ایک دوسرے کے ساتھ بغیر کسی رکاوٹ کے بات چیت کریں اور ان میں ایک جیسی فعالیت ہو اور وہ ایک مساوی صارف کا تجربہ فراہم کریں۔ تاہم، اس وقت نوڈس میں کلائنٹس کی تقسیم اتنی مساوی نہیں ہے کہ اس نیٹ ورک کی مضبوطی کو اس کی پوری صلاحیت تک پہنچایا جا سکے۔ مثالی طور پر، صارفین مختلف کلائنٹس میں تقریباً یکساں طور پر تقسیم ہو جاتے ہیں تاکہ نیٹ ورک میں زیادہ سے زیادہ کلائنٹ کا تنوع لایا جا سکے۔ + +## شرائط {#prerequisites} + +اگر آپ پہلے سے نہیں سمجھتے کہ نوڈس اور کلائنٹس کیا ہیں، تو [نوڈس اور کلائنٹس](/developers/docs/nodes-and-clients/) دیکھیں۔ [ایگزیکیوشن](/glossary/#execution-layer) اور [کنسینسس](/glossary/#consensus-layer) لیئرز کی تعریف لغت میں کی گئی ہے۔ + +## متعدد کلائنٹس کیوں ہیں؟ {#why-multiple-clients} + +متعدد، آزادانہ طور پر تیار کردہ اور برقرار رکھے گئے کلائنٹس موجود ہیں کیونکہ کلائنٹ کا تنوع نیٹ ورک کو حملوں اور بگز کے خلاف زیادہ لچکدار بناتا ہے۔ متعدد کلائنٹس ایتھیریم کے لیے ایک منفرد طاقت ہیں - دیگر بلاک چینز ایک ہی کلائنٹ کی ناقابل تسخیریت پر انحصار کرتے ہیں۔ تاہم، صرف متعدد کلائنٹس کا دستیاب ہونا کافی نہیں ہے، انہیں کمیونٹی کی طرف سے اپنانا ہوگا اور کل فعال نوڈس کو ان میں نسبتاً یکساں طور پر تقسیم کرنا ہوگا۔ + +## کلائنٹ کا تنوع کیوں اہم ہے؟ {#client-diversity-importance} + +ایک غیر مرکزی نیٹ ورک کی صحت کے لیے بہت سے آزادانہ طور پر تیار اور برقرار رکھے گئے کلائنٹس کا ہونا بہت ضروری ہے۔ آئیے اس کی وجوہات تلاش کرتے ہیں۔ + +### بگز {#bugs} + +ایک انفرادی کلائنٹ میں ایک بگ نیٹ ورک کے لیے کم خطرہ ہوتا ہے جب وہ ایتھیریم نوڈس کی اقلیت کی نمائندگی کرتا ہے۔ بہت سے کلائنٹس میں نوڈس کی تقریباً یکساں تقسیم کے ساتھ، زیادہ تر کلائنٹس کے مشترکہ مسئلے سے دوچار ہونے کا امکان کم ہوتا ہے، اور اس کے نتیجے میں، نیٹ ورک زیادہ مضبوط ہوتا ہے۔ + +### حملوں کے خلاف لچک {#resilience} + +کلائنٹ کا تنوع حملوں کے خلاف لچک بھی فراہم کرتا ہے۔ مثال کے طور پر، ایک حملہ جو [کسی خاص کلائنٹ کو دھوکہ دیتا ہے](https://twitter.com/vdWijden/status/1437712249926393858) چین کی کسی خاص شاخ پر کامیاب ہونے کا امکان نہیں ہے کیونکہ دوسرے کلائنٹس کا اسی طرح استحصال کیے جانے کا امکان نہیں ہے اور کینونیکل چین غیر خراب رہتی ہے۔ کم کلائنٹ کا تنوع غالب کلائنٹ پر ہیک سے وابستہ خطرے کو بڑھاتا ہے۔ کلائنٹ کا تنوع پہلے ہی نیٹ ورک پر بدنیتی پر مبنی حملوں کے خلاف ایک اہم دفاع ثابت ہو چکا ہے، مثال کے طور پر 2016 میں شنگھائی ڈینائل آف سروس کا حملہ اس لیے ممکن ہوا کیونکہ حملہ آور غالب کلائنٹ (Geth) کو ایک سست ڈسک i/o آپریشن کو فی بلاک دسیوں ہزار بار انجام دینے کے لیے دھوکہ دینے میں کامیاب رہے۔ چونکہ متبادل کلائنٹس بھی آن لائن تھے جو اس کمزوری کو شیئر نہیں کرتے تھے، ایتھیریم حملے کا مقابلہ کرنے اور کام جاری رکھنے میں کامیاب رہا جب کہ Geth میں کمزوری کو ٹھیک کر دیا گیا تھا۔ + +### پروف آف اسٹیک فائنلٹی {#finality} + +ایتھیریم نوڈس کے 33% سے زیادہ والے کنسینسس کلائنٹ میں ایک بگ کنسینسس لیئر کو حتمی شکل دینے سے روک سکتا ہے، جس کا مطلب ہے کہ صارفین اس بات پر بھروسہ نہیں کر سکتے کہ ٹرانزیکشنز کو کسی وقت واپس نہیں کیا جائے گا یا تبدیل نہیں کیا جائے گا۔ یہ ایتھیریم کے اوپر بنے بہت سے ایپس، خاص طور پر DeFi کے لیے بہت پریشانی کا باعث ہوگا۔ + + اس سے بھی بدتر، دو تہائی اکثریت والے کلائنٹ میں ایک اہم بگ چین کو غلط طریقے سے تقسیم اور حتمی شکل دینے کا سبب بن سکتا ہے، جس کے نتیجے میں ویلیڈیٹرز کا ایک بڑا سیٹ ایک غلط چین پر پھنس سکتا ہے۔ اگر وہ صحیح چین میں دوبارہ شامل ہونا چاہتے ہیں، تو ان ویلیڈیٹرز کو سلیشنگ یا سست اور مہنگی رضاکارانہ واپسی اور دوبارہ فعال ہونے کا سامنا کرنا پڑتا ہے۔ سلیشنگ کی شدت قصوروار نوڈس کی تعداد کے ساتھ بڑھتی ہے جس میں دو تہائی اکثریت کو زیادہ سے زیادہ (32 ETH) سلیش کیا جاتا ہے۔ + +اگرچہ یہ غیر متوقع منظرنامے ہیں، ایتھیریم ایکو سسٹم فعال نوڈس میں کلائنٹس کی تقسیم کو برابر کرکے ان کے خطرے کو کم کر سکتا ہے۔ مثالی طور پر، کوئی بھی کنسینسس کلائنٹ کبھی بھی کل نوڈس کے 33% حصے تک نہیں پہنچے گا۔ + +### مشترکہ ذمہ داری {#responsibility} + +اکثریتی کلائنٹس رکھنے کی ایک انسانی قیمت بھی ہے۔ یہ ایک چھوٹی ترقیاتی ٹیم پر اضافی دباؤ اور ذمہ داری ڈالتا ہے۔ کلائنٹ کا تنوع جتنا کم ہوگا، اکثریتی کلائنٹ کو برقرار رکھنے والے ڈیولپرز کے لیے ذمہ داری کا بوجھ اتنا ہی زیادہ ہوگا۔ اس ذمہ داری کو متعدد ٹیموں میں پھیلانا ایتھیریم کے نوڈس کے نیٹ ورک اور اس کے لوگوں کے نیٹ ورک دونوں کی صحت کے لیے اچھا ہے۔ + +## موجودہ کلائنٹ کا تنوع {#current-client-diversity} + +### ایگزیکیوشن کلائنٹس {#execution-clients-breakdown} + + + +### کنسینسس کلائنٹس {#consensus-clients-breakdown} + + + +یہ ڈایاگرام پرانا ہو سکتا ہے — تازہ ترین معلومات کے لیے [ethernodes.org](https://ethernodes.org) اور [clientdiversity.org](https://clientdiversity.org) پر جائیں۔ + +اوپر دیے گئے دو پائی چارٹس ایگزیکیوشن اور کنسینسس لیئرز کے لیے موجودہ کلائنٹ کے تنوع کے اسنیپ شاٹس دکھاتے ہیں (اکتوبر 2025 میں لکھنے کے وقت)۔ سالوں کے دوران کلائنٹ کے تنوع میں بہتری آئی ہے، اور ایگزیکیوشن لیئر نے [Geth](https://geth.ethereum.org/) کے غلبے میں کمی دیکھی ہے، جس میں [Nethermind](https://www.nethermind.io/nethermind-client) دوسرے، [Besu](https://besu.hyperledger.org/) تیسرے اور [Erigon](https://github.com/ledgerwatch/erigon) چوتھے نمبر پر ہے، جبکہ دیگر کلائنٹس نیٹ ورک کے 3% سے بھی کم پر مشتمل ہیں۔ کنسینسس لیئر پر سب سے زیادہ استعمال ہونے والا کلائنٹ—[Lighthouse](https://lighthouse.sigmaprime.io/)—دوسرے سب سے زیادہ استعمال ہونے والے کلائنٹ کے کافی قریب ہے۔ [Prysm](https://prysmaticlabs.com/#projects) اور [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) بالترتیب ~31% اور ~14% بناتے ہیں، اور دیگر کلائنٹس شاذ و نادر ہی استعمال ہوتے ہیں۔ + +ایگزیکیوشن لیئر کا ڈیٹا 26-اکتوبر-2025 کو [supermajority.info](https://supermajority.info/) سے حاصل کیا گیا تھا۔ کنسینسس کلائنٹس کا ڈیٹا [مائیکل اسپراؤل](https://github.com/sigp/blockprint) سے حاصل کیا گیا تھا۔ کنسینسس کلائنٹ کا ڈیٹا حاصل کرنا زیادہ مشکل ہے کیونکہ کنسینسس لیئر کلائنٹس کے پاس ہمیشہ غیر مبہم نشانات نہیں ہوتے ہیں جن کا استعمال ان کی شناخت کے لیے کیا جا سکے۔ ڈیٹا ایک درجہ بندی الگورتھم کا استعمال کرتے ہوئے تیار کیا گیا تھا جو کبھی کبھی کچھ اقلیتی کلائنٹس کو الجھا دیتا ہے (مزید تفصیلات کے لیے [یہاں](https://twitter.com/sproulM_/status/1440512518242197516) دیکھیں)۔ اوپر دیے گئے ڈایاگرام میں، ان مبہم درجہ بندیوں کو ایک یا/یا لیبل (مثلاً Nimbus/Teku) کے ساتھ برتا جاتا ہے۔ بہر حال، یہ واضح ہے کہ نیٹ ورک کی اکثریت Prysm چلا رہی ہے۔ صرف اسنیپ شاٹس ہونے کے باوجود، ڈایاگرام میں موجود اقدار کلائنٹ کے تنوع کی موجودہ حالت کا ایک اچھا عمومی احساس فراہم کرتی ہیں۔ + +کنسینسس لیئر کے لیے کلائنٹ کے تنوع کا تازہ ترین ڈیٹا اب [clientdiversity.org](https://clientdiversity.org/) پر دستیاب ہے۔ + +## ایگزیکیوشن لیئر {#execution-layer} + +اب تک، کلائنٹ کے تنوع کے ارد گرد گفتگو بنیادی طور پر کنسینسس لیئر پر مرکوز رہی ہے۔ تاہم، ایگزیکیوشن کلائنٹ [Geth](https://geth.ethereum.org) فی الحال تمام نوڈس کا تقریباً 85% ہے۔ یہ فیصد انہی وجوہات کی بنا پر پریشانی کا باعث ہے جو کنسینسس کلائنٹس کے لیے ہیں۔ مثال کے طور پر، Geth میں ایک بگ جو ٹرانزیکشن ہینڈلنگ یا ایگزیکیوشن پے لوڈز کی تعمیر کو متاثر کرتا ہے، کنسینسس کلائنٹس کو پریشانی والے یا بگ والے ٹرانزیکشنز کو حتمی شکل دینے کا باعث بن سکتا ہے۔ لہذا، ایتھیریم ایگزیکیوشن کلائنٹس کی زیادہ یکساں تقسیم کے ساتھ صحت مند ہوگا، مثالی طور پر کوئی بھی کلائنٹ نیٹ ورک کے 33% سے زیادہ کی نمائندگی نہیں کرتا ہے۔ + +## اقلیتی کلائنٹ کا استعمال کریں {#use-minority-client} + +کلائنٹ کے تنوع سے نمٹنے کے لیے انفرادی صارفین کو اقلیتی کلائنٹس کا انتخاب کرنے سے زیادہ کی ضرورت ہوتی ہے - اس کے لیے ویلیڈیٹر پولز اور بڑے dapps اور ایکسچینجز جیسے اداروں کو بھی کلائنٹ تبدیل کرنے کی ضرورت ہوتی ہے۔ تاہم، تمام صارفین موجودہ عدم توازن کو دور کرنے اور تمام دستیاب ایتھیریم سافٹ ویئر کے استعمال کو معمول پر لانے میں اپنا کردار ادا کر سکتے ہیں۔ مرج کے بعد، تمام نوڈ آپریٹرز کو ایک ایگزیکیوشن کلائنٹ اور ایک کنسینسس کلائنٹ چلانے کی ضرورت ہوگی۔ ذیل میں تجویز کردہ کلائنٹس کے امتزاج کا انتخاب کلائنٹ کے تنوع کو بڑھانے میں مدد کرے گا۔ + +### ایگزیکیوشن کلائنٹس {#execution-clients} + +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) + +### کنسینسس کلائنٹس {#consensus-clients} + +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) + +تکنیکی صارفین اقلیتی کلائنٹس کے لیے مزید ٹیوٹوریلز اور دستاویزات لکھ کر اور اپنے نوڈ آپریٹنگ ساتھیوں کو غالب کلائنٹس سے دور منتقل ہونے کی ترغیب دے کر اس عمل کو تیز کرنے میں مدد کر سکتے ہیں۔ اقلیتی کنسینسس کلائنٹ پر سوئچ کرنے کے لیے گائیڈز [clientdiversity.org](https://clientdiversity.org/) پر دستیاب ہیں۔ + +## کلائنٹ تنوع کے ڈیش بورڈز {#client-diversity-dashboards} + +کئی ڈیش بورڈز ایگزیکیوشن اور کنسینسس لیئر کے لیے ریئل ٹائم کلائنٹ تنوع کے اعدادوشمار دیتے ہیں۔ + +**کنسینسس لیئر:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) + +**ایگزیکیوشن لیئر:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم کے کنسینسس لیئر پر کلائنٹ کا تنوع](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [ایتھیریم مرج: اکثریتی کلائنٹ کو اپنے خطرے پر چلائیں!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest، 24 مارچ 2022_ +- [کلائنٹ کے تنوع کی اہمیت](https://our.status.im/the-importance-of-client-diversity/) +- [Ethereum نوڈ سروسز کی فہرست](https://ethereumnodes.com/) +- [کلائنٹ تنوع کے مسئلے کے "پانچ کیوں"](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [ایتھیریم تنوع اور اسے کیسے حل کیا جائے (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## متعلقہ موضوعات {#related-topics} + +- [ایتھیریم نوڈ چلائیں](/run-a-node/) +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/index.md new file mode 100644 index 00000000000..d119b6e4986 --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/index.md @@ -0,0 +1,319 @@ +--- +title: "نوڈز اور کلائنٹس" +description: "ایتھیریم نوڈز اور کلائنٹ سافٹ ویئر کا ایک جائزہ، نیز ایک نوڈ کیسے سیٹ اپ کریں اور آپ کو یہ کیوں کرنا چاہئے۔" +lang: ur-in +sidebarDepth: 2 +--- + +ایتھیریم کمپیوٹرز کا ایک تقسیم شدہ نیٹ ورک ہے (جسے نوڈز کہا جاتا ہے) جو ایسا سافٹ ویئر چلاتا ہے جو بلاکس اور ٹرانزیکشن ڈیٹا کی تصدیق کر سکتا ہے۔ اسے ایتھیریم نوڈ میں تبدیل کرنے کے لیے آپ کے کمپیوٹر پر سافٹ ویئر چلایا جانا چاہیے۔ ایک نوڈ بنانے کے لیے سافٹ ویئر کے دو الگ الگ ٹکڑوں (جنہیں 'کلائنٹس' کہا جاتا ہے) کی ضرورت ہوتی ہے۔ + +## شرائط {#prerequisites} + +ایتھیریم کلائنٹ کی اپنی مثال کو مزید گہرائی میں جانے اور چلانے سے پہلے آپ کو پیئر-ٹو-پیئر نیٹ ورک کے تصور اور [EVM کی بنیادی باتوں](/developers/docs/evm/) کو سمجھنا چاہیے۔ ہمارا [ایتھیریم کا تعارف](/developers/docs/intro-to-ethereum/) دیکھیں۔ + +اگر آپ نوڈز کے موضوع میں نئے ہیں، تو ہم تجویز کرتے ہیں کہ پہلے [ایتھیریم نوڈ چلانے](/run-a-node) پر ہمارا صارف دوست تعارف دیکھیں۔ + +## نوڈز اور کلائنٹس کیا ہیں؟ {#what-are-nodes-and-clients} + +ایک "نوڈ" ایتھیریم کلائنٹ سافٹ ویئر کی کوئی بھی مثال ہے جو ایتھیریم سافٹ ویئر چلانے والے دوسرے کمپیوٹرز سے بھی منسلک ہے، جو ایک نیٹ ورک بناتا ہے۔ ایک کلائنٹ ایتھیریم کا ایک نفاذ ہے جو پروٹوکول کے اصولوں کے خلاف ڈیٹا کی تصدیق کرتا ہے اور نیٹ ورک کو محفوظ رکھتا ہے۔ ایک نوڈ کو دو کلائنٹس چلانے ہوتے ہیں: ایک کنسنسس کلائنٹ اور ایک ایگزیکیوشن کلائنٹ۔ + +- ایگزیکیوشن کلائنٹ (جسے ایگزیکیوشن انجن، EL کلائنٹ یا پہلے Eth1 کلائنٹ بھی کہا جاتا ہے) نیٹ ورک میں نشر ہونے والی نئی ٹرانزیکشنز کو سنتا ہے، انہیں EVM میں انجام دیتا ہے، اور تمام موجودہ ایتھیریم ڈیٹا کی تازہ ترین اسٹیٹ اور ڈیٹا بیس رکھتا ہے۔ +- کنسنسس کلائنٹ (جسے بیکن نوڈ، CL کلائنٹ یا پہلے Eth2 کلائنٹ بھی کہا جاتا ہے) پروف آف اسٹیک کنسنسس الگورتھم کو نافذ کرتا ہے، جو نیٹ ورک کو ایگزیکیوشن کلائنٹ سے تصدیق شدہ ڈیٹا کی بنیاد پر معاہدہ حاصل کرنے کے قابل بناتا ہے۔ سافٹ ویئر کا ایک تیسرا ٹکڑا بھی ہے، جسے 'ویلیڈیٹر' کہا جاتا ہے جسے کنسنسس کلائنٹ میں شامل کیا جا سکتا ہے، جو ایک نوڈ کو نیٹ ورک کو محفوظ بنانے میں حصہ لینے کی اجازت دیتا ہے۔ + +یہ کلائنٹس ایتھیریم چین کے ہیڈ پر نظر رکھنے کے لیے مل کر کام کرتے ہیں اور صارفین کو ایتھیریم نیٹ ورک کے ساتھ تعامل کرنے کی اجازت دیتے ہیں۔ سافٹ ویئر کے متعدد ٹکڑوں کے ساتھ ماڈیولر ڈیزائن جو ایک ساتھ کام کرتے ہیں اسے [encapsulated complexity](https://vitalik.eth.limo/general/2022/02/28/complexity.html) کہا جاتا ہے۔ اس نقطہ نظر نے [The Merge](/roadmap/merge) کو بغیر کسی رکاوٹ کے انجام دینا آسان بنا دیا، کلائنٹ سافٹ ویئر کو برقرار رکھنا اور تیار کرنا آسان بناتا ہے، اور انفرادی کلائنٹس کے دوبارہ استعمال کو قابل بناتا ہے، مثال کے طور پر، [لیئر 2 ایکو سسٹم](/layer-2/) میں۔ + +![جوڑے ہوئے ایگزیکیوشن اور کنسنسس کلائنٹس](./eth1eth2client.png) +جوڑے ہوئے ایگزیکیوشن اور کنسنسس کلائنٹ کا آسان خاکہ۔ + +### کلائنٹ کا تنوع {#client-diversity} + +دونوں [ایگزیکیوشن کلائنٹس](/developers/docs/nodes-and-clients/#execution-clients) اور [کنسنسس کلائنٹس](/developers/docs/nodes-and-clients/#consensus-clients) مختلف ٹیموں کے ذریعہ تیار کردہ مختلف پروگرامنگ زبانوں میں موجود ہیں۔ + +متعدد کلائنٹ کے نفاذ ایک ہی کوڈبیس پر اس کا انحصار کم کرکے نیٹ ورک کو مضبوط بنا سکتے ہیں۔ مثالی مقصد یہ ہے کہ نیٹ ورک پر کسی بھی کلائنٹ کے غلبہ کے بغیر تنوع حاصل کیا جائے، اس طرح ناکامی کے ممکنہ واحد نقطہ کو ختم کیا جائے۔ +زبانوں کی مختلف قسمیں ایک وسیع تر ڈیولپر کمیونٹی کو بھی مدعو کرتی ہیں اور انہیں اپنی ترجیحی زبان میں انضمام پیدا کرنے کی اجازت دیتی ہیں۔ + +[کلائنٹ کے تنوع](/developers/docs/nodes-and-clients/client-diversity/) کے بارے میں مزید جانیں۔ + +ان نفاذ میں جو چیز مشترک ہے وہ یہ ہے کہ وہ سب ایک ہی تفصیلات پر عمل کرتے ہیں۔ تفصیلات یہ بتاتی ہیں کہ ایتھیریم نیٹ ورک اور بلاک چین کیسے کام کرتے ہیں۔ ہر تکنیکی تفصیل کی وضاحت کی گئی ہے اور تفصیلات اس طرح مل سکتی ہیں: + +- اصل میں، [ایتھیریم یلو پیپر](https://ethereum.github.io/yellowpaper/paper.pdf) +- [ایگزیکیوشن کی تفصیلات](https://github.com/ethereum/execution-specs/) +- [کنسنسس کی تفصیلات](https://github.com/ethereum/consensus-specs) +- مختلف [نیٹ ورک اپ گریڈ](/ethereum-forks/) میں نافذ [EIPs](https://eips.ethereum.org/) + +### نیٹ ورک میں نوڈز کو ٹریک کرنا {#network-overview} + +متعدد ٹریکرز ایتھیریم نیٹ ورک میں نوڈز کا حقیقی وقت کا جائزہ پیش کرتے ہیں۔ نوٹ کریں کہ غیر مرکزی نیٹ ورکس کی نوعیت کی وجہ سے، یہ کرالر صرف نیٹ ورک کا ایک محدود نظارہ فراہم کر سکتے ہیں اور مختلف نتائج کی اطلاع دے سکتے ہیں۔ + +- Etherscan کی طرف سے [نوڈز کا نقشہ](https://etherscan.io/nodetracker) +- Bitfly کی طرف سے [Ethernodes](https://ethernodes.org/) +- Chainsafe کی طرف سے [Nodewatch](https://www.nodewatch.io/)، کنسنسس نوڈز کو کرال کرنا +- [Monitoreth](https://monitoreth.io/) - MigaLabs کی طرف سے، ایک تقسیم شدہ نیٹ ورک مانیٹرنگ ٹول +- [ہفتہ وار نیٹ ورک ہیلتھ رپورٹس](https://probelab.io) - ProbeLab کی طرف سے، [نیبولا کرالر](https://github.com/dennis-tra/nebula) اور دیگر ٹولز کا استعمال + +## نوڈ کی اقسام {#node-types} + +اگر آپ [اپنا نوڈ چلانا چاہتے ہیں](/developers/docs/nodes-and-clients/run-a-node/)، تو آپ کو یہ سمجھنا چاہیے کہ نوڈ کی مختلف قسمیں ہیں جو ڈیٹا کو مختلف طریقے سے استعمال کرتی ہیں۔ درحقیقت، کلائنٹس تین مختلف قسم کے نوڈز چلا سکتے ہیں: لائٹ، فل اور آرکائیو۔ مختلف سنک حکمت عملیوں کے اختیارات بھی ہیں جو تیز سنکرونائزیشن کا وقت فراہم کرتے ہیں۔ سنکرونائزیشن سے مراد یہ ہے کہ یہ ایتھیریم کی اسٹیٹ پر کتنی جلدی تازہ ترین معلومات حاصل کر سکتا ہے۔ + +### فل نوڈ {#full-node} + +فل نوڈز بلاک چین کی بلاک بہ بلاک توثیق کرتے ہیں، بشمول ہر بلاک کے لیے بلاک باڈی اور اسٹیٹ ڈیٹا کو ڈاؤن لوڈ اور تصدیق کرنا۔ فل نوڈ کی مختلف کلاسیں ہیں - کچھ جینیسس بلاک سے شروع ہوتی ہیں اور بلاک چین کی پوری تاریخ میں ہر ایک بلاک کی تصدیق کرتی ہیں۔ دوسرے اپنی تصدیق ایک حالیہ بلاک سے شروع کرتے ہیں جس پر وہ درست ہونے کا بھروسہ کرتے ہیں (مثلاً، Geth کا 'سنیپ سنک')۔ اس سے کوئی فرق نہیں پڑتا ہے کہ تصدیق کہاں سے شروع ہوتی ہے، فل نوڈز صرف نسبتاً حالیہ ڈیٹا (عام طور پر حالیہ ترین 128 بلاکس) کی مقامی کاپی رکھتے ہیں، جس سے ڈسک کی جگہ بچانے کے لیے پرانے ڈیٹا کو حذف کرنے کی اجازت ملتی ہے۔ پرانے ڈیٹا کو ضرورت پڑنے پر دوبارہ بنایا جا سکتا ہے۔ + +- فل بلاک چین ڈیٹا کو اسٹور کرتا ہے (حالانکہ اسے وقتاً فوقتاً صاف کیا جاتا ہے تاکہ ایک فل نوڈ تمام اسٹیٹ ڈیٹا کو جینیسس تک اسٹور نہ کرے) +- بلاک کی توثیق میں حصہ لیتا ہے، تمام بلاکس اور اسٹیٹس کی تصدیق کرتا ہے۔ +- تمام اسٹیٹس کو یا تو مقامی اسٹوریج سے بازیافت کیا جا سکتا ہے یا ایک فل نوڈ کے ذریعے 'سنیپ شاٹس' سے دوبارہ بنایا جا سکتا ہے۔ +- نیٹ ورک کی خدمت کرتا ہے اور درخواست پر ڈیٹا فراہم کرتا ہے۔ + +### آرکائیو نوڈ {#archive-node} + +آرکائیو نوڈز فل نوڈز ہیں جو جینیسس سے ہر بلاک کی تصدیق کرتے ہیں اور ڈاؤن لوڈ کردہ ڈیٹا میں سے کسی کو بھی کبھی حذف نہیں کرتے ہیں۔ + +- فل نوڈ میں رکھی گئی ہر چیز کو اسٹور کرتا ہے اور تاریخی اسٹیٹس کا ایک آرکائیو بناتا ہے۔ اگر آپ بلاک #4,000,000 پر اکاؤنٹ بیلنس جیسی کوئی چیز دریافت کرنا چاہتے ہیں، یا ٹریسنگ کا استعمال کیے بغیر اپنے ٹرانزیکشن سیٹ کو قابل اعتماد طریقے سے جانچنا چاہتے ہیں تو اس کی ضرورت ہے۔ +- یہ ڈیٹا ٹیرا بائٹس کی اکائیوں کی نمائندگی کرتا ہے، جو آرکائیو نوڈز کو اوسط صارفین کے لیے کم پرکشش بناتا ہے لیکن بلاک ایکسپلوررز، والیٹ وینڈرز، اور چین تجزیات جیسی خدمات کے لیے کارآمد ہو سکتا ہے۔ + +آرکائیو کے علاوہ کسی بھی موڈ میں کلائنٹس کو سنک کرنے کے نتیجے میں بلاک چین کا ڈیٹا کم ہو جائے گا۔ اس کا مطلب ہے، تمام تاریخی اسٹیٹس کا کوئی آرکائیو نہیں ہے لیکن فل نوڈ انہیں طلب پر بنانے کے قابل ہے۔ + +[آرکائیو نوڈز](/developers/docs/nodes-and-clients/archive-nodes) کے بارے میں مزید جانیں۔ + +### لائٹ نوڈ {#light-node} + +ہر بلاک کو ڈاؤن لوڈ کرنے کے بجائے، لائٹ نوڈز صرف بلاک ہیڈرز ڈاؤن لوڈ کرتے ہیں۔ ان ہیڈرز میں بلاکس کے مواد کے بارے میں خلاصہ معلومات ہوتی ہیں۔ لائٹ نوڈ کو درکار کوئی بھی دوسری معلومات فل نوڈ سے درخواست کی جاتی ہے۔ لائٹ نوڈ پھر بلاک ہیڈرز میں اسٹیٹ روٹس کے خلاف موصول ہونے والے ڈیٹا کی آزادانہ طور پر تصدیق کر سکتا ہے۔ لائٹ نوڈز صارفین کو فل نوڈز چلانے کے لیے درکار طاقتور ہارڈ ویئر یا ہائی بینڈوڈتھ کے بغیر ایتھیریم نیٹ ورک میں حصہ لینے کے قابل بناتے ہیں۔ آخر کار، لائٹ نوڈز موبائل فونز یا ایمبیڈڈ ڈیوائسز پر چل سکتے ہیں۔ لائٹ نوڈز کنسنسس میں حصہ نہیں لیتے ہیں (یعنی، وہ ویلیڈیٹرز نہیں ہو سکتے)، لیکن وہ فل نوڈ کی طرح کی فعالیت اور سیکیورٹی کی ضمانتوں کے ساتھ ایتھیریم بلاک چین تک رسائی حاصل کر سکتے ہیں۔ + +لائٹ کلائنٹس ایتھیریم کے لیے فعال ترقی کا ایک شعبہ ہیں اور ہم جلد ہی کنسنسس لیئر اور ایگزیکیوشن لیئر کے لیے نئے لائٹ کلائنٹس دیکھنے کی توقع کرتے ہیں۔ +[گوسپ نیٹ ورک](https://www.ethportal.net/) پر لائٹ کلائنٹ ڈیٹا فراہم کرنے کے ممکنہ راستے بھی ہیں۔ یہ فائدہ مند ہے کیونکہ گوسپ نیٹ ورک درخواستوں کی خدمت کے لیے فل نوڈز کی ضرورت کے بغیر لائٹ نوڈز کے نیٹ ورک کو سپورٹ کر سکتا ہے۔ + +ایتھیریم ابھی تک لائٹ نوڈز کی ایک بڑی آبادی کو سپورٹ نہیں کرتا ہے، لیکن لائٹ نوڈ سپورٹ ایک ایسا شعبہ ہے جس کی مستقبل قریب میں تیزی سے ترقی کی توقع ہے۔ خاص طور پر، [Nimbus](https://nimbus.team/)، [Helios](https://github.com/a16z/helios)، اور [LodeStar](https://lodestar.chainsafe.io/) جیسے کلائنٹس فی الحال لائٹ نوڈز پر بہت زیادہ توجہ مرکوز کیے ہوئے ہیں۔ + +## مجھے ایتھیریم نوڈ کیوں چلانا چاہئے؟ {#why-should-i-run-an-ethereum-node} + +ایک نوڈ چلانے سے آپ کو ایتھیریم کو براہ راست، بغیر کسی بھروسے اور نجی طور پر استعمال کرنے کی اجازت ملتی ہے جبکہ نیٹ ورک کو مزید مضبوط اور غیر مرکزی رکھ کر اس کی حمایت کرتے ہیں۔ + +### آپ کے لیے فوائد {#benefits-to-you} + +اپنا نوڈ چلانے سے آپ ایتھیریم کو نجی، خود کفیل اور بغیر کسی بھروسے کے طریقے سے استعمال کر سکتے ہیں۔ آپ کو نیٹ ورک پر بھروسہ کرنے کی ضرورت نہیں ہے کیونکہ آپ اپنے کلائنٹ کے ساتھ خود ڈیٹا کی تصدیق کر سکتے ہیں۔ "بھروسہ نہ کریں، تصدیق کریں" ایک مشہور بلاک چین منتر ہے۔ + +- آپ کا نوڈ خود ہی تمام ٹرانزیکشنز اور بلاکس کی کنسنسس کے اصولوں کے خلاف تصدیق کرتا ہے۔ اس کا مطلب ہے کہ آپ کو نیٹ ورک میں کسی دوسرے نوڈ پر انحصار کرنے یا ان پر مکمل بھروسہ کرنے کی ضرورت نہیں ہے۔ +- آپ اپنے نوڈ کے ساتھ ایتھیریم والیٹ استعمال کر سکتے ہیں۔ آپ ڈی ایپس کو زیادہ محفوظ اور نجی طور پر استعمال کر سکتے ہیں کیونکہ آپ کو اپنے پتے اور بیلنس بیچوانوں کو لیک کرنے کی ضرورت نہیں ہوگی۔ ہر چیز کو آپ کے اپنے کلائنٹ سے چیک کیا جا سکتا ہے۔ [MetaMask](https://metamask.io)، [Frame](https://frame.sh/)، اور [بہت سے دوسرے والیٹس](/wallets/find-wallet/) RPC-امپورٹنگ کی پیشکش کرتے ہیں، جو انہیں آپ کا نوڈ استعمال کرنے کی اجازت دیتے ہیں۔ +- آپ دوسری خدمات چلا سکتے ہیں اور خود میزبان کر سکتے ہیں جو ایتھیریم کے ڈیٹا پر منحصر ہیں۔ مثال کے طور پر، یہ ایک بیکن چین ویلیڈیٹر، لیئر 2 جیسا سافٹ ویئر، انفراسٹرکچر، بلاک ایکسپلوررز، ادائیگی کے پروسیسرز وغیرہ ہو سکتا ہے۔ +- آپ اپنے خود کے کسٹم [RPC اینڈ پوائنٹس](/developers/docs/apis/json-rpc/) فراہم کر سکتے ہیں۔ آپ کمیونٹی کو یہ اینڈ پوائنٹس عوامی طور پر پیش کر سکتے ہیں تاکہ انہیں بڑے مرکزی فراہم کنندگان سے بچنے میں مدد ملے۔ +- آپ **انٹر-پروسیس کمیونیکیشنز (IPC)** کا استعمال کرکے اپنے نوڈ سے جڑ سکتے ہیں یا اپنے پروگرام کو بطور پلگ ان لوڈ کرنے کے لیے نوڈ کو دوبارہ لکھ سکتے ہیں۔ یہ کم لیٹنسی فراہم کرتا ہے، جو بہت مدد کرتا ہے، مثال کے طور پر، جب web3 لائبریریوں کا استعمال کرتے ہوئے بہت سارے ڈیٹا پر کارروائی کی جاتی ہے یا جب آپ کو اپنی ٹرانزیکشنز کو جلد از جلد تبدیل کرنے کی ضرورت ہوتی ہے (یعنی، فرنٹ رننگ)۔ +- آپ نیٹ ورک کو محفوظ بنانے اور انعامات حاصل کرنے کے لیے براہ راست ETH اسٹیک کر سکتے ہیں۔ شروع کرنے کے لیے [سولو اسٹیکنگ](/staking/solo/) دیکھیں۔ + +![آپ اپنی ایپلیکیشن اور نوڈز کے ذریعے ایتھیریم تک کیسے رسائی حاصل کرتے ہیں](./nodes.png) + +### نیٹ ورک کے فوائد {#network-benefits} + +نوڈز کا ایک متنوع سیٹ ایتھیریم کی صحت، حفاظت اور آپریشنل لچک کے لیے اہم ہے۔ + +- فل نوڈز کنسنسس کے اصولوں کو نافذ کرتے ہیں تاکہ انہیں ایسے بلاکس کو قبول کرنے کے لیے دھوکہ نہ دیا جا سکے جو ان پر عمل نہیں کرتے ہیں۔ یہ نیٹ ورک میں اضافی سیکیورٹی فراہم کرتا ہے کیونکہ اگر تمام نوڈز لائٹ نوڈز ہوتے، جو مکمل تصدیق نہیں کرتے، تو ویلیڈیٹرز نیٹ ورک پر حملہ کر سکتے تھے۔ +- [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/#what-is-pos) کے کرپٹو-اکنامک دفاع پر قابو پانے والے حملے کی صورت میں، ایماندار چین کی پیروی کرنے کا انتخاب کرنے والے فل نوڈز کے ذریعے سماجی بحالی کی جا سکتی ہے۔ +- نیٹ ورک میں زیادہ نوڈز کے نتیجے میں ایک زیادہ متنوع اور مضبوط نیٹ ورک ہوتا ہے، جو غیر مرکزیت کا حتمی مقصد ہے، جو ایک سنسر شپ مزاحم اور قابل اعتماد نظام کو قابل بناتا ہے۔ +- فل نوڈز ہلکے وزن والے کلائنٹس کے لیے بلاک چین ڈیٹا تک رسائی فراہم کرتے ہیں جو اس پر منحصر ہیں۔ لائٹ نوڈز پوری بلاک چین کو اسٹور نہیں کرتے، اس کے بجائے وہ [بلاک ہیڈرز میں اسٹیٹ روٹس](/developers/docs/blocks/#block-anatomy) کے ذریعے ڈیٹا کی تصدیق کرتے ہیں۔ اگر انہیں ضرورت ہو تو وہ فل نوڈز سے مزید معلومات کی درخواست کر سکتے ہیں۔ + +اگر آپ ایک فل نوڈ چلاتے ہیں، تو پورا ایتھیریم نیٹ ورک اس سے فائدہ اٹھاتا ہے، یہاں تک کہ اگر آپ ویلیڈیٹر نہیں چلاتے ہیں۔ + +## اپنا نوڈ چلانا {#running-your-own-node} + +اپنا ایتھیریم کلائنٹ چلانے میں دلچسپی ہے؟ + +ایک ابتدائی دوست تعارف کے لیے مزید جاننے کے لیے ہمارا [ایک نوڈ چلائیں](/run-a-node) صفحہ دیکھیں۔ + +اگر آپ زیادہ تکنیکی صارف ہیں، تو [اپنا نوڈ کیسے چلائیں](/developers/docs/nodes-and-clients/run-a-node/) کے بارے میں مزید تفصیلات اور اختیارات میں غوطہ لگائیں۔ + +## متبادلات {#alternatives} + +اپنا نوڈ سیٹ اپ کرنے میں آپ کا وقت اور وسائل لگ سکتے ہیں لیکن آپ کو ہمیشہ اپنی مثال چلانے کی ضرورت نہیں ہوتی۔ اس صورت میں، آپ کسی تیسرے فریق API فراہم کنندہ کا استعمال کر سکتے ہیں۔ ان خدمات کو استعمال کرنے کے ایک جائزہ کے لیے، [نوڈز بطور سروس](/developers/docs/nodes-and-clients/nodes-as-a-service/) دیکھیں۔ + +اگر کوئی آپ کی کمیونٹی میں پبلک API کے ساتھ ایتھیریم نوڈ چلاتا ہے، تو آپ کسٹم RPC کے ذریعے اپنے والیٹس کو کمیونٹی نوڈ کی طرف اشارہ کر سکتے ہیں اور کسی بے ترتیب بھروسہ مند تیسرے فریق کے مقابلے میں زیادہ رازداری حاصل کر سکتے ہیں۔ + +دوسری طرف، اگر آپ ایک کلائنٹ چلاتے ہیں، تو آپ اسے اپنے دوستوں کے ساتھ شیئر کر سکتے ہیں جنہیں اس کی ضرورت ہو سکتی ہے۔ + +## ایگزیکیوشن کلائنٹس {#execution-clients} + +ایتھیریم کمیونٹی متعدد اوپن سورس ایگزیکیوشن کلائنٹس (پہلے 'Eth1 کلائنٹس'، یا صرف 'ایتھیریم کلائنٹس' کے نام سے جانا جاتا تھا) کو برقرار رکھتی ہے، جو مختلف ٹیموں نے مختلف پروگرامنگ زبانوں کا استعمال کرتے ہوئے تیار کیے ہیں۔ یہ نیٹ ورک کو مضبوط اور زیادہ [متنوع](/developers/docs/nodes-and-clients/client-diversity/) بناتا ہے۔ مثالی مقصد یہ ہے کہ کسی بھی کلائنٹ کے غلبے کے بغیر تنوع حاصل کیا جائے تاکہ ناکامی کے کسی ایک نقطہ کو کم کیا جا سکے۔ + +یہ جدول مختلف کلائنٹس کا خلاصہ کرتا ہے۔ یہ سبھی [کلائنٹ ٹیسٹ](https://github.com/ethereum/tests) پاس کرتے ہیں اور نیٹ ورک اپ گریڈ کے ساتھ اپ ڈیٹ رہنے کے لیے فعال طور پر برقرار رکھے جاتے ہیں۔ + +| کلائنٹ | زبان | آپریٹنگ سسٹمز | نیٹورکس | سنک حکمت عملیاں | اسٹیٹ کی چھانٹی | +| ------------------------------------------------------------------------------------------- | ------------------------ | --------------------- | ---------------------- | ------------------------------------------------------------------------------- | ------------------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | مین نیٹ، سیپولیا، ہوڈی | [Snap](#snap-sync), [Full](#full-sync) | آرکائیو، چھانٹا ہوا | +| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | مین نیٹ، سیپولیا، ہوڈی | [Snap](#snap-sync) (سرونگ کے بغیر)، فاسٹ، [Full](#full-sync) | آرکائیو، چھانٹا ہوا | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | مین نیٹ، سیپولیا، ہوڈی | [Snap](#snap-sync), [Fast](#fast-sync), [Full](#full-sync) | آرکائیو، چھانٹا ہوا | +| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | مین نیٹ، سیپولیا، ہوڈی | [Full](#full-sync) | آرکائیو، چھانٹا ہوا | +| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | مین نیٹ، سیپولیا، ہوڈی | [Full](#full-sync) | آرکائیو، چھانٹا ہوا | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(بیٹا)_ | TypeScript | Linux, Windows, macOS | سیپولیا، ہوڈی | [Full](#full-sync) | چھانٹا ہوا | + +معاون نیٹ ورکس کے بارے میں مزید جاننے کے لیے، [ایتھیریم نیٹ ورکس](/developers/docs/networks/) پر پڑھیں۔ + +ہر کلائنٹ کے منفرد استعمال کے معاملات اور فوائد ہیں، لہذا آپ کو اپنی ترجیحات کی بنیاد پر ایک کا انتخاب کرنا چاہیے۔ تنوع نفاذ کو مختلف خصوصیات اور صارف کے سامعین پر توجہ مرکوز کرنے کی اجازت دیتا ہے۔ آپ خصوصیات، سپورٹ، پروگرامنگ زبان، یا لائسنس کی بنیاد پر ایک کلائنٹ کا انتخاب کرنا چاہیں گے۔ + +### Besu {#besu} + +Hyperledger Besu پبلک اور اجازت یافتہ نیٹ ورکس کے لیے ایک انٹرپرائز-گریڈ ایتھیریم کلائنٹ ہے۔ یہ ٹریسنگ سے لے کر GraphQL تک تمام ایتھیریم مین نیٹ خصوصیات چلاتا ہے، اس میں وسیع نگرانی ہے اور ConsenSys کے ذریعہ اس کی حمایت کی جاتی ہے، دونوں کھلے کمیونٹی چینلز میں اور کاروباری اداروں کے لیے تجارتی SLAs کے ذریعے۔ یہ جاوا میں لکھا گیا ہے اور اپاچی 2.0 لائسنس یافتہ ہے۔ + +Besu کی وسیع [دستاویزات](https://besu.hyperledger.org/en/stable/) آپ کو اس کی خصوصیات اور سیٹ اپ پر تمام تفصیلات کے ذریعے رہنمائی کرے گی۔ + +### Erigon {#erigon} + +Erigon، جسے پہلے Turbo‐Geth کے نام سے جانا جاتا تھا، Go Ethereum کے ایک فورک کے طور پر شروع ہوا جو رفتار اور ڈسک کی جگہ کی کارکردگی کی طرف مبنی تھا۔ Erigon ایتھیریم کا ایک مکمل طور پر دوبارہ تعمیر شدہ نفاذ ہے، جو فی الحال Go میں لکھا گیا ہے لیکن ترقی کے تحت دیگر زبانوں میں نفاذ کے ساتھ۔ Erigon کا مقصد ایتھیریم کا ایک تیز، زیادہ ماڈیولر، اور زیادہ بہتر نفاذ فراہم کرنا ہے۔ یہ 3 دن سے بھی کم وقت میں، تقریباً 2TB ڈسک کی جگہ کا استعمال کرتے ہوئے ایک فل آرکائیو نوڈ سنک انجام دے سکتا ہے۔ + +### Go Ethereum {#geth} + +Go Ethereum (مختصراً Geth) ایتھیریم پروٹوکول کے اصل نفاذ میں سے ایک ہے۔ فی الحال، یہ سب سے زیادہ وسیع کلائنٹ ہے جس میں سب سے بڑا صارف اڈہ اور صارفین اور ڈیولپرز کے لیے ٹولنگ کی مختلف قسمیں ہیں۔ یہ Go میں لکھا گیا ہے، مکمل طور پر اوپن سورس اور GNU LGPL v3 کے تحت لائسنس یافتہ ہے۔ + +Geth کے بارے میں اس کی [دستاویزات](https://geth.ethereum.org/docs/) میں مزید جانیں۔ + +### Nethermind {#nethermind} + +Nethermind C# .NET ٹیک اسٹیک کے ساتھ بنایا گیا ایک ایتھیریم نفاذ ہے، جو LGPL-3.0 کے ساتھ لائسنس یافتہ ہے، جو ARM سمیت تمام بڑے پلیٹ فارمز پر چلتا ہے۔ یہ بہترین کارکردگی پیش کرتا ہے: + +- ایک بہتر ورچوئل مشین +- اسٹیٹ تک رسائی +- نیٹ ورکنگ اور امیر خصوصیات جیسے Prometheus/Grafana ڈیش بورڈز، seq انٹرپرائز لاگنگ سپورٹ، JSON-RPC ٹریسنگ، اور تجزیاتی پلگ انز۔ + +Nethermind کے پاس [تفصیلی دستاویزات](https://docs.nethermind.io)، مضبوط ڈیولپر سپورٹ، ایک آن لائن کمیونٹی اور پریمیم صارفین کے لیے 24/7 سپورٹ بھی ہے۔ + +### Reth {#reth} + +Reth (Rust Ethereum کا مخفف) ایک ایتھیریم فل نوڈ نفاذ ہے جو صارف دوست، انتہائی ماڈیولر، تیز اور موثر ہونے پر مرکوز ہے۔ Reth کو اصل میں Paradigm نے بنایا اور آگے بڑھایا تھا، اور یہ اپاچی اور MIT لائسنس کے تحت لائسنس یافتہ ہے۔ + +Reth پروڈکشن کے لیے تیار ہے، اور مشن کے لیے اہم ماحول جیسے اسٹیکنگ یا ہائی-اپ ٹائم خدمات میں استعمال کے لیے موزوں ہے۔ ایسے استعمال کے معاملات میں اچھی کارکردگی کا مظاہرہ کرتا ہے جہاں اعلی کارکردگی کے ساتھ بہترین مارجن کی ضرورت ہوتی ہے جیسے RPC، MEV، انڈیکسنگ، سمیلیشنز، اور P2P سرگرمیاں۔ + +[Reth بک](https://reth.rs/)، یا [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) کو دیکھ کر مزید جانیں۔ + +### ترقی میں {#execution-in-development} + +یہ کلائنٹس ابھی بھی ترقی کے ابتدائی مراحل میں ہیں اور ابھی تک پروڈکشن کے استعمال کے لیے ان کی سفارش نہیں کی جاتی ہے۔ + +#### EthereumJS {#ethereumjs} + +EthereumJS ایگزیکیوشن کلائنٹ (EthereumJS) TypeScript میں لکھا گیا ہے اور متعدد پیکجز پر مشتمل ہے، بشمول بنیادی ایتھیریم پرائمیٹوز جن کی نمائندگی بلاک، ٹرانزیکشن، اور مرکل-پیٹریشیا ٹرائی کلاسز اور بنیادی کلائنٹ اجزاء کرتی ہیں جن میں ایتھیریم ورچوئل مشین (EVM)، ایک بلاک چین کلاس، اور DevP2P نیٹ ورکنگ اسٹیک کا نفاذ شامل ہے۔ + +اس کی [دستاویزات](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) پڑھ کر اس کے بارے میں مزید جانیں۔ + +## کنسینسس کلائنٹس {#consensus-clients} + +[کنسنسس اپ گریڈ](/roadmap/beacon-chain/) کی حمایت کے لیے متعدد کنسنسس کلائنٹس (پہلے 'Eth2' کلائنٹس کے نام سے جانا جاتا تھا) موجود ہیں۔ وہ تمام کنسنسس سے متعلق منطق کے ذمہ دار ہیں بشمول فورک-چوائس الگورتھم، تصدیقوں پر کارروائی اور [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos) انعامات اور جرمانے کا انتظام۔ + +| کلائنٹ | زبان | آپریٹنگ سسٹمز | نیٹورکس | +| ------------------------------------------------------------- | ---------- | --------------------- | ------------------------------------------------- | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | بیکن چین، ہوڈی، پیرمونٹ، سیپولیا، اور مزید | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | بیکن چین، ہوڈی، سیپولیا، اور مزید | +| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | بیکن چین، ہوڈی، سیپولیا، اور مزید | +| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux, Windows, macOS | بیکن چین، گنوسس، ہوڈی، پیرمونٹ، سیپولیا، اور مزید | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | بیکن چین، گنوسس، ہوڈی، سیپولیا، اور مزید | +| [Grandine](https://docs.grandine.io/) | Rust | Linux, Windows, macOS | بیکن چین، ہوڈی، سیپولیا، اور مزید | + +### Lighthouse {#lighthouse} + +Lighthouse اپاچی-2.0 لائسنس کے تحت Rust میں لکھا گیا ایک کنسنسس کلائنٹ نفاذ ہے۔ اسے سگما پرائم کے ذریعہ برقرار رکھا جاتا ہے اور بیکن چین جینیسس کے بعد سے مستحکم اور پروڈکشن کے لیے تیار ہے۔ اس پر مختلف کاروباری اداروں، اسٹیکنگ پولز اور افراد انحصار کرتے ہیں۔ اس کا مقصد ڈیسک ٹاپ پی سی سے لے کر جدید خودکار تعیناتیوں تک وسیع پیمانے پر ماحول میں محفوظ، کارکردگی اور باہمی تعاون کے قابل ہونا ہے۔ + +دستاویزات [لائٹ ہاؤس بک](https://lighthouse-book.sigmaprime.io/) میں مل سکتی ہیں۔ + +### Lodestar {#lodestar} + +Lodestar LGPL-3.0 لائسنس کے تحت Typescript میں لکھا گیا ایک پروڈکشن کے لیے تیار کنسنسس کلائنٹ نفاذ ہے۔ اسے چین سیف سسٹمز کے ذریعہ برقرار رکھا جاتا ہے اور یہ سولو-اسٹیکرز، ڈیولپرز اور محققین کے لیے جدید ترین کنسنسس کلائنٹس میں سے ہے۔ Lodestar ایک بیکن نوڈ اور ویلیڈیٹر کلائنٹ پر مشتمل ہے جو جاوا اسکرپٹ نفاذات ایتھیریم پروٹوکولز کے ذریعہ تقویت یافتہ ہے۔ Lodestar کا مقصد لائٹ کلائنٹس کے ساتھ ایتھیریم کے استعمال کو بہتر بنانا، ڈیولپرز کے ایک بڑے گروپ تک رسائی کو بڑھانا اور ایکو سسٹم کے تنوع میں مزید حصہ ڈالنا ہے۔ + +مزید معلومات [Lodestar ویب سائٹ](https://lodestar.chainsafe.io/) پر مل سکتی ہیں۔ + +### Nimbus {#nimbus} + +Nimbus اپاچی-2.0 لائسنس کے تحت Nim میں لکھا گیا ایک کنسنسس کلائنٹ نفاذ ہے۔ یہ سولو-اسٹیکرز اور اسٹیکنگ پولز کے ذریعہ استعمال میں ایک پروڈکشن کے لیے تیار کلائنٹ ہے۔ Nimbus کو وسائل کی کارکردگی کے لیے ڈیزائن کیا گیا ہے، جس سے اسے وسائل پر پابندی والے آلات اور انٹرپرائز انفراسٹرکچر پر یکساں آسانی کے ساتھ چلانا آسان ہوجاتا ہے، بغیر استحکام یا انعام کی کارکردگی پر سمجھوتہ کیے۔ ایک ہلکا وسائل کا نشان کا مطلب ہے کہ جب نیٹ ورک دباؤ میں ہو تو کلائنٹ کے پاس حفاظت کا ایک بڑا مارجن ہوتا ہے۔ + +[Nimbus دستاویزات](https://nimbus.guide/) میں مزید جانیں۔ + +### Prysm {#prysm} + +Prysm GPL-3.0 لائسنس کے تحت Go میں لکھا گیا ایک مکمل خصوصیات والا، اوپن سورس کنسنسس کلائنٹ ہے۔ اس میں ایک اختیاری ویب ایپ UI ہے اور یہ گھریلو اور ادارہ جاتی دونوں صارفین کے لیے صارف کے تجربے، دستاویزات، اور کنفیگریشن کو ترجیح دیتا ہے۔ + +مزید جاننے کے لیے [Prysm دستاویزات](https://prysm.offchainlabs.com/docs/) دیکھیں۔ + +### Teku {#teku} + +Teku اصل بیکن چین جینیسس کلائنٹس میں سے ایک ہے۔ معمول کے اہداف (سیکیورٹی، مضبوطی، استحکام، استعمال، کارکردگی) کے ساتھ، Teku خاص طور پر تمام مختلف کنسنسس کلائنٹ معیارات کی مکمل تعمیل کرنے کا ارادہ رکھتا ہے۔ + +Teku بہت لچکدار تعیناتی کے اختیارات پیش کرتا ہے۔ بیکن نوڈ اور ویلیڈیٹر کلائنٹ کو ایک ہی عمل کے طور پر ایک ساتھ چلایا جا سکتا ہے، جو سولو اسٹیکرز کے لیے انتہائی آسان ہے، یا جدید اسٹیکنگ آپریشنز کے لیے نوڈز کو الگ سے چلایا جا سکتا ہے۔ اس کے علاوہ، Teku سائننگ کلید کی سیکیورٹی اور سلیشنگ پروٹیکشن کے لیے [Web3Signer](https://github.com/ConsenSys/web3signer/) کے ساتھ مکمل طور پر باہمی تعاون کے قابل ہے۔ + +Teku جاوا میں لکھا گیا ہے اور یہ اپاچی 2.0 لائسنس یافتہ ہے۔ اسے ConsenSys کی پروٹوکولز ٹیم نے تیار کیا ہے جو Besu اور Web3Signer کے لیے بھی ذمہ دار ہے۔ [Teku دستاویزات](https://docs.teku.consensys.net/en/latest/) میں مزید جانیں۔ + +### Grandine {#grandine} + +Grandine GPL-3.0 لائسنس کے تحت Rust میں لکھا گیا ایک کنسنسس کلائنٹ نفاذ ہے۔ اسے گرینڈائن کور ٹیم کے ذریعہ برقرار رکھا جاتا ہے اور یہ تیز، اعلی کارکردگی اور ہلکا پھلکا ہے۔ یہ Raspberry Pi جیسے کم وسائل والے آلات پر چلنے والے سولو اسٹیکرز سے لے کر ہزاروں ویلیڈیٹرز چلانے والے بڑے ادارہ جاتی اسٹیکرز تک وسیع پیمانے پر اسٹیکرز کے لیے موزوں ہے۔ + +دستاویزات [Grandine بک](https://docs.grandine.io/) میں مل سکتی ہیں۔ + +## سنکرونائزیشن موڈز {#sync-modes} + +نیٹ ورک میں موجودہ ڈیٹا کی پیروی اور تصدیق کے لیے، ایتھیریم کلائنٹ کو تازہ ترین نیٹ ورک اسٹیٹ کے ساتھ سنک کرنے کی ضرورت ہے۔ یہ ہم مرتبہ افراد سے ڈیٹا ڈاؤن لوڈ کرکے، ان کی سالمیت کی خفیہ طور پر تصدیق کرکے، اور ایک مقامی بلاک چین ڈیٹا بیس بنا کر کیا جاتا ہے۔ + +سنکرونائزیشن موڈز مختلف تجارتی مفادات کے ساتھ اس عمل کے لیے مختلف طریقوں کی نمائندگی کرتے ہیں۔ کلائنٹس سنک الگورتھم کے نفاذ میں بھی مختلف ہوتے ہیں۔ نفاذ پر تفصیلات کے لیے ہمیشہ اپنے منتخب کردہ کلائنٹ کی سرکاری دستاویزات سے رجوع کریں۔ + +### ایگزیکیوشن لیئر سنک موڈز {#execution-layer-sync-modes} + +ایگزیکیوشن لیئر کو مختلف استعمال کے معاملات کے مطابق مختلف موڈز میں چلایا جا سکتا ہے، بلاک چین کی عالمی اسٹیٹ کو دوبارہ چلانے سے لے کر صرف ایک قابل اعتماد چیک پوائنٹ سے چین کی نوک کے ساتھ سنک کرنے تک۔ + +#### فل سنک {#full-sync} + +ایک فل سنک تمام بلاکس (بشمول ہیڈرز اور بلاک باڈیز) کو ڈاؤن لوڈ کرتا ہے اور جینیسس سے ہر بلاک کو چلا کر بلاک چین کی اسٹیٹ کو بتدریج دوبارہ بناتا ہے۔ + +- ہر ٹرانزیکشن کی تصدیق کرکے بھروسے کو کم کرتا ہے اور سب سے زیادہ سیکیورٹی پیش کرتا ہے۔ +- بڑھتی ہوئی ٹرانزیکشنز کی تعداد کے ساتھ، تمام ٹرانزیکشنز پر کارروائی کرنے میں دن سے ہفتے لگ سکتے ہیں۔ + +[آرکائیو نوڈز](#archive-node) ہر بلاک میں ہر ٹرانزیکشن کے ذریعہ کی گئی اسٹیٹ تبدیلیوں کی مکمل تاریخ بنانے (اور برقرار رکھنے) کے لیے ایک فل سنک انجام دیتے ہیں۔ + +#### فاسٹ سنک {#fast-sync} + +ایک فل سنک کی طرح، ایک فاسٹ سنک تمام بلاکس (بشمول ہیڈرز، ٹرانزیکشنز، اور رسیدیں) کو ڈاؤن لوڈ کرتا ہے۔ تاہم، تاریخی ٹرانزیکشنز کو دوبارہ پروسیس کرنے کے بجائے، ایک فاسٹ سنک رسیدوں پر انحصار کرتا ہے جب تک کہ یہ حالیہ ہیڈ تک نہ پہنچ جائے، جب یہ ایک فل نوڈ فراہم کرنے کے لیے بلاکس کو درآمد اور پروسیس کرنے میں بدل جاتا ہے۔ + +- فاسٹ سنک حکمت عملی۔ +- بینڈوڈتھ کے استعمال کے حق میں پروسیسنگ کی طلب کو کم کرتا ہے۔ + +#### سنیپ سنک {#snap-sync} + +سنیپ سنک بھی چین کی بلاک بہ بلاک تصدیق کرتے ہیں۔ تاہم، جینیسس بلاک سے شروع کرنے کے بجائے، ایک سنیپ سنک ایک حالیہ 'قابل اعتماد' چیک پوائنٹ سے شروع ہوتا ہے جو حقیقی بلاک چین کا حصہ سمجھا جاتا ہے۔ نوڈ ایک خاص عمر سے پرانے ڈیٹا کو حذف کرتے ہوئے متواتر چیک پوائنٹس کو محفوظ کرتا ہے۔ ان سنیپ شاٹس کا استعمال ضرورت کے مطابق اسٹیٹ ڈیٹا کو دوبارہ بنانے کے لیے کیا جاتا ہے، بجائے اس کے کہ اسے ہمیشہ کے لیے ذخیرہ کیا جائے۔ + +- سب سے تیز سنک حکمت عملی، فی الحال ایتھیریم مین نیٹ میں ڈیفالٹ ہے۔ +- سیکیورٹی کی قربانی کے بغیر بہت زیادہ ڈسک کے استعمال اور نیٹ ورک کی بینڈوڈتھ کو بچاتا ہے۔ + +[سنیپ سنک پر مزید](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)۔ + +#### لائٹ سنک {#light-sync} + +لائٹ کلائنٹ موڈ تمام بلاک ہیڈرز، بلاک ڈیٹا کو ڈاؤن لوڈ کرتا ہے، اور کچھ کی تصادفی طور پر تصدیق کرتا ہے۔ صرف قابل اعتماد چیک پوائنٹ سے چین کی نوک کو سنک کرتا ہے۔ + +- ڈیولپرز اور کنسنسس میکانزم پر بھروسہ کرتے ہوئے صرف تازہ ترین اسٹیٹ حاصل کرتا ہے۔ +- کلائنٹ چند منٹوں میں موجودہ نیٹ ورک اسٹیٹ کے ساتھ استعمال کے لیے تیار ہے۔ + +**NB** لائٹ سنک ابھی تک پروف آف اسٹیک ایتھیریم کے ساتھ کام نہیں کرتا - لائٹ سنک کے نئے ورژن جلد ہی بھیجے جانے چاہئیں! + +[لائٹ کلائنٹس پر مزید](/developers/docs/nodes-and-clients/light-clients/) + +### کنسنسس لیئر سنک موڈز {#consensus-layer-sync-modes} + +#### آپٹیمسٹک سنک {#optimistic-sync} + +آپٹیمسٹک سنک ایک پوسٹ مرج سنکرونائزیشن حکمت عملی ہے جسے آپٹ ان اور پسماندہ مطابقت کے لیے ڈیزائن کیا گیا ہے، جو ایگزیکیوشن نوڈز کو قائم شدہ طریقوں کے ذریعے سنک کرنے کی اجازت دیتا ہے۔ ایگزیکیوشن انجن _مثبت_ طور پر بیکن بلاکس کو مکمل طور پر تصدیق کیے بغیر درآمد کر سکتا ہے، تازہ ترین ہیڈ تلاش کر سکتا ہے، اور پھر مذکورہ بالا طریقوں سے چین کو سنک کرنا شروع کر سکتا ہے۔ پھر، ایگزیکیوشن کلائنٹ کے پکڑنے کے بعد، یہ کنسنسس کلائنٹ کو بیکن چین میں ٹرانزیکشنز کی صداقت سے آگاہ کرے گا۔ + +[آپٹیمسٹک سنک پر مزید](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) + +#### چیک پوائنٹ سنک {#checkpoint-sync} + +ایک چیک پوائنٹ سنک، جسے کمزور موضوعیت سنک بھی کہا جاتا ہے، بیکن نوڈ کو سنک کرنے کے لیے ایک اعلیٰ صارف کا تجربہ بناتا ہے۔ یہ [کمزور موضوعیت](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) کے مفروضوں پر مبنی ہے جو بیکن چین کو جینیسس کے بجائے حالیہ کمزور موضوعیت چیک پوائنٹ سے سنک کرنے کے قابل بناتا ہے۔ چیک پوائنٹ سنک [جینیسس](/glossary/#genesis-block) سے سنک کرنے جیسے ہی بھروسے کے مفروضوں کے ساتھ ابتدائی سنک کا وقت نمایاں طور پر تیز بناتے ہیں۔ + +عملی طور پر، اس کا مطلب ہے کہ آپ کا نوڈ حالیہ حتمی اسٹیٹس کو ڈاؤن لوڈ کرنے کے لیے ایک ریموٹ سروس سے جڑتا ہے اور اس مقام سے ڈیٹا کی تصدیق جاری رکھتا ہے۔ ڈیٹا فراہم کرنے والا تیسرا فریق قابل اعتماد ہے اور اسے احتیاط سے منتخب کیا جانا چاہئے۔ + +[چیک پوائنٹ سنک](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) پر مزید + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم 101 - حصہ 2 - نوڈز کو سمجھنا](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– ول بارنس، 13 فروری 2019_ +- [ایتھیریم فل نوڈز چلانا: بمشکل حوصلہ افزائی کے لیے ایک گائیڈ](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جسٹن لیروکس، 7 نومبر 2019_ + +## متعلقہ موضوعات {#related-topics} + +- [بلاکس](/developers/docs/blocks/) +- [نیٹ ورکس](/developers/docs/networks/) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [اپنے Raspberry Pi 4 کو صرف MicroSD کارڈ فلیش کرکے ایک ویلیڈیٹر نوڈ میں تبدیل کریں – انسٹالیشن گائیڈ](/developers/tutorials/run-node-raspberry-pi/) _– اپنے Raspberry Pi 4 کو فلیش کریں، ایک ایتھرنیٹ کیبل لگائیں، SSD ڈسک کو جوڑیں اور Raspberry Pi 4 کو ایگزیکیوشن لیئر (مین نیٹ) اور/یا کنسنسس لیئر (بیکن چین/ویلیڈیٹر) چلانے والے ایک فل ایتھیریم نوڈ میں تبدیل کرنے کے لیے ڈیوائس کو پاور اپ کریں۔_ diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/light-clients/index.md new file mode 100644 index 00000000000..9285a49e95d --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/light-clients/index.md @@ -0,0 +1,61 @@ +--- +title: "لائٹ کلائنٹس" +description: "Ethereum لائٹ کلائنٹس کا تعارف۔" +lang: ur-in +--- + +ایک مکمل نوڈ چلانا Ethereum کے ساتھ تعامل کرنے کا سب سے زیادہ ٹرس لیس، نجی، غیر مرکزی اور سنسر شپ مزاحم طریقہ ہے۔ ایک مکمل نوڈ کے ساتھ آپ بلاک چین کی اپنی کاپی رکھتے ہیں جسے آپ فوری طور پر دریافت کرسکتے ہیں اور آپ کو Ethereum کے پیئر ٹو پیئر نیٹ ورک تک براہ راست رسائی حاصل ہوتی ہے۔ تاہم، ایک مکمل نوڈ چلانے کے لیے کافی مقدار میں میموری، اسٹوریج اور CPU کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ ہر کسی کے لیے اپنا نوڈ چلانا ممکن نہیں ہے۔ Ethereum روڈ میپ پر اس کے کئی حل موجود ہیں، بشمول اسٹیٹ لیس نیس، لیکن ان کے نفاذ میں کئی سال باقی ہیں۔ قریب کی مدت میں اس کا جواب یہ ہے کہ ایک مکمل نوڈ چلانے کے کچھ فوائد کو بڑی کارکردگی میں بہتری کے لیے ٹریڈ آف کیا جائے جو نوڈز کو بہت کم ہارڈویئر ضروریات کے ساتھ چلانے کی اجازت دیتی ہیں۔ وہ نوڈز جو یہ ٹریڈ آف کرتے ہیں انہیں لائٹ نوڈز کے نام سے جانا جاتا ہے۔ + +## لائٹ کلائنٹ کیا ہے {#what-is-a-light-client} + +ایک لائٹ نوڈ ایک ایسا نوڈ ہے جو لائٹ کلائنٹ سافٹ ویئر چلاتا ہے۔ بلاک چین ڈیٹا کی مقامی کاپیاں رکھنے اور تمام تبدیلیوں کی آزادانہ طور پر تصدیق کرنے کے بجائے، وہ اس کے بجائے کسی فراہم کنندہ سے ضروری ڈیٹا کی درخواست کرتے ہیں۔ فراہم کنندہ ایک مکمل نوڈ سے براہ راست کنکشن یا کسی مرکزی RPC سرور کے ذریعے ہو سکتا ہے۔ اس کے بعد ڈیٹا کی تصدیق لائٹ نوڈ کے ذریعے کی جاتی ہے، جس سے وہ چین کے ہیڈ کے ساتھ اپ ٹو ڈیٹ رہ سکتا ہے۔ لائٹ نوڈ صرف بلاک ہیڈرز پر کارروائی کرتا ہے، صرف کبھی کبھار ہی اصل بلاک کے مواد کو ڈاؤن لوڈ کرتا ہے۔ نوڈز اپنے ہلکے پن میں مختلف ہو سکتے ہیں، یہ اس بات پر منحصر ہے کہ وہ لائٹ اور فل کلائنٹ سافٹ ویئر کے کن امتزاج کو چلاتے ہیں۔ مثال کے طور پر، سب سے ہلکی کنفیگریشن ایک لائٹ ایگزیکیوشن کلائنٹ اور ایک لائٹ کنسینسس کلائنٹ چلانا ہوگی۔ یہ بھی امکان ہے کہ بہت سے نوڈز مکمل ایگزیکیوشن کلائنٹس کے ساتھ لائٹ کنسینسس کلائنٹس، یا اس کے برعکس چلانے کا انتخاب کریں گے۔ + +## لائٹ کلائنٹس کیسے کام کرتے ہیں؟ {#how-do-light-clients-work} + +جب Ethereum نے پروف آف اسٹیک پر مبنی کنسینسس میکانزم کا استعمال شروع کیا، تو خاص طور پر لائٹ کلائنٹس کو سپورٹ کرنے کے لیے نیا انفراسٹرکچر متعارف کرایا گیا۔ یہ ہر 1.1 دن میں 512 ویلیڈیٹرز کے ایک سب سیٹ کو تصادفی طور پر منتخب کرکے کام کرتا ہے تاکہ وہ **سنک کمیٹی** کے طور پر کام کرے۔ سنک کمیٹی حالیہ بلاکس کے ہیڈر پر دستخط کرتی ہے۔ ہر بلاک ہیڈر میں سنک کمیٹی میں ویلیڈیٹرز کے مجموعی دستخط اور ایک "بٹ فیلڈ" ہوتا ہے جو یہ دکھاتا ہے کہ کن ویلیڈیٹرز نے دستخط کیے اور کن نے نہیں۔ ہر ہیڈر میں ان ویلیڈیٹرز کی فہرست بھی شامل ہوتی ہے جن سے اگلے بلاک پر دستخط کرنے میں حصہ لینے کی توقع کی جاتی ہے۔ اس کا مطلب ہے کہ ایک لائٹ کلائنٹ تیزی سے دیکھ سکتا ہے کہ سنک کمیٹی نے موصول ہونے والے ڈیٹا پر دستخط کردیے ہیں، اور وہ یہ بھی جانچ سکتا ہے کہ آیا سنک کمیٹی اصلی ہے یا نہیں، اس کا موازنہ اس سے کرکے جس کے بارے میں پچھلے بلاک میں توقع کرنے کے لیے کہا گیا تھا۔ اس طرح، لائٹ کلائنٹ اصل میں بلاک کو ڈاؤن لوڈ کیے بغیر، صرف ہیڈر جس میں خلاصہ معلومات ہوتی ہیں، کے ذریعے تازہ ترین Ethereum بلاک کے بارے میں اپنے علم کو اپ ڈیٹ کرتا رہ سکتا ہے۔ + +ایگزیکیوشن لیئر پر لائٹ ایگزیکیوشن کلائنٹ کے لیے کوئی واحد تفصیلات موجود نہیں ہے۔ ایک لائٹ ایگزیکیوشن کلائنٹ کا دائرہ کار ایک مکمل ایگزیکیوشن کلائنٹ کے "لائٹ موڈ" سے مختلف ہو سکتا ہے جس میں ایک مکمل نوڈ کی تمام EVM اور نیٹ ورکنگ کی فعالیت ہوتی ہے لیکن وہ صرف بلاک ہیڈرز کی تصدیق کرتا ہے، اور متعلقہ ڈیٹا کو ڈاؤن لوڈ نہیں کرتا، یا یہ ایک زیادہ سٹرپڈ ڈاؤن کلائنٹ ہو سکتا ہے جو Ethereum کے ساتھ تعامل کرنے کے لیے RPC فراہم کنندہ کو درخواستیں بھیجنے پر بہت زیادہ انحصار کرتا ہے۔ + +## لائٹ کلائنٹس کیوں اہم ہیں؟ {#why-are-light-clients-important} + +لائٹ کلائنٹس اس لیے اہم ہیں کیونکہ وہ صارفین کو آنے والے ڈیٹا کی تصدیق کرنے کی اجازت دیتے ہیں بجائے اس کے کہ وہ آنکھ بند کرکے بھروسہ کریں کہ ان کا ڈیٹا فراہم کنندہ صحیح اور ایماندار ہے، جبکہ ایک مکمل نوڈ کے حسابی وسائل کا صرف ایک چھوٹا سا حصہ استعمال کرتے ہیں۔ لائٹ کلائنٹس کو موصول ہونے والے ڈیٹا کو ان بلاک ہیڈرز کے خلاف چیک کیا جا سکتا ہے جن کے بارے میں وہ جانتے ہیں کہ ان پر 512 Ethereum ویلیڈیٹرز کے بے ترتیب سیٹ کے کم از کم 2/3 نے دستخط کیے ہیں۔ یہ اس بات کا بہت مضبوط ثبوت ہے کہ ڈیٹا درست ہے۔ + +لائٹ کلائنٹ صرف بہت کم کمپیوٹنگ پاور، میموری اور اسٹوریج کا استعمال کرتا ہے اس لیے اسے موبائل فون پر چلایا جا سکتا ہے، کسی ایپ میں ایمبیڈ کیا جا سکتا ہے یا براؤزر کے حصے کے طور پر استعمال کیا جا سکتا ہے۔ لائٹ کلائنٹس Ethereum تک ٹرسٹ منیمائزڈ رسائی کو اتنا ہی آسان بنانے کا ایک طریقہ ہیں جتنا کسی تیسرے فریق فراہم کنندہ پر بھروسہ کرنا۔ + +آئیے ایک سادہ مثال لیتے ہیں۔ تصور کریں کہ آپ اپنے اکاؤنٹ کا بیلنس چیک کرنا چاہتے ہیں۔ ایسا کرنے کے لیے آپ کو Ethereum نوڈ سے درخواست کرنی ہوگی۔ وہ نوڈ آپ کے بیلنس کے لیے Ethereum اسٹیٹ کی اپنی مقامی کاپی کو چیک کرے گا اور اسے آپ کو واپس کر دے گا۔ اگر آپ کو کسی نوڈ تک براہ راست رسائی نہیں ہے، تو مرکزی آپریٹرز ہیں جو اس ڈیٹا کو بطور سروس فراہم کرتے ہیں۔ آپ انہیں ایک درخواست بھیج سکتے ہیں، وہ اپنے نوڈ کو چیک کرتے ہیں، اور نتیجہ آپ کو واپس بھیجتے ہیں۔ اس میں مسئلہ یہ ہے کہ پھر آپ کو فراہم کنندہ پر بھروسہ کرنا پڑتا ہے کہ وہ آپ کو صحیح معلومات دے رہا ہے۔ اگر آپ خود اس کی تصدیق نہیں کر سکتے تو آپ کبھی بھی واقعی یہ نہیں جان سکتے کہ معلومات درست ہے۔ + +ایک لائٹ کلائنٹ اس مسئلے کو حل کرتا ہے۔ آپ اب بھی کسی بیرونی فراہم کنندہ سے ڈیٹا کی درخواست کرتے ہیں، لیکن جب آپ کو ڈیٹا واپس ملتا ہے تو یہ ایک ثبوت کے ساتھ آتا ہے جسے آپ کا لائٹ نوڈ بلاک ہیڈر میں موصول ہونے والی معلومات کے خلاف چیک کر سکتا ہے۔ اس کا مطلب ہے کہ کسی بھروسہ مند آپریٹر کے بجائے Ethereum آپ کے ڈیٹا کی درستگی کی تصدیق کر رہا ہے۔ + +## لائٹ کلائنٹس کن اختراعات کو ممکن بناتے ہیں؟ {#what-innovations-do-light-clients-enable} + +لائٹ کلائنٹس کا بنیادی فائدہ یہ ہے کہ وہ زیادہ لوگوں کو نہ ہونے کے برابر ہارڈویئر کی ضروریات اور تیسرے فریق پر کم سے کم انحصار کے ساتھ آزادانہ طور پر Ethereum تک رسائی حاصل کرنے کے قابل بناتے ہیں۔ یہ صارفین کے لیے اچھا ہے کیونکہ وہ اپنے ڈیٹا کی خود تصدیق کر سکتے ہیں اور یہ نیٹ ورک کے لیے بھی اچھا ہے کیونکہ یہ ان نوڈز کی تعداد اور تنوع کو بڑھاتا ہے جو چین کی تصدیق کر رہے ہیں۔ + +بہت کم اسٹوریج، میموری اور پروسیسنگ پاور والے آلات پر Ethereum نوڈز چلانے کی صلاحیت لائٹ کلائنٹس کے ذریعے ممکن ہونے والے اختراع کے بڑے شعبوں میں سے ایک ہے۔ جبکہ آج Ethereum نوڈز کو بہت زیادہ کمپیوٹنگ وسائل کی ضرورت ہوتی ہے، لائٹ کلائنٹس کو براؤزرز میں ایمبیڈ کیا جا سکتا ہے، موبائل فونز پر چلایا جا سکتا ہے اور شاید اسمارٹ واچز جیسے چھوٹے آلات پر بھی۔ اس کا مطلب ہے کہ ایمبیڈڈ کلائنٹس والے Ethereum والیٹس موبائل فون پر چل سکتے ہیں۔ اس کا مطلب یہ ہے کہ موبائل والیٹس زیادہ غیر مرکزی ہو سکتے ہیں کیونکہ انہیں اپنے ڈیٹا کے لیے مرکزی ڈیٹا فراہم کنندگان پر بھروسہ نہیں کرنا پڑے گا۔ + +اس کی ایک توسیع **انٹرنیٹ آف تھنگز (IoT)** آلات کو فعال کرنا ہے۔ ایک لائٹ کلائنٹ کو کسی ٹوکن بیلنس یا NFT کی ملکیت کو تیزی سے ثابت کرنے کے لیے استعمال کیا جا سکتا ہے، سنک کمیٹیوں کی طرف سے فراہم کردہ تمام سیکیورٹی گارنٹیوں کے ساتھ، جو ایک IoT نیٹ ورک پر کسی عمل کو متحرک کرتا ہے۔ ایک [سائیکل کرائے کی سروس](https://youtu.be/ZHNrAXf3RDE?t=929) کا تصور کریں جو ایک ایمبیڈڈ لائٹ کلائنٹ والی ایپ کا استعمال کرتی ہے تاکہ یہ تیزی سے تصدیق کی جا سکے کہ آپ رینٹل سروس کے NFT کے مالک ہیں اور اگر ایسا ہے تو، آپ کے لیے سواری کرنے کے لیے ایک سائیکل ان لاک کر دیتی ہے! + +Ethereum رول اپس کو بھی لائٹ کلائنٹس سے فائدہ ہوگا۔ رول اپس کے لیے ایک بڑا مسئلہ ان برجز کو نشانہ بنانے والے ہیکس رہے ہیں جو فنڈز کو Ethereum Mainnet سے رول اپ میں منتقل کرنے کی اجازت دیتے ہیں۔ ایک کمزوری وہ اوریکلز ہیں جن کا استعمال رول اپس یہ پتہ لگانے کے لیے کرتے ہیں کہ کسی صارف نے برج میں رقم جمع کرائی ہے۔ اگر کوئی اوریکل غلط ڈیٹا فیڈ کرتا ہے، تو وہ رول اپ کو یہ سوچنے پر مجبور کر سکتا ہے کہ برج میں رقم جمع ہوئی تھی اور وہ غلط طریقے سے فنڈز جاری کر سکتا ہے۔ رول اپ میں ایمبیڈڈ ایک لائٹ کلائنٹ کو کرپٹڈ اوریکلز سے بچانے کے لیے استعمال کیا جا سکتا ہے کیونکہ برج میں جمع کرائی گئی رقم ایک ثبوت کے ساتھ آسکتی ہے جس کی تصدیق رول اپ کے ذریعے کوئی بھی ٹوکن جاری کرنے سے پہلے کی جا سکتی ہے۔ یہی تصور دوسرے انٹرچین برجز پر بھی لاگو کیا جا سکتا ہے۔ + +لائٹ کلائنٹس کو Ethereum والیٹس کو اپ گریڈ کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔ RPC فراہم کنندہ سے فراہم کردہ ڈیٹا پر بھروسہ کرنے کے بجائے، آپ کا والیٹ ایک ایمبیڈڈ لائٹ کلائنٹ کا استعمال کرتے ہوئے آپ کو پیش کیے جانے والے ڈیٹا کی براہ راست تصدیق کر سکتا ہے۔ اس سے آپ کے والیٹ کی سیکیورٹی میں اضافہ ہوگا۔ اگر آپ کا RPC فراہم کنندہ بے ایمان تھا اور اس نے آپ کو غلط ڈیٹا فراہم کیا، تو ایمبیڈڈ لائٹ کلائنٹ آپ کو بتا سکتا ہے! + +## لائٹ کلائنٹ کی ترقی کی موجودہ حالت کیا ہے؟ {#current-state-of-development} + +کئی لائٹ کلائنٹس ترقی کے مراحل میں ہیں، جن میں ایگزیکیوشن، کنسینسس اور مشترکہ ایگزیکیوشن/کنسینسس لائٹ کلائنٹس شامل ہیں۔ یہ وہ لائٹ کلائنٹ نفاذات ہیں جن کے بارے میں ہم اس صفحہ کو لکھنے کے وقت جانتے ہیں: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): TypeScript میں کنسینسس لائٹ کلائنٹ +- [Helios](https://github.com/a16z/helios): Rust میں مشترکہ ایگزیکیوشن اور کنسینسس لائٹ کلائنٹ +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): Go میں ایگزیکیوشن کلائنٹ کے لیے لائٹ موڈ (زیرِ ترقی) +- [Nimbus](https://nimbus.guide/el-light-client.html): Nim میں کنسینسس لائٹ کلائنٹ + +ہمارے علم کے مطابق ان میں سے کوئی بھی ابھی تک پروڈکشن کے لیے تیار نہیں سمجھا جاتا ہے۔ + +ان طریقوں کو بہتر بنانے کے لیے بھی بہت کام کیا جا رہا ہے جن سے لائٹ کلائنٹس Ethereum ڈیٹا تک رسائی حاصل کر سکتے ہیں۔ فی الحال، لائٹ کلائنٹس کلائنٹ/سرور ماڈل کا استعمال کرتے ہوئے مکمل نوڈز کو RPC درخواستوں پر انحصار کرتے ہیں، لیکن مستقبل میں [Portal Network](https://www.ethportal.net/) جیسے ایک وقف شدہ نیٹ ورک کا استعمال کرتے ہوئے ڈیٹا کی درخواست زیادہ غیر مرکزی طریقے سے کی جا سکتی ہے، جو پیئر-ٹو-پیئر گوسپ پروٹوکول کا استعمال کرتے ہوئے لائٹ کلائنٹس کو ڈیٹا فراہم کر سکتا ہے۔ + +دیگر [روڈ میپ](/roadmap/) آئٹمز جیسے [Verkle trees](/roadmap/verkle-trees/) اور [اسٹیٹ لیس نیس](/roadmap/statelessness/) بالآخر لائٹ کلائنٹس کی سیکیورٹی گارنٹیوں کو مکمل کلائنٹس کے برابر لے آئیں گے۔ + +## مزید پڑھیں {#further-reading} + +- [Geth لائٹ کلائنٹس پر Zsolt Felfodhi](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [لائٹ کلائنٹ نیٹ ورکنگ پر Etan Kissling](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [The Merge کے بعد لائٹ کلائنٹس پر Etan Kissling](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Piper Merriam: فنکشنل لائٹ کلائنٹس کی طرف پیچیدہ راستہ](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/node-architecture/index.md new file mode 100644 index 00000000000..89267dcb3b7 --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/node-architecture/index.md @@ -0,0 +1,59 @@ +--- +title: "نوڈ کا فن تعمیر" +description: "ایتھیریم نوڈز کو کیسے منظم کیا جاتا ہے اس کا تعارف۔" +lang: ur-in +--- + +ایک ایتھیریم نوڈ دو کلائنٹس پر مشتمل ہوتا ہے: ایک [ایگزیکیوشن کلائنٹ](/developers/docs/nodes-and-clients/#execution-clients) اور ایک [کنسینسس کلائنٹ](/developers/docs/nodes-and-clients/#consensus-clients)۔ ایک نوڈ کو نیا بلاک تجویز کرنے کے لیے، اسے ایک [ویلیڈیٹر کلائنٹ](#validators) بھی چلانا ہوگا۔ + +جب ایتھیریم [پروف-آف-ورک](/developers/docs/consensus-mechanisms/pow/) استعمال کر رہا تھا، تو ایک مکمل ایتھیریم نوڈ چلانے کے لیے ایک ایگزیکیوشن کلائنٹ کافی تھا۔ تاہم، [پروف-آف-اسٹیک](/developers/docs/consensus-mechanisms/pow/) کو نافذ کرنے کے بعد سے، ایگزیکیوشن کلائنٹ کو ایک دوسرے سافٹ ویئر کے ساتھ استعمال کیا جانا چاہیے جسے [کنسینسس کلائنٹ](/developers/docs/nodes-and-clients/#consensus-clients) کہا جاتا ہے۔ + +نیچے دیا گیا ڈایاگرام دو ایتھیریم کلائنٹس کے درمیان تعلق کو ظاہر کرتا ہے۔ دونوں کلائنٹس اپنے اپنے پیئر-ٹو-پیئر (P2P) نیٹ ورکس سے جڑتے ہیں۔ الگ الگ P2P نیٹ ورکس کی ضرورت ہے کیونکہ ایگزیکیوشن کلائنٹس اپنے P2P نیٹ ورک پر ٹرانزیکشنز کو براڈکاسٹ کرتے ہیں، جس سے وہ اپنے مقامی ٹرانزیکشن پول کو منظم کر سکتے ہیں، جبکہ کنسینسس کلائنٹس اپنے P2P نیٹ ورک پر بلاکس کو براڈکاسٹ کرتے ہیں، جس سے کنسینسس اور چین کی ترقی ممکن ہوتی ہے۔ + +![](node-architecture-text-background.png) + +_ایگزیکیوشن کلائنٹ کے لیے کئی آپشنز ہیں جن میں Erigon، Nethermind اور Besu شامل ہیں_۔ + +اس دو-کلائنٹ ساخت کے کام کرنے کے لیے، کنسینسس کلائنٹس کو ایگزیکیوشن کلائنٹ کو ٹرانزیکشنز کے بنڈل بھیجنے چاہئیں۔ ایگزیکیوشن کلائنٹ مقامی طور پر ٹرانزیکشنز کو ایگزیکیوٹ کرتا ہے تاکہ اس بات کی توثیق کی جا سکے کہ ٹرانزیکشنز ایتھیریم کے کسی اصول کی خلاف ورزی نہیں کرتے ہیں اور ایتھیریم کی اسٹیٹ میں مجوزہ اپ ڈیٹ درست ہے۔ جب کسی نوڈ کو بلاک پروڈیوسر کے طور پر منتخب کیا جاتا ہے تو اس کا کنسینسس کلائنٹ انسٹینس ایگزیکیوشن کلائنٹ سے نئے بلاک میں شامل کرنے اور عالمی اسٹیٹ کو اپ ڈیٹ کرنے کے لیے ٹرانزیکشنز کے بنڈلز کی درخواست کرتا ہے۔ کنسینسس کلائنٹ [انجن API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) کا استعمال کرتے ہوئے مقامی RPC کنکشن کے ذریعے ایگزیکیوشن کلائنٹ کو چلاتا ہے۔ + +## ایگزیکیوشن کلائنٹ کیا کرتا ہے؟ {#execution-client} + +ایگزیکیوشن کلائنٹ ٹرانزیکشن کی توثیق، ہینڈلنگ، اور براڈکاسٹنگ کے ساتھ ساتھ اسٹیٹ مینجمنٹ اور ایتھیریم ورچوئل مشین ([EVM](/developers/docs/evm/)) کو سپورٹ کرنے کا ذمہ دار ہے۔ یہ بلاک بنانے، بلاک کی براڈکاسٹنگ یا کنسینسس منطق کو سنبھالنے کا ذمہ دار **نہیں** ہے۔ یہ کنسینسس کلائنٹ کے دائرہ کار میں ہیں۔ + +ایگزیکیوشن کلائنٹ ایگزیکیوشن پے لوڈز بناتا ہے - ٹرانزیکشنز کی فہرست، اپ ڈیٹ شدہ اسٹیٹ ٹرائی، اور ایگزیکیوشن سے متعلق دیگر ڈیٹا۔ کنسینسس کلائنٹس ہر بلاک میں ایگزیکیوشن پے لوڈ شامل کرتے ہیں۔ ایگزیکیوشن کلائنٹ نئے بلاکس میں ٹرانزیکشنز کو دوبارہ ایگزیکیوٹ کرنے کا بھی ذمہ دار ہے تاکہ یہ یقینی بنایا جا سکے کہ وہ درست ہیں۔ ٹرانزیکشنز کو ایگزیکیوشن کلائنٹ کے ایمبیڈڈ کمپیوٹر پر ایگزیکیوٹ کیا جاتا ہے، جسے [ایتھیریم ورچوئل مشین (EVM)](/developers/docs/evm) کے نام سے جانا جاتا ہے۔ + +ایگزیکیوشن کلائنٹ [RPC طریقوں](/developers/docs/apis/json-rpc) کے ذریعے ایتھیریم کو ایک یوزر انٹرفیس بھی پیش کرتا ہے جو صارفین کو ایتھیریم بلاک چین سے استفسار کرنے، ٹرانزیکشنز جمع کرنے اور اسمارٹ کنٹریکٹس کو تعینات کرنے کے قابل بناتا ہے۔ یہ عام ہے کہ RPC کالز کو [Web3js](https://docs.web3js.org/)، [Web3py](https://web3py.readthedocs.io/en/v5/) جیسی لائبریری، یا براؤزر والیٹ جیسے یوزر انٹرفیس کے ذریعے ہینڈل کیا جائے۔ + +خلاصہ یہ ہے کہ، ایگزیکیوشن کلائنٹ ہے: + +- ایتھیریم کا ایک یوزر گیٹ وے +- ایتھیریم ورچوئل مشین، ایتھیریم کی اسٹیٹ اور ٹرانزیکشن پول کا گھر۔ + +## کنسینسس کلائنٹ کیا کرتا ہے؟ {#consensus-client} + +کنسینسس کلائنٹ اس تمام منطق کو سنبھالتا ہے جو ایک نوڈ کو ایتھیریم نیٹ ورک کے ساتھ مطابقت پذیر رہنے کے قابل بناتی ہے۔ اس میں ساتھیوں سے بلاکس وصول کرنا اور ایک فورک چوائس الگورتھم چلانا شامل ہے تاکہ یہ یقینی بنایا جا سکے کہ نوڈ ہمیشہ اس چین کی پیروی کرتا ہے جس میں تصدیقوں کا سب سے زیادہ جمع ہو (ویلیڈیٹر کے موثر بیلنس کے حساب سے وزنی)۔ ایگزیکیوشن کلائنٹ کی طرح، کنسینسس کلائنٹس کا اپنا P2P نیٹ ورک ہوتا ہے جس کے ذریعے وہ بلاکس اور تصدیقیں شیئر کرتے ہیں۔ + +کنسینسس کلائنٹ بلاکس کی تصدیق کرنے یا تجویز کرنے میں حصہ نہیں لیتا - یہ کام ایک ویلیڈیٹر کے ذریعے کیا جاتا ہے، جو کنسینسس کلائنٹ کا ایک اختیاری ایڈ-آن ہے۔ ایک ویلیڈیٹر کے بغیر کنسینسس کلائنٹ صرف چین کے ہیڈ کے ساتھ مطابقت رکھتا ہے، جس سے نوڈ مطابقت پذیر رہتا ہے۔ یہ ایک صارف کو اپنے ایگزیکیوشن کلائنٹ کا استعمال کرتے ہوئے ایتھیریم کے ساتھ لین دین کرنے کے قابل بناتا ہے، اس یقین کے ساتھ کہ وہ صحیح چین پر ہیں۔ + +## ویلیڈیٹرز {#validators} + +اسٹیکنگ اور ویلیڈیٹر سافٹ ویئر چلانے سے ایک نوڈ نیا بلاک تجویز کرنے کے لیے منتخب ہونے کا اہل بن جاتا ہے۔ نوڈ آپریٹرز ڈیپازٹ کنٹریکٹ میں 32 ETH جمع کر کے اپنے کنسینسس کلائنٹس میں ایک ویلیڈیٹر شامل کر سکتے ہیں۔ ویلیڈیٹر کلائنٹ کنسینسس کلائنٹ کے ساتھ بنڈل میں آتا ہے اور اسے کسی بھی وقت نوڈ میں شامل کیا جا سکتا ہے۔ ویلیڈیٹر تصدیقوں اور بلاک کی تجاویز کو سنبھالتا ہے۔ یہ ایک نوڈ کو جرمانے یا سلیشنگ کے ذریعے انعامات حاصل کرنے یا ETH کھونے کے قابل بھی بناتا ہے۔ + +[اسٹیکنگ کے بارے میں مزید](/staking/)۔ + +## ایک نوڈ کے اجزاء کا موازنہ {#node-comparison} + +| ایگزیکیوشن کلائنٹ | کنسینسس کلائنٹ | ویلیڈیٹر | +| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------- | +| اپنے P2P نیٹ ورک پر ٹرانزیکشنز کو براڈکاسٹ کرتا ہے | اپنے P2P نیٹ ورک پر بلاکس اور تصدیقوں کو براڈکاسٹ کرتا ہے | بلاکس تجویز کرتا ہے | +| ٹرانزیکشنز کو ایگزیکیوٹ/دوبارہ ایگزیکیوٹ کرتا ہے | فورک چوائس الگورتھم چلاتا ہے | انعامات/جرمانے حاصل کرتا ہے | +| آنے والی اسٹیٹ تبدیلیوں کی تصدیق کرتا ہے | چین کے ہیڈ کا ٹریک رکھتا ہے | تصدیقیں کرتا ہے | +| اسٹیٹ اور رسیدوں کی ٹرائی کو منظم کرتا ہے | بیکن اسٹیٹ کو منظم کرتا ہے (جس میں کنسینسس اور ایگزیکیوشن کی معلومات ہوتی ہیں) | 32 ETH اسٹیک کرنے کی ضرورت ہوتی ہے | +| ایگزیکیوشن پے لوڈ بناتا ہے | RANDAO میں جمع شدہ بے ترتیبی کا ٹریک رکھتا ہے (ایک الگورتھم جو ویلیڈیٹر کے انتخاب اور دیگر کنسینسس آپریشنز کے لیے قابل تصدیق بے ترتیبی فراہم کرتا ہے) | سلیش کیا جا سکتا ہے | +| ایتھیریم کے ساتھ تعامل کے لیے JSON-RPC API کو ظاہر کرتا ہے | جواز اور حتمی شکل کا ٹریک رکھتا ہے | | + +## مزید پڑھیں {#further-reading} + +- [پروف-آف-اسٹیک](/developers/docs/consensus-mechanisms/pos) +- [بلاک کی تجویز](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [ویلیڈیٹر کے انعامات اور جرمانے](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/nodes-as-a-service/index.md new file mode 100644 index 00000000000..29c0111f19a --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -0,0 +1,418 @@ +--- +title: "نوڈز بطور سروس" +description: "نوڈ سروسز، ان کے فوائد و نقصانات، اور مقبول فراہم کنندگان کا ایک ابتدائی سطح کا جائزہ۔" +lang: ur-in +sidebarDepth: 2 +--- + +## تعارف {#Introduction} + +اپنا [Ethereum نوڈ](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) چلانا مشکل ہو سکتا ہے، خاص طور پر جب آپ شروعات کر رہے ہوں یا تیزی سے اسکیلنگ کر رہے ہوں۔ [کئی سروسز](#popular-node-services) ہیں جو آپ کے لیے آپٹمائزڈ نوڈ انفراسٹرکچر چلاتی ہیں، تاکہ آپ اس کے بجائے اپنی ایپلیکیشن یا پروڈکٹ تیار کرنے پر توجہ مرکوز کر سکیں۔ ہم وضاحت کریں گے کہ نوڈ سروسز کیسے کام کرتی ہیں، ان کے استعمال کے فوائد و نقصانات کیا ہیں اور اگر آپ شروعات کرنے میں دلچسپی رکھتے ہیں تو فراہم کنندگان کی فہرست بھی دیں گے۔ + +## شرائط {#prerequisites} + +اگر آپ کو پہلے سے یہ سمجھ نہیں ہے کہ نوڈز اور کلائنٹس کیا ہیں، تو [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) دیکھیں۔ + +## اسٹیکرز {#stakoooooooooooooors} + +سولو اسٹیکرز کو تھرڈ پارٹی فراہم کنندگان پر انحصار کرنے کے بجائے اپنا انفراسٹرکچر خود چلانا چاہیے۔ اس کا مطلب ہے ایک ایگزیکیوشن کلائنٹ کو کنسینسس کلائنٹ کے ساتھ ملا کر چلانا۔ [The Merge](/roadmap/merge) سے پہلے، صرف ایک کنسینسس کلائنٹ چلانا اور ایگزیکیوشن ڈیٹا کے لیے ایک مرکزی فراہم کنندہ کا استعمال کرنا ممکن تھا؛ اب یہ ممکن نہیں ہے - ایک سولو اسٹیکر کو دونوں کلائنٹس چلانے چاہئیں۔ تاہم، اس عمل کو آسان بنانے کے لیے سروسز دستیاب ہیں۔ + +[نوڈ چلانے کے بارے میں مزید پڑھیں](/developers/docs/nodes-and-clients/run-a-node/)۔ + +اس صفحے پر بیان کردہ سروسز نان-اسٹیکنگ نوڈز کے لیے ہیں۔ + +## نوڈ سروسز کیسے کام کرتی ہیں؟ {#how-do-node-services-work} + +نوڈ سروس فراہم کنندگان آپ کے لیے پس پردہ ڈسٹری بیوٹڈ نوڈ کلائنٹس چلاتے ہیں، لہذا آپ کو ایسا کرنے کی ضرورت نہیں ہے۔ + +یہ سروسز عام طور پر ایک API کی (key) فراہم کرتی ہیں جسے آپ بلاک چین پر لکھنے اور پڑھنے کے لیے استعمال کر سکتے ہیں۔ ان میں اکثر مین نیٹ (Mainnet) کے علاوہ [Ethereum ٹیسٹ نیٹس](/developers/docs/networks/#ethereum-testnets) تک رسائی بھی شامل ہوتی ہے۔ + +کچھ سروسز آپ کو اپنا وقف شدہ نوڈ پیش کرتی ہیں جسے وہ آپ کے لیے منظم کرتے ہیں، جبکہ دیگر نوڈز پر سرگرمی تقسیم کرنے کے لیے لوڈ بیلنسر استعمال کرتے ہیں۔ + +تقریباً تمام نوڈ سروسز کو انٹیگریٹ کرنا انتہائی آسان ہے، جس میں آپ کے خود میزبان نوڈ کو تبدیل کرنے، یا خود سروسز کے درمیان سوئچ کرنے کے لیے آپ کے کوڈ میں ایک لائن کی تبدیلیاں شامل ہیں۔ + +اکثر نوڈ سروسز مختلف قسم کے [نوڈ کلائنٹس](/developers/docs/nodes-and-clients/#execution-clients) اور [اقسام](/developers/docs/nodes-and-clients/#node-types) چلائیں گی، جس سے آپ کو ایک API میں کلائنٹ کے مخصوص طریقوں کے علاوہ مکمل اور آرکائیو نوڈز تک رسائی حاصل ہو گی۔ + +یہ نوٹ کرنا ضروری ہے کہ نوڈ سروسز آپ کی نجی کیز (private keys) یا معلومات کو اسٹور نہیں کرتی ہیں اور نہ ہی انہیں کرنا چاہیے۔ + +## نوڈ سروس استعمال کرنے کے کیا فوائد ہیں؟ {#benefits-of-using-a-node-service} + +نوڈ سروس استعمال کرنے کا بنیادی فائدہ یہ ہے کہ آپ کو خود نوڈز کو برقرار رکھنے اور ان کا انتظام کرنے میں انجینئرنگ کا وقت صرف نہیں کرنا پڑتا۔ یہ آپ کو انفراسٹرکچر کی دیکھ بھال کی فکر کرنے کے بجائے اپنی پروڈکٹ بنانے پر توجہ مرکوز کرنے کی اجازت دیتا ہے۔ + +اپنے نوڈز چلانا اسٹوریج سے لے کر بینڈوتھ اور قیمتی انجینئرنگ وقت تک بہت مہنگا ہو سکتا ہے۔ اسکیلنگ کے وقت مزید نوڈز کو اسپن اپ کرنا، نوڈز کو تازہ ترین ورژنز میں اپ گریڈ کرنا، اور اسٹیٹ کی ہم آہنگی (consistency) کو یقینی بنانا جیسی چیزیں آپ کو اپنی مطلوبہ web3 پروڈکٹ بنانے اور اس پر وسائل خرچ کرنے سے ہٹا سکتی ہیں۔ + +## نوڈ سروس استعمال کرنے کے کیا نقصانات ہیں؟ {#cons-of-using-a-node-service} + +نوڈ سروس کا استعمال کرکے آپ اپنی پروڈکٹ کے انفراسٹرکچر کے پہلو کو مرکزی بنا رہے ہیں۔ اسی وجہ سے، وہ پروجیکٹس جو ڈی سینٹرلائزیشن کو انتہائی اہمیت دیتے ہیں، وہ تھرڈ پارٹی کو آؤٹ سورس کرنے کے بجائے نوڈز کو خود ہوسٹ کرنے کو ترجیح دے سکتے ہیں۔ + +اپنا نوڈ چلانے کے [فوائد کے بارے میں مزید پڑھیں](/developers/docs/nodes-and-clients/#benefits-to-you)۔ + +## مقبول نوڈ سروسز {#popular-node-services} + +یہاں کچھ سب سے مقبول Ethereum نوڈ فراہم کنندگان کی فہرست ہے، اگر کوئی چھوٹ گیا ہو تو بلا جھجھک شامل کریں! ہر نوڈ سروس مفت یا بامعاوضہ ٹائرز کے علاوہ مختلف فوائد اور خصوصیات پیش کرتی ہے، آپ کو فیصلہ کرنے سے پہلے یہ تحقیق کرنی چاہیے کہ کونسی سروس آپ کی ضروریات کے لیے بہترین ہے۔ + +- [**Alchemy**](https://alchemy.com/) + - [Docs](https://www.alchemy.com/docs/) + - خصوصیات + - سب سے بڑا مفت ٹائیر جس میں 300M کمپیوٹ یونٹس فی مہینہ (تقریباً 30M getLatestBlock درخواستیں)۔ + - Polygon, Starknet, Optimism, Arbitrum کے لیے ملٹی چین سپورٹ۔ + - سب سے بڑی Ethereum dapps اور DeFi ٹرانزیکشن حجم کا تقریباً 70% کو پاور کرنا۔ + - Alchemy Notify کے ذریعے ریئل ٹائم ویب ہک الرٹس۔ + - بہترین سپورٹ اور قابل اعتمادی / استحکام۔ + - Alchemy کی NFT API + - درخواست ایکسپلورر، Mempool واچر، اور کمپوزر کے ساتھ ڈیش بورڈ۔ + - انٹیگریٹڈ ٹیسٹ نیٹ فاوسیٹ (faucet) تک رسائی۔ + - 18 ہزار صارفین کے ساتھ فعال ڈسکارڈ بلڈر کمیونٹی۔ + +- [**Allnodes**](https://www.allnodes.com/) + - [Docs](https://docs.allnodes.com/) + - خصوصیات + - Allnodes پورٹ فولیو صفحہ پر بنائے گئے PublicNode ٹوکن کے ساتھ کوئی ریٹ کی حد نہیں۔ + - [PublicNode](https://www.publicnode.com) پر پرائیویسی پر مرکوز مفت rpc اینڈ پوائنٹس (100+ بلاک چینز)۔ + - 90+ بلاک چینز کے لیے بغیر ریٹ کی حد کے وقف شدہ نوڈز۔ + - 30+ بلاک چینز کے لیے وقف شدہ آرکائیو نوڈز۔ + - 3 علاقوں (US, EU, Asia) میں دستیاب ہے۔ + - [PublicNode](https://www.publicnode.com/snapshots) پر 100+ بلاک چینز کے لیے اسنیپ شاٹس۔ + - 99.90%-99.98% اپ ٹائم SLA کے ساتھ 24/7 تکنیکی مدد (پلان پر منحصر ہے)۔ + - فی گھنٹہ ادائیگی کی قیمت۔ + - کریڈٹ کارڈ، پے پال یا کرپٹو سے ادائیگی کریں۔ + +- [**All That Node**](https://allthatnode.com/) + - [Docs](https://docs.allthatnode.com/) + - خصوصیات + - مفت ٹائیر کے ساتھ روزانہ 50,000 درخواستیں۔ + - 40 سے زیادہ پروٹوکولز کے لیے سپورٹ۔ + - JSON-RPC (EVM, Tendermint)، REST، اور Websocket APIs کی حمایت کی جاتی ہے۔ + - آرکائیو تاریخ تک لامحدود رسائی۔ + - 24/7 تکنیکی مدد اور 99.9% سے زیادہ اپ ٹائم۔ + - ملٹی چینز پر فاوسیٹ (Faucet) دستیاب ہے۔ + - لامحدود تعداد میں API کیز (keys) کے ساتھ لامحدود اینڈ پوائنٹ رسائی۔ + - Trace/Debug API کی حمایت کی جاتی ہے۔ + - خودکار اپ ڈیٹس۔ + +- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/) + - [Docs](https://aws.amazon.com/managed-blockchain/resources/) + - خصوصیات + - مکمل طور پر منظم Ethereum نوڈز۔ + - چھ علاقوں میں دستیاب ہے۔ + - HTTP اور محفوظ (secure) WebSockets پر JSON-RPC۔ + - 3 چینز کو سپورٹ کرتا ہے۔ + - SLAs, AWS سپورٹ 24/7۔ + - Go-ethereum اور Lighthouse۔ + +- [**Ankr**](https://www.ankr.com/) + - [Docs](https://docs.ankr.com/) + - خصوصیات + - Ankr پروٹوکول - 8+ چینز کے لیے پبلک RPC API اینڈ پوائنٹس تک کھلی رسائی۔ + - قریب ترین دستیاب نوڈ تک تیز اور قابل اعتماد گیٹ وے کے لیے لوڈ بیلنسنگ اور نوڈ ہیلتھ مانیٹرنگ۔ + - پریمیم ٹائیر جو WSS اینڈ پوائنٹ اور بغیر حد کے ریٹ کی اجازت دیتا ہے۔ + - 40+ چینز کے لیے ایک کلک میں مکمل نوڈ اور ویلیڈیٹر نوڈ کی تعیناتی۔ + - جیسے جیسے آپ آگے بڑھیں اسکیل کریں۔ + - تجزیاتی ٹولز۔ + - ڈیش بورڈ + - RPC, HTTPS اور WSS اینڈ پوائنٹس۔ + - براہ راست مدد۔ + +- [**Blast**](https://blastapi.io/) + - [Docs](https://docs.blastapi.io/) + - خصوصیات + - RPC اور WSS سپورٹ۔ + - ملٹی ریجن نوڈ ہوسٹنگ۔ + - ڈی سینٹرلائزڈ انفراسٹرکچر۔ + - پبلک API + - وقف شدہ مفت پلان۔ + - ملٹی چین سپورٹ (17+ بلاک چینز)۔ + - آرکائیو نوڈز۔ + - 24/7 ڈسکارڈ سپورٹ۔ + - 24/7 مانیٹرنگ اور الرٹس۔ + - 99.9% کا مجموعی SLA۔ + - کرپٹو میں ادائیگی کریں۔ + +- [**BlockDaemon**](https://blockdaemon.com/) + - [Docs](https://ubiquity.docs.blockdaemon.com/) + - فوائد + - ڈیش بورڈ + - فی نوڈ کی بنیاد پر۔ + - تجزیات + +- [**BlockPI**](https://blockpi.io/) + - [Docs](https://docs.blockpi.io/) + - خصوصیات + - مضبوط اور تقسیم شدہ نوڈ کا ڈھانچہ۔ + - 40 تک HTTPS اور WSS اینڈ پوائنٹس۔ + - مفت سائن اپ پیکیج اور ماہانہ پیکیج۔ + - Trace طریقہ + آرکائیو ڈیٹا سپورٹ۔ + - 90 دن تک کی میعاد والے پیکیجز۔ + - کسٹم پلان اور 'پے ایز یو گو' ادائیگی۔ + - کرپٹو میں ادائیگی کریں۔ + - براہ راست مدد اور تکنیکی مدد۔ + +- [**Chainbase**](https://www.chainbase.com/) + - [Docs](https://docs.chainbase.com) + - خصوصیات + - انتہائی دستیاب، تیز، اور اسکیل ایبل RPC سروس۔ + - ملٹی چین سپورٹ۔ + - مفت ٹیرف۔ + - صارف دوست ڈیش بورڈ۔ + - RPC سے آگے بلاک چین ڈیٹا سروسز فراہم کرتا ہے۔ + +- [**Chainstack**](https://chainstack.com/) + - [Docs](https://docs.chainstack.com/) + - خصوصیات + - مفت مشترکہ نوڈز۔ + - مشترکہ آرکائیو نوڈز۔ + - GraphQL سپورٹ۔ + - RPC اور WSS اینڈ پوائنٹس۔ + - وقف شدہ مکمل اور آرکائیو نوڈز۔ + - وقف شدہ تعیناتیوں کے لیے تیز سنک ٹائم۔ + - اپنا کلاؤڈ لائیں۔ + - فی گھنٹہ ادائیگی کی قیمت۔ + - براہ راست 24/7 مدد۔ + +- [**dRPC**](https://drpc.org/) + - [Docs](https://drpc.org/docs) + - NodeCloud: پلگ-این-پلے RPC انفرا $10 (USD) سے شروع—مکمل رفتار، کوئی حد نہیں۔ + - NodeCloud کی خصوصیات: + - 185 نیٹ ورکس کے لیے API سپورٹ۔ + - 40+ فراہم کنندگان کا تقسیم شدہ پول۔ + - نو (9) جیو-کلسٹرز کے ساتھ عالمی کوریج۔ + - AI سے چلنے والا لوڈ بیلنسنگ سسٹم۔ + - پے-ایز-یو-گو فلیٹ قیمت—کوئی اضافہ نہیں، کوئی میعاد ختم نہیں، کوئی لاک-ان نہیں۔ + - لامحدود کیز، گرینولر کی ٹویکس، ٹیم کے کردار، فرنٹ-اینڈ تحفظ۔ + - طریقوں کی فلیٹ شرح 20 کمپیوٹ یونٹس (CUs) فی طریقہ۔ + - [پبلک اینڈ پوائنٹ چین لسٹ](https://drpc.org/chainlist) + - [قیمت کا کیلکولیٹر](https://drpc.org/pricing#calculator) + - NodeCore: مکمل کنٹرول چاہنے والی تنظیموں کے لیے اوپن سورس اسٹیک۔ + +- [**GetBlock**](https://getblock.io/) + - [Docs](https://getblock.io/docs/get-started/authentication-with-api-key/) + - خصوصیات + - 40+ بلاک چین نوڈز تک رسائی۔ + - روزانہ 40K مفت درخواستیں۔ + - API کیز (keys) کی لامحدود تعداد۔ + - 1GB/sec پر تیز کنکشن کی رفتار۔ + - Trace+Archive + - جدید تجزیات۔ + - خودکار اپ ڈیٹس۔ + - تکنیکی مدد۔ + +- [**InfStones**](https://infstones.com/) + - خصوصیات + - مفت ٹائیر کا آپشن۔ + - جیسے جیسے آپ آگے بڑھیں اسکیل کریں۔ + - تجزیات + - ڈیش بورڈ + - منفرد API اینڈ پوائنٹس۔ + - وقف شدہ مکمل نوڈز۔ + - وقف شدہ تعیناتیوں کے لیے تیز سنک ٹائم۔ + - براہ راست 24/7 مدد۔ + - 50+ بلاک چین نوڈز تک رسائی۔ + +- [**Infura**](https://infura.io/) + - [Docs](https://infura.io/docs) + - خصوصیات + - مفت ٹائیر کا آپشن۔ + - جیسے جیسے آپ آگے بڑھیں اسکیل کریں۔ + - بامعاوضہ آرکائیول ڈیٹا۔ + - براہ راست مدد۔ + - ڈیش بورڈ + +- [**Kaleido**](https://kaleido.io/) + - [Docs](https://docs.kaleido.io/) + - خصوصیات + - مفت اسٹارٹر ٹائیر۔ + - ایک کلک میں Ethereum نوڈ کی تعیناتی۔ + - حسب ضرورت کلائنٹس اور الگورتھم (Geth, Quorum & Besu || PoA, IBFT & Raft)۔ + - 500+ انتظامی اور سروس APIs۔ + - Ethereum ٹرانزیکشن جمع کرانے کے لیے RESTful انٹرفیس (Apache Kafka کی حمایت یافتہ)۔ + - ایونٹ کی ترسیل کے لیے آؤٹ باؤنڈ اسٹریمز (Apache Kafka کی حمایت یافتہ)۔ + - "آف چین" اور ذیلی خدمات کا گہرا مجموعہ (مثلاً، دو طرفہ انکرپٹڈ میسجنگ ٹرانسپورٹ)۔ + - گورننس اور کردار پر مبنی رسائی کنٹرول کے ساتھ سیدھا نیٹ ورک آن بورڈنگ۔ + - ایڈمنسٹریٹرز اور آخری صارفین دونوں کے لیے جدید صارف کا انتظام۔ + - انتہائی اسکیل ایبل، لچکدار، انٹرپرائز-گریڈ انفراسٹرکچر۔ + - کلاؤڈ HSM پرائیویٹ کی (key) کا انتظام۔ + - Ethereum مین نیٹ ٹیدرنگ۔ + - ISO 27k اور SOC 2، ٹائپ 2 سرٹیفیکیشنز۔ + - متحرک رن ٹائم کنفیگریشن (مثلاً، کلاؤڈ انٹیگریشنز شامل کرنا، نوڈ انگرسس کو تبدیل کرنا، وغیرہ)۔ + - ملٹی کلاؤڈ، ملٹی ریجن اور ہائبرڈ تعیناتی آرکیسٹریشن کے لیے سپورٹ۔ + - سادہ گھنٹہ وار SaaS پر مبنی قیمت۔ + - SLAs اور 24x7 سپورٹ۔ + +- [**Lava Network**](https://www.lavanet.xyz/) + - [Docs](https://docs.lavanet.xyz/) + - خصوصیات + - مفت ٹیسٹ نیٹ کا استعمال۔ + - اعلی اپ ٹائم کے لیے ڈی سینٹرلائزڈ ریڈنڈنسی۔ + - اوپن سورس۔ + - مکمل طور پر ڈی سینٹرلائزڈ SDK۔ + - Ethers.js انٹیگریشن۔ + - بدیہی پروجیکٹ مینجمنٹ انٹرفیس۔ + - کنسینسس پر مبنی ڈیٹا کی سالمیت۔ + - ملٹی چین سپورٹ۔ + +- [**Moralis**](https://moralis.io/) + - [Docs](https://docs.moralis.io/) + - خصوصیات + - مفت مشترکہ نوڈز۔ + - مفت مشترکہ آرکائیو نوڈز۔ + - پرائیویسی پر مرکوز (کوئی لاگ پالیسی نہیں)۔ + - کراس چین سپورٹ۔ + - جیسے جیسے آپ آگے بڑھیں اسکیل کریں۔ + - ڈیش بورڈ + - منفرد Ethereum SDK۔ + - منفرد API اینڈ پوائنٹس۔ + - براہ راست، تکنیکی مدد۔ + +- [**NodeReal MegaNode**](https://nodereal.io/) + - [Docs](https://docs.nodereal.io/docs/introduction) + - خصوصیات + - قابل اعتماد، تیز اور اسکیل ایبل RPC API سروسز۔ + - web3 ڈیولپرز کے لیے بہتر API۔ + - ملٹی چین سپورٹ۔ + - مفت میں شروع کریں۔ + +- [**NOWNodes**](https://nownodes.io/) + - [Docs](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - خصوصیات + - 50+ بلاک چین نوڈز تک رسائی۔ + - مفت API کی (Key)۔ + - بلاک ایکسپلوررز۔ + - API رسپانس ٹائم ⩽ 1 سیکنڈ۔ + - 24/7 سپورٹ ٹیم۔ + - ذاتی اکاؤنٹ مینیجر۔ + - مشترکہ، آرکائیو، بیک اپ اور وقف شدہ نوڈز۔ + +- [**Pocket Network**](https://www.pokt.network/) + - [Docs](https://docs.pokt.network/home/) + - خصوصیات + - ڈی سینٹرلائزڈ RPC پروٹوکول اور مارکیٹ پلیس۔ + - 1M درخواستیں فی دن مفت ٹائیر (فی اینڈ پوائنٹ، زیادہ سے زیادہ 2)۔ + - [پبلک اینڈ پوائنٹس](https://docs.pokt.network/developers/public-endpoints) + - پری-اسٹیک+ پروگرام (اگر آپ کو روزانہ 1M سے زیادہ درخواستوں کی ضرورت ہے)۔ + - 15+ بلاک چینز کی حمایت یافتہ۔ + - 6400+ نوڈز جو ایپلی کیشنز کی خدمت کے لیے POKT کما رہے ہیں۔ + - آرکائیول نوڈ، ٹریسنگ کے ساتھ آرکائیول نوڈ، اور ٹیسٹ نیٹ نوڈ سپورٹ۔ + - Ethereum مین نیٹ نوڈ کلائنٹ کا تنوع۔ + - ناکامی کا کوئی ایک نقطہ نہیں۔ + - صفر ڈاؤن ٹائم۔ + - لاگت-مؤثر تقریباً-صفر ٹوکنومکس (نیٹ ورک بینڈوتھ کے لیے ایک بار POKT اسٹیک کریں)۔ + - کوئی ماہانہ ڈوبی ہوئی لاگت نہیں، اپنے انفراسٹرکچر کو ایک اثاثہ میں تبدیل کریں۔ + - پروٹوکول میں بلٹ-ان لوڈ-بیلنسنگ۔ + - جیسے جیسے آپ آگے بڑھیں، روزانہ کی درخواستوں اور فی گھنٹہ نوڈز کی تعداد کو لامحدود طور پر اسکیل کریں۔ + - سب سے زیادہ نجی، سنسرشپ-مزاحم آپشن۔ + - ہینڈز-آن ڈیولپر سپورٹ۔ + - [Pocket Portal](https://bit.ly/ETHorg_POKTportal) ڈیش بورڈ اور تجزیات۔ + +- [**QuickNode**](https://www.quicknode.com) + - [Docs](https://www.quicknode.com/docs/) + - خصوصیات + - 24/7 تکنیکی مدد اور ڈیو ڈسکارڈ کمیونٹی۔ + - جیو-بیلنسڈ، ملٹی کلاؤڈ/میٹل، کم لیٹنسی والا نیٹ ورک۔ + - ملٹی چین سپورٹ (Optimism, Arbitrum, Polygon + 11 دیگر)۔ + - رفتار اور استحکام کے لیے درمیانی پرتیں (کال روٹنگ، کیش، انڈیکسنگ)۔ + - ویب ہکس کے ذریعے اسمارٹ-کنٹریکٹ کی نگرانی۔ + - بدیہی ڈیش بورڈ، تجزیاتی سویٹ، RPC کمپوزر۔ + - جدید حفاظتی خصوصیات (JWT، ماسکنگ، وائٹ لسٹنگ)۔ + - NFT ڈیٹا اور تجزیاتی API۔ + - [SOC2 سرٹیفائیڈ](https://www.quicknode.com/security) + - ڈیولپرز سے لے کر انٹرپرائزز تک کے لیے موزوں۔ + +- [**Rivet**](https://rivet.cloud/) + - [Docs](https://rivet.readthedocs.io/en/latest/) + - خصوصیات + - مفت ٹائیر کا آپشن۔ + - جیسے جیسے آپ آگے بڑھیں اسکیل کریں۔ + +- [**SenseiNode**](https://senseinode.com) + - [Docs](https://docs.senseinode.com/) + - خصوصیات + - وقف شدہ اور مشترکہ نوڈز۔ + - ڈیش بورڈ + - لاطینی امریکہ میں مختلف مقامات پر متعدد ہوسٹنگ فراہم کنندگان پر AWS سے ہٹ کر ہوسٹنگ۔ + - Prysm اور Lighthouse کلائنٹس۔ + +- [**SettleMint**](https://console.settlemint.com/) + - [Docs](https://docs.settlemint.com/) + - خصوصیات + - مفت ٹرائل۔ + - جیسے جیسے آپ آگے بڑھیں اسکیل کریں۔ + - GraphQL سپورٹ۔ + - RPC اور WSS اینڈ پوائنٹس۔ + - وقف شدہ مکمل نوڈز۔ + - اپنا کلاؤڈ لائیں۔ + - تجزیاتی ٹولز۔ + - ڈیش بورڈ + - فی گھنٹہ ادائیگی کی قیمت۔ + - براہ راست مدد۔ + +- [**Tenderly**](https://tenderly.co/web3-gateway) + - [Docs](https://docs.tenderly.co/web3-gateway/web3-gateway) + - خصوصیات + - مفت ٹائیر جس میں 25 ملین Tenderly یونٹس فی مہینہ شامل ہیں۔ + - تاریخی ڈیٹا تک مفت رسائی۔ + - 8 گنا تک تیز ریڈ-ہیوی ورک لوڈز۔ + - 100% مستقل ریڈ رسائی۔ + - JSON-RPC اینڈ پوائنٹس۔ + - UI پر مبنی RPC درخواست بلڈر اور درخواست کا پیش نظارہ۔ + - Tenderly کے ڈیولپمنٹ، ڈیبگنگ، اور ٹیسٹنگ ٹولز کے ساتھ مضبوطی سے مربوط۔ + - ٹرانزیکشن سیمولیشنز۔ + - استعمال کے تجزیات اور فلٹرنگ۔ + - آسان رسائی کی (key) کا انتظام۔ + - چیٹ، ای میل، اور ڈسکارڈ کے ذریعے وقف شدہ انجینئرنگ سپورٹ۔ + +- [**Tokenview**](https://services.tokenview.io/) + - [Docs](https://services.tokenview.io/docs?type=nodeService) + - خصوصیات + - 24/7 تکنیکی مدد اور ڈیو ٹیلیگرام کمیونٹی۔ + - ملٹی چین سپورٹ (Bitcoin، Ethereum، Tron، BNB اسمارٹ چین، Ethereum کلاسک)۔ + - RPC اور WSS دونوں اینڈ پوائنٹس استعمال کے لیے کھلے ہیں۔ + - آرکائیو ڈیٹا API تک لامحدود رسائی۔ + - درخواست ایکسپلورر اور Mempool واچر کے ساتھ ڈیش بورڈ۔ + - NFT ڈیٹا API اور ویب ہک نوٹیفائی۔ + - کرپٹو میں ادائیگی کریں۔ + - اضافی رویے کی ضروریات کے لیے بیرونی مدد۔ + +- [**Watchdata**](https://watchdata.io/) + - [Docs](https://docs.watchdata.io/) + - خصوصیات + - ڈیٹا کی قابل اعتمادی۔ + - بغیر کسی ڈاؤن ٹائم کے بلاتعطل کنکشن۔ + - عمل کی آٹومیشن۔ + - مفت ٹیرف۔ + - اعلیٰ حدود جو کسی بھی صارف کے لیے موزوں ہیں۔ + - مختلف نوڈز کے لیے سپورٹ۔ + - وسائل کی اسکیلنگ۔ + - تیز پروسیسنگ رفتار۔ + +- [**ZMOK**](https://zmok.io/) + - [Docs](https://docs.zmok.io/) + - خصوصیات + - بطور سروس فرنٹ-رننگ۔ + - تلاش/فلٹرنگ طریقوں کے ساتھ عالمی ٹرانزیکشنز میمپول۔ + - ٹرانزیکشن بھیجنے کے لیے لامحدود TX فیس اور لامحدود گیس۔ + - نئے بلاک کو سب سے تیزی سے حاصل کرنا اور بلاک چین کو پڑھنا۔ + - فی API کال بہترین قیمت کی گارنٹی۔ + +- [**Zeeve**](https://www.zeeve.io/) + - [Docs](https://www.zeeve.io/docs/) + - خصوصیات + - انٹرپرائز-گریڈ نو-کوڈ آٹومیشن پلیٹ فارم جو بلاک چین نوڈز اور نیٹ ورکس کی تعیناتی، نگرانی اور انتظام فراہم کرتا ہے۔ + - 30+ حمایتی پروٹوکولز اور انٹیگریشنز، اور مزید شامل کیے جا رہے ہیں۔ + - ویلیو ایڈڈ web3 انفراسٹرکچر سروسز جیسے ڈی سینٹرلائزڈ اسٹوریج، ڈی سینٹرلائزڈ شناخت اور حقیقی دنیا کے استعمال کے معاملات کے لیے بلاک چین لیجر ڈیٹا APIs۔ + - 24/7 سپورٹ اور فعال نگرانی ہر وقت نوڈز کی صحت کو یقینی بناتی ہے۔ + - RPC اینڈ پوائنٹس APIs تک تصدیق شدہ رسائی، بدیہی ڈیش بورڈ اور تجزیات کے ساتھ پریشانی سے پاک انتظام پیش کرتے ہیں۔ + - دونوں منظم کلاؤڈ اور اپنا کلاؤڈ لانے کے آپشنز فراہم کرتا ہے اور تمام بڑے کلاؤڈ فراہم کنندگان جیسے AWS، Azure، Google Cloud، Digital Ocean اور آن-پریمس کو سپورٹ کرتا ہے۔ + - ہم ہر بار آپ کے صارف کے قریب ترین نوڈ کو ہٹ کرنے کے لیے ذہین روٹنگ کا استعمال کرتے ہیں۔ + +## مزید پڑھیں {#further-reading} + +- [Ethereum نوڈ سروسز کی فہرست](https://ethereumnodes.com/) + +## متعلقہ موضوعات {#related-topics} + +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [Alchemy کا استعمال کرتے ہوئے Ethereum ڈیولپمنٹ کے ساتھ شروعات کرنا](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [web3 اور Alchemy کا استعمال کرتے ہوئے ٹرانزیکشن بھیجنے کے لیے گائیڈ](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git a/public/content/translations/ur/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/ur/developers/docs/nodes-and-clients/run-a-node/index.md new file mode 100644 index 00000000000..996106f35d2 --- /dev/null +++ b/public/content/translations/ur/developers/docs/nodes-and-clients/run-a-node/index.md @@ -0,0 +1,484 @@ +--- +title: "اپنا خود کا ایتھریم نوڈ اسپن کریں" +description: "ایتھریم کلائنٹ کا اپنا انسٹینس چلانے کا عمومی تعارف۔" +lang: ur-in +sidebarDepth: 2 +--- + +اپنا نوڈ چلانے سے آپ کو مختلف فوائد ملتے ہیں، نئے امکانات کھلتے ہیں، اور ماحولیاتی نظام کو سپورٹ کرنے میں مدد ملتی ہے۔ یہ صفحہ آپ کو اپنا نوڈ اسپن کرنے اور ایتھریم ٹرانزیکشنز کی توثیق میں حصہ لینے میں رہنمائی کرے گا۔ + +نوٹ کریں کہ [The Merge](/roadmap/merge) کے بعد، ایتھریم نوڈ چلانے کے لیے دو کلائنٹس کی ضرورت ہوتی ہے؛ ایک **ایگزیکیوشن لیئر (EL)** کلائنٹ اور ایک **کنسینسس لیئر (CL)** کلائنٹ۔ یہ صفحہ دکھائے گا کہ ایتھریم نوڈ چلانے کے لیے ان دو کلائنٹس کو کیسے انسٹال، کنفیگر اور کنیکٹ کیا جائے۔ + +## شرائط {#prerequisites} + +آپ کو یہ سمجھنا چاہئے کہ ایتھریم نوڈ کیا ہے اور آپ کلائنٹ کیوں چلانا چاہیں گے۔ اس کا احاطہ [نوڈس اور کلائنٹس](/developers/docs/nodes-and-clients/) میں کیا گیا ہے۔ + +اگر آپ نوڈ چلانے کے موضوع میں نئے ہیں، یا کم تکنیکی راستے کی تلاش میں ہیں، تو ہم تجویز کرتے ہیں کہ پہلے [ایتھریم نوڈ چلانے](/run-a-node) پر ہمارا صارف دوست تعارف دیکھیں۔ + +## ایک نقطہ نظر کا انتخاب {#choosing-approach} + +اپنا نوڈ اسپن کرنے میں پہلا قدم اپنے نقطہ نظر کا انتخاب کرنا ہے۔ ضروریات اور مختلف امکانات کی بنیاد پر، آپ کو کلائنٹ کے نفاذ (ایگزیکیوشن اور کنسینسس کلائنٹس دونوں)، ماحول (ہارڈویئر، سسٹم)، اور کلائنٹ کی ترتیبات کے لیے پیرامیٹرز کا انتخاب کرنا ہوگا۔ + +یہ صفحہ ان فیصلوں میں آپ کی رہنمائی کرے گا اور آپ کو اپنا ایتھریم انسٹینس چلانے کا سب سے موزوں طریقہ تلاش کرنے میں مدد کرے گا۔ + +کلائنٹ کے نفاذ میں سے انتخاب کرنے کے لیے، تمام دستیاب مین نیٹ کے لیے تیار [ایگزیکیوشن کلائنٹس](/developers/docs/nodes-and-clients/#execution-clients)، [کنسینسس کلائنٹس](/developers/docs/nodes-and-clients/#consensus-clients) دیکھیں اور [کلائنٹ ڈائیورسٹی](/developers/docs/nodes-and-clients/client-diversity) کے بارے میں جانیں۔ + +کلائنٹس کی [ضروریات](#requirements) پر غور کرتے ہوئے، فیصلہ کریں کہ سافٹ ویئر کو اپنے [ہارڈویئر پر چلانا ہے یا کلاؤڈ میں](#local-vs-cloud)۔ + +ماحول تیار کرنے کے بعد، منتخب کلائنٹس کو یا تو [ابتدائی افراد کے لیے دوستانہ انٹرفیس](#automatized-setup) کے ساتھ یا اعلیٰ اختیارات کے ساتھ ٹرمینل کا استعمال کرتے ہوئے [دستی طور پر](#manual-setup) انسٹال کریں۔ + +جب نوڈ چل رہا ہو اور مطابقت پذیری کر رہا ہو، تو آپ اسے [استعمال کرنے](#using-the-node) کے لیے تیار ہیں، لیکن اس کی [دیکھ بھال](#operating-the-node) پر نظر رکھنا یقینی بنائیں۔ + +![کلائنٹ سیٹ اپ](./diagram.png) + +### ماحول اور ہارڈویئر {#environment-and-hardware} + +#### مقامی یا کلاؤڈ {#local-vs-cloud} + +ایتھریم کلائنٹس صارف کے درجے کے کمپیوٹرز پر چل سکتے ہیں اور انہیں کسی خاص ہارڈویئر کی ضرورت نہیں ہوتی، جیسے کہ مثال کے طور پر کان کنی کی مشینیں۔ لہذا، آپ کے پاس اپنی ضروریات کی بنیاد پر نوڈ کو تعینات کرنے کے لیے مختلف اختیارات ہیں۔ +آسان بنانے کے لیے، آئیے ایک مقامی فزیکل مشین اور کلاؤڈ سرور دونوں پر نوڈ چلانے کے بارے میں سوچتے ہیں: + +- کلاؤڈ + - فراہم کنندگان اعلی سرور اپ ٹائم اور جامد عوامی IP پتے پیش کرتے ہیں + - ایک وقف شدہ یا ورچوئل سرور حاصل کرنا اپنا بنانے سے زیادہ آرام دہ ہوسکتا ہے + - ٹریڈ آف ایک تیسرے فریق - سرور فراہم کنندہ پر بھروسہ کرنا ہے + - مکمل نوڈ کے لیے درکار اسٹوریج سائز کی وجہ سے، کرائے کے سرور کی قیمت زیادہ ہو سکتی ہے +- اپنا ہارڈویئر + - زیادہ ٹرس ٹلیس اور خودمختار نقطہ نظر + - ایک بار کی سرمایہ کاری + - پہلے سے تشکیل شدہ مشینیں خریدنے کا ایک اختیار + - آپ کو مشین اور نیٹ ورکنگ کو جسمانی طور پر تیار کرنا، برقرار رکھنا، اور ممکنہ طور پر خرابیوں کا ازالہ کرنا ہوگا + +دونوں اختیارات کے مختلف فوائد ہیں جن کا خلاصہ اوپر دیا گیا ہے۔ اگر آپ کلاؤڈ حل تلاش کر رہے ہیں، تو بہت سے روایتی کلاؤڈ کمپیوٹنگ فراہم کنندگان کے علاوہ، نوڈس کو تعینات کرنے پر مرکوز خدمات بھی موجود ہیں۔ میزبانی شدہ نوڈس پر مزید اختیارات کے لیے [نوڈس بطور سروس](/developers/docs/nodes-and-clients/nodes-as-a-service/) دیکھیں۔ + +#### ہارڈ ویئر {#hardware} + +تاہم، ایک سنسر شپ مزاحم، غیر مرکزی نیٹ ورک کو کلاؤڈ فراہم کنندگان پر انحصار نہیں کرنا چاہئے۔ اس کے بجائے، اپنے مقامی ہارڈویئر پر اپنا نوڈ چلانا ماحولیاتی نظام کے لیے زیادہ صحت مند ہے۔ [تخمینہ](https://www.ethernodes.org/networkType/cl/Hosting) دکھاتا ہے کہ نوڈس کا ایک بڑا حصہ کلاؤڈ پر چلتا ہے، جو ناکامی کا ایک واحد نقطہ بن سکتا ہے۔ + +ایتھریم کلائنٹس آپ کے کمپیوٹر، لیپ ٹاپ، سرور، یا یہاں تک کہ ایک سنگل بورڈ کمپیوٹر پر بھی چل سکتے ہیں۔ جبکہ اپنے ذاتی کمپیوٹر پر کلائنٹس چلانا ممکن ہے، صرف اپنے نوڈ کے لیے ایک وقف شدہ مشین رکھنا اس کی کارکردگی اور سیکیورٹی کو نمایاں طور پر بڑھا سکتا ہے جبکہ آپ کے بنیادی کمپیوٹر پر اثرات کو کم سے کم کیا جا سکتا ہے۔ + +اپنا ہارڈویئر استعمال کرنا بہت آسان ہوسکتا ہے۔ زیادہ تکنیکی لوگوں کے لیے بہت سے آسان اختیارات کے ساتھ ساتھ جدید سیٹ اپ بھی موجود ہیں۔ تو آئیے آپ کی مشین پر ایتھریم کلائنٹس چلانے کی ضروریات اور ذرائع پر غور کریں۔ + +#### ضروریات {#requirements} + +ہارڈویئر کی ضروریات کلائنٹ کے لحاظ سے مختلف ہوتی ہیں لیکن عام طور پر اتنی زیادہ نہیں ہوتی ہیں کیونکہ نوڈ کو صرف مطابقت پذیر رہنے کی ضرورت ہوتی ہے۔ اسے کان کنی کے ساتھ الجھن میں نہ ڈالیں، جس کے لیے بہت زیادہ کمپیوٹنگ پاور کی ضرورت ہوتی ہے۔ تاہم، زیادہ طاقتور ہارڈویئر کے ساتھ مطابقت پذیری کا وقت اور کارکردگی بہتر ہوتی ہے۔ + +کسی بھی کلائنٹ کو انسٹال کرنے سے پہلے، براہ کرم یقینی بنائیں کہ آپ کے کمپیوٹر کے پاس اسے چلانے کے لیے کافی وسائل ہیں۔ آپ ذیل میں کم از کم اور تجویز کردہ ضروریات تلاش کرسکتے ہیں۔ + +آپ کے ہارڈویئر کے لیے رکاوٹ زیادہ تر ڈسک کی جگہ ہے۔ ایتھریم بلاکچین کی مطابقت پذیری بہت ان پٹ/آؤٹ پٹ پر مبنی ہے اور اس کے لیے بہت زیادہ جگہ کی ضرورت ہوتی ہے۔ مطابقت پذیری کے بعد بھی سینکڑوں جی بی خالی جگہ کے ساتھ ایک **سالڈ اسٹیٹ ڈرائیو (SSD)** رکھنا بہتر ہے۔ + +ڈیٹا بیس کا سائز اور ابتدائی مطابقت پذیری کی رفتار منتخب کلائنٹ، اس کی ترتیب اور [مطابقت پذیری کی حکمت عملی](/developers/docs/nodes-and-clients/#sync-modes) پر منحصر ہے۔ + +یہ بھی یقینی بنائیں کہ آپ کا انٹرنیٹ کنکشن [بینڈوڈتھ کیپ](https://wikipedia.org/wiki/Data_cap) سے محدود نہیں ہے۔ ایک غیر میٹر شدہ کنکشن استعمال کرنے کی سفارش کی جاتی ہے کیونکہ ابتدائی مطابقت پذیری اور نیٹ ورک پر نشر کیا گیا ڈیٹا آپ کی حد سے تجاوز کر سکتا ہے۔ + +##### آپریٹنگ سسٹم + +تمام کلائنٹس بڑے آپریٹنگ سسٹمز - لینکس، میک او ایس، ونڈوز کو سپورٹ کرتے ہیں۔ اس کا مطلب ہے کہ آپ باقاعدہ ڈیسک ٹاپ یا سرور مشینوں پر اس آپریٹنگ سسٹم (OS) کے ساتھ نوڈس چلا سکتے ہیں جو آپ کے لیے بہترین ہے۔ یقینی بنائیں کہ آپ کا OS ممکنہ مسائل اور سیکیورٹی کے خطرات سے بچنے کے لیے تازہ ترین ہے۔ + +##### کم از کم ضروریات + +- 2+ کور والا سی پی یو +- 8 جی بی ریم +- 2 ٹی بی ایس ایس ڈی +- 10+ ایم بٹ/سیکنڈ بینڈوڈتھ + +##### تجویز کردہ وضاحتیں + +- 4+ کور والا تیز سی پی یو +- 16+ جی بی ریم +- 2+ ٹی بی کے ساتھ تیز ایس ایس ڈی +- 25+ ایم بٹ/سیکنڈ بینڈوڈتھ + +آپ کے منتخب کردہ مطابقت پذیری کا موڈ اور کلائنٹ جگہ کی ضروریات کو متاثر کرے گا، لیکن ہم نے ذیل میں ہر کلائنٹ کے لیے درکار ڈسک کی جگہ کا تخمینہ لگایا ہے۔ + +| کلائنٹ | ڈسک کا سائز (سنیپ سنک) | ڈسک کا سائز (مکمل آرکائیو) | +| ---------- | ----------------------------------------- | --------------------------------------------- | +| Besu | 800GB+ | 12TB+ | +| Erigon | N/A | 2.5TB+ | +| Geth | 500GB+ | 12TB+ | +| Nethermind | 500GB+ | 12TB+ | +| Reth | N/A | 2.2TB+ | + +- نوٹ: Erigon اور Reth سنیپ سنک پیش نہیں کرتے ہیں، لیکن مکمل کٹائی ممکن ہے (~2TB Erigon کے لیے، ~1.2TB Reth کے لیے) + +کنسینسس کلائنٹس کے لیے، جگہ کی ضرورت کلائنٹ کے نفاذ اور فعال خصوصیات (مثال کے طور پر، ویلیڈیٹر سلیشر) پر بھی منحصر ہے، لیکن عام طور پر بیکن ڈیٹا کے لیے درکار مزید 200GB کے ساتھ شمار کریں۔ بڑی تعداد میں ویلیڈیٹرز کے ساتھ، بینڈوڈتھ کا بوجھ بھی بڑھتا ہے۔ آپ [اس تجزیے میں کنسینسس کلائنٹ کی ضروریات پر تفصیلات](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc) تلاش کرسکتے ہیں۔ + +#### پلگ اینڈ پلے حل {#plug-and-play} + +اپنے ہارڈویئر کے ساتھ نوڈ چلانے کا سب سے آسان آپشن پلگ اینڈ پلے باکسز کا استعمال ہے۔ وینڈرز سے پہلے سے تشکیل شدہ مشینیں سب سے سیدھا تجربہ پیش کرتی ہیں: آرڈر کریں، جڑیں، چلائیں۔ سافٹ ویئر کی نگرانی اور کنٹرول کے لیے ایک بدیہی گائیڈ اور ڈیش بورڈ کے ساتھ ہر چیز پہلے سے تشکیل شدہ ہے اور خود بخود چلتی ہے۔ + +- [DappNode](https://dappnode.io/) +- [Avado](https://ava.do/) + +#### ایک سنگل بورڈ کمپیوٹر پر ایتھریم {#ethereum-on-a-single-board-computer} + +ایتھریم نوڈ چلانے کا ایک آسان اور سستا طریقہ ایک سنگل بورڈ کمپیوٹر کا استعمال ہے، یہاں تک کہ Raspberry Pi جیسے ARM فن تعمیر کے ساتھ بھی۔ [ARM پر ایتھریم](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) Raspberry Pi اور دیگر ARM بورڈز کے لیے متعدد ایگزیکیوشن اور کنسینسس کلائنٹ کی آسانی سے چلنے والی تصاویر فراہم کرتا ہے۔ + +اس طرح کے چھوٹے، سستے اور موثر آلات گھر پر نوڈ چلانے کے لیے مثالی ہیں لیکن ان کی محدود کارکردگی کو ذہن میں رکھیں۔ + +## نوڈ کو اسپن کرنا {#spinning-up-node} + +اصل کلائنٹ سیٹ اپ یا تو خودکار لانچرز کے ساتھ یا دستی طور پر کیا جا سکتا ہے، کلائنٹ سافٹ ویئر کو براہ راست ترتیب دے کر۔ + +کم جدید صارفین کے لیے، تجویز کردہ نقطہ نظر ایک لانچر کا استعمال ہے، ایسا سافٹ ویئر جو آپ کو انسٹالیشن کے ذریعے رہنمائی کرتا ہے اور کلائنٹ سیٹ اپ کے عمل کو خودکار کرتا ہے۔ تاہم، اگر آپ کو ٹرمینل استعمال کرنے کا کچھ تجربہ ہے، تو دستی سیٹ اپ کے مراحل پر عمل کرنا آسان ہونا چاہئے۔ + +### رہنمائی والا سیٹ اپ {#automatized-setup} + +متعدد صارف دوست منصوبوں کا مقصد کلائنٹ قائم کرنے کے تجربے کو بہتر بنانا ہے۔ یہ لانچرز خودکار کلائنٹ انسٹالیشن اور کنفیگریشن فراہم کرتے ہیں، کچھ تو کلائنٹس کی رہنمائی والے سیٹ اپ اور نگرانی کے لیے گرافیکل انٹرفیس بھی پیش کرتے ہیں۔ + +ذیل میں کچھ منصوبے ہیں جو آپ کو صرف چند کلکس کے ساتھ کلائنٹس کو انسٹال اور کنٹرول کرنے میں مدد کرسکتے ہیں: + +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNode صرف ایک وینڈر سے مشین کے ساتھ نہیں آتا ہے۔ سافٹ ویئر، اصل نوڈ لانچر اور بہت سی خصوصیات والا کنٹرول سینٹر کسی بھی ہارڈویئر پر استعمال کیا جا سکتا ہے۔ +- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) - ایک مکمل نوڈ قائم کرنے کا تیز ترین اور آسان ترین طریقہ۔ ون لائنر سیٹ اپ ٹول اور نوڈ مینجمنٹ TUI۔ مفت۔ اوپن سورس۔ سولو اسٹیکرز کے ذریعہ ایتھریم کے لیے عوامی سامان۔ ARM64 اور AMD64 سپورٹ۔ +- [eth-docker](https://eth-docker.net/) - Docker کا استعمال کرتے ہوئے خودکار سیٹ اپ جو آسان اور محفوظ اسٹیکنگ پر مرکوز ہے، اس کے لیے بنیادی ٹرمینل اور Docker علم کی ضرورت ہے، جو تھوڑے زیادہ جدید صارفین کے لیے تجویز کیا جاتا ہے۔ +- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) - ایک GUI سیٹ اپ گائیڈ، کنٹرول سینٹر، اور بہت سی دیگر خصوصیات کے ساتھ SSH کنکشن کے ذریعے ریموٹ سرور پر کلائنٹس کو انسٹال کرنے کے لیے لانچر۔ +- [NiceNode](https://www.nicenode.xyz/) - آپ کے کمپیوٹر پر نوڈ چلانے کے لیے سیدھے صارف کے تجربے کے ساتھ لانچر۔ بس کلائنٹس کا انتخاب کریں اور انہیں چند کلکس کے ساتھ شروع کریں۔ ابھی بھی ترقی میں ہے۔ +- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - نوڈ سیٹ اپ ٹول جو CLI وزرڈ کا استعمال کرتے ہوئے خود بخود Docker کنفیگریشن تیار کرتا ہے۔ Nethermind کے ذریعہ Go میں لکھا گیا ہے۔ + +### دستی کلائنٹس سیٹ اپ {#manual-setup} + +دوسرا آپشن کلائنٹ سافٹ ویئر کو دستی طور پر ڈاؤن لوڈ، تصدیق اور کنفیگر کرنا ہے۔ یہاں تک کہ اگر کچھ کلائنٹس گرافیکل انٹرفیس پیش کرتے ہیں، تب بھی دستی سیٹ اپ کے لیے ٹرمینل کے ساتھ بنیادی مہارت کی ضرورت ہوتی ہے لیکن یہ بہت زیادہ استعداد پیش کرتا ہے۔ + +جیسا کہ پہلے وضاحت کی گئی ہے، اپنا ایتھریم نوڈ قائم کرنے کے لیے کنسینسس اور ایگزیکیوشن کلائنٹس کی ایک جوڑی چلانے کی ضرورت ہوگی۔ کچھ کلائنٹس میں دوسری قسم کا لائٹ کلائنٹ شامل ہوسکتا ہے اور بغیر کسی دوسرے سافٹ ویئر کی ضرورت کے مطابقت پذیر ہوسکتا ہے۔ تاہم، مکمل طور پر ٹرس ٹلیس تصدیق کے لیے دونوں نفاذ کی ضرورت ہوتی ہے۔ + +#### کلائنٹ سافٹ ویئر حاصل کرنا {#getting-the-client} + +سب سے پہلے، آپ کو اپنا ترجیحی [ایگزیکیوشن کلائنٹ](/developers/docs/nodes-and-clients/#execution-clients) اور [کنسینسس کلائنٹ](/developers/docs/nodes-and-clients/#consensus-clients) سافٹ ویئر حاصل کرنے کی ضرورت ہے۔ + +آپ آسانی سے ایک قابل عمل ایپلیکیشن یا انسٹالیشن پیکیج ڈاؤن لوڈ کرسکتے ہیں جو آپ کے آپریٹنگ سسٹم اور فن تعمیر کے مطابق ہو۔ ڈاؤن لوڈ کردہ پیکجوں کے دستخطوں اور چیکسم کی ہمیشہ تصدیق کریں۔ کچھ کلائنٹس آسان تنصیب اور اپ ڈیٹس کے لیے ریپوزٹریز یا Docker امیجز بھی پیش کرتے ہیں۔ تمام کلائنٹس اوپن سورس ہیں، لہذا آپ انہیں سورس سے بھی بنا سکتے ہیں۔ یہ ایک زیادہ جدید طریقہ ہے، لیکن کچھ معاملات میں، اس کی ضرورت ہوسکتی ہے۔ + +ہر کلائنٹ کو انسٹال کرنے کی ہدایات اوپر دی گئی کلائنٹ فہرستوں میں منسلک دستاویزات میں فراہم کی گئی ہیں۔ + +یہاں کلائنٹس کے ریلیز صفحات ہیں جہاں آپ ان کے پہلے سے بنے ہوئے بائنریز یا انسٹالیشن پر ہدایات تلاش کرسکتے ہیں: + +##### ایگزیکیوشن کلائنٹس + +- [Besu](https://github.com/hyperledger/besu/releases) +- [Erigon](https://github.com/ledgerwatch/erigon/releases) +- [Geth](https://geth.ethereum.org/downloads/) +- [Nethermind](https://downloads.nethermind.io/) +- [Reth](https://reth.rs/installation/installation.html) + +یہ بھی قابل ذکر ہے کہ کلائنٹ کا تنوع [ایگزیکیوشن لیئر](/developers/docs/nodes-and-clients/client-diversity/#execution-layer) پر ایک مسئلہ ہے۔ یہ سفارش کی جاتی ہے کہ قارئین اقلیتی ایگزیکیوشن کلائنٹ چلانے پر غور کریں۔ + +##### کنسینسس کلائنٹس + +- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) +- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source) (پہلے سے بنایا ہوا بائنری فراہم نہیں کرتا، صرف Docker امیج یا سورس سے بنانے کے لیے) +- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) +- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) +- [Teku](https://github.com/ConsenSys/teku/releases) + +ویلیڈیٹرز چلانے والے کنسینسس نوڈس کے لیے [کلائنٹ ڈائیورسٹی](/developers/docs/nodes-and-clients/client-diversity/) بہت اہم ہے۔ اگر ویلیڈیٹرز کی اکثریت ایک ہی کلائنٹ کے نفاذ کو چلا رہی ہے، تو نیٹ ورک کی سیکیورٹی خطرے میں ہے۔ لہذا یہ سفارش کی جاتی ہے کہ اقلیتی کلائنٹ کو منتخب کرنے پر غور کریں۔ + +[تازہ ترین نیٹ ورک کلائنٹ کے استعمال کو دیکھیں](https://clientdiversity.org/) اور [کلائنٹ ڈائیورسٹی](/developers/docs/nodes-and-clients/client-diversity) کے بارے میں مزید جانیں۔ + +##### سافٹ ویئر کی تصدیق + +انٹرنیٹ سے سافٹ ویئر ڈاؤن لوڈ کرتے وقت، اس کی سالمیت کی تصدیق کرنے کی سفارش کی جاتی ہے۔ یہ قدم اختیاری ہے لیکن خاص طور پر ایتھریم کلائنٹ جیسے اہم انفراسٹرکچر کے ٹکڑے کے ساتھ، ممکنہ حملے کے ویکٹرز سے آگاہ ہونا اور ان سے بچنا ضروری ہے۔ اگر آپ نے پہلے سے بنایا ہوا بائنری ڈاؤن لوڈ کیا ہے، تو آپ کو اس پر بھروسہ کرنے کی ضرورت ہے اور یہ خطرہ مول لینا ہوگا کہ کوئی حملہ آور قابل عمل کو کسی بدنیتی پر مبنی سے بدل سکتا ہے۔ + +ڈویلپرز اپنی PGP کلیدوں کے ساتھ جاری کردہ بائنریز پر دستخط کرتے ہیں تاکہ آپ کرپٹوگرافک طور پر تصدیق کرسکیں کہ آپ بالکل وہی سافٹ ویئر چلا رہے ہیں جو انہوں نے بنایا ہے۔ آپ کو صرف ڈویلپرز کے ذریعہ استعمال ہونے والی عوامی کلیدیں حاصل کرنے کی ضرورت ہے، جو کلائنٹ ریلیز صفحات پر یا دستاویزات میں مل سکتی ہیں۔ کلائنٹ ریلیز اور اس کے دستخط کو ڈاؤن لوڈ کرنے کے بعد، آپ آسانی سے ان کی تصدیق کے لیے PGP نفاذ، جیسے [GnuPG](https://gnupg.org/download/index.html) کا استعمال کرسکتے ہیں۔ [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) یا [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/) پر `gpg` کا استعمال کرتے ہوئے اوپن سورس سافٹ ویئر کی تصدیق پر ایک ٹیوٹوریل دیکھیں۔ + +تصدیق کی ایک اور شکل یہ یقینی بنانا ہے کہ آپ کے ڈاؤن لوڈ کردہ سافٹ ویئر کا ہیش، ایک منفرد کرپٹوگرافک فنگر پرنٹ، ڈویلپرز کے ذریعہ فراہم کردہ سے میل کھاتا ہے۔ یہ PGP استعمال کرنے سے بھی آسان ہے، اور کچھ کلائنٹس صرف یہ آپشن پیش کرتے ہیں۔ بس ڈاؤن لوڈ کردہ سافٹ ویئر پر ہیش فنکشن چلائیں اور اسے ریلیز صفحہ سے موازنہ کریں۔ مثال کے طور پر: + +```sh +sha256sum teku-22.6.1.tar.gz + +9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde +``` + +#### کلائنٹ سیٹ اپ {#client-setup} + +کلائنٹ سافٹ ویئر کو انسٹال، ڈاؤن لوڈ، یا مرتب کرنے کے بعد، آپ اسے چلانے کے لیے تیار ہیں۔ اس کا صرف یہ مطلب ہے کہ اسے مناسب ترتیب کے ساتھ عمل میں لایا جانا چاہئے۔ کلائنٹس بھرپور ترتیب کے اختیارات پیش کرتے ہیں، جو مختلف خصوصیات کو فعال کرسکتے ہیں۔ + +آئیے ان اختیارات سے شروع کریں جو کلائنٹ کی کارکردگی اور ڈیٹا کے استعمال کو نمایاں طور پر متاثر کرسکتے ہیں۔ [مطابقت پذیری کے طریقوں](/developers/docs/nodes-and-clients/#sync-modes) بلاکچین ڈیٹا کو ڈاؤن لوڈ کرنے اور اس کی توثیق کرنے کے مختلف طریقوں کی نمائندگی کرتے ہیں۔ نوڈ شروع کرنے سے پہلے، آپ کو یہ فیصلہ کرنا چاہئے کہ کون سا نیٹ ورک اور مطابقت پذیری کا موڈ استعمال کرنا ہے۔ غور کرنے کے لیے سب سے اہم چیزیں ڈسک کی جگہ، اور کلائنٹ کو درکار مطابقت پذیری کا وقت ہیں۔ کلائنٹ کی دستاویزات پر توجہ دیں تاکہ یہ تعین کیا جاسکے کہ کون سا مطابقت پذیری کا موڈ ڈیفالٹ ہے۔ اگر یہ آپ کے لیے موزوں نہیں ہے، تو سیکیورٹی کی سطح، دستیاب ڈیٹا، اور لاگت کی بنیاد پر دوسرا انتخاب کریں۔ مطابقت پذیری الگورتھم کے علاوہ، آپ مختلف قسم کے پرانے ڈیٹا کی کٹائی بھی ترتیب دے سکتے ہیں۔ کٹائی پرانے ڈیٹا کو حذف کرنے کے قابل بناتی ہے، یعنی، ریاستی ٹرائی نوڈس کو ہٹانا جو حالیہ بلاکس سے ناقابل رسائی ہیں۔ + +دیگر بنیادی کنفیگریشن آپشنز ہیں، مثلاً، نیٹ ورک کا انتخاب - مین نیٹ یا ٹیسٹ نیٹ، RPC یا WebSockets کے لیے HTTP اینڈ پوائنٹ کو فعال کرنا، وغیرہ۔ آپ کلائنٹ کی دستاویزات میں تمام خصوصیات اور اختیارات تلاش کرسکتے ہیں۔ مختلف کلائنٹ کنفیگریشنز کو CLI یا کنفگ فائل میں براہ راست متعلقہ جھنڈوں کے ساتھ کلائنٹ کو چلا کر ترتیب دیا جاسکتا ہے۔ ہر کلائنٹ تھوڑا مختلف ہے؛ براہ کرم کنفگ کے اختیارات پر تفصیلات کے لیے ہمیشہ اس کی سرکاری دستاویزات یا مدد کے صفحے سے رجوع کریں۔ + +جانچ کے مقاصد کے لیے، آپ ٹیسٹ نیٹ نیٹ ورکس میں سے کسی ایک پر کلائنٹ چلانا پسند کرسکتے ہیں۔ [تعاون یافتہ نیٹ ورکس کا جائزہ دیکھیں](/developers/docs/nodes-and-clients/#execution-clients)۔ + +بنیادی ترتیب کے ساتھ ایگزیکیوشن کلائنٹس چلانے کی مثالیں اگلے حصے میں مل سکتی ہیں۔ + +#### ایگزیکیوشن کلائنٹ شروع کرنا {#starting-the-execution-client} + +ایتھریم کلائنٹ سافٹ ویئر شروع کرنے سے پہلے، آخری بار چیک کریں کہ آپ کا ماحول تیار ہے۔ مثال کے طور پر، یقینی بنائیں: + +- منتخب نیٹ ورک اور مطابقت پذیری کے موڈ کو مدنظر رکھتے ہوئے کافی ڈسک کی جگہ موجود ہے۔ +- میموری اور سی پی یو دوسرے پروگراموں سے رکے نہیں ہیں۔ +- آپریٹنگ سسٹم تازہ ترین ورژن پر اپ ڈیٹ ہے۔ +- سسٹم کا وقت اور تاریخ درست ہے۔ +- آپ کا راؤٹر اور فائر وال سننے والے پورٹس پر کنکشن قبول کرتے ہیں۔ پہلے سے طے شدہ طور پر ایتھریم کلائنٹس ایک سننے والے (TCP) پورٹ اور ایک دریافت (UDP) پورٹ کا استعمال کرتے ہیں، دونوں پہلے سے طے شدہ طور پر 30303 پر ہیں۔ + +یہ یقینی بنانے میں مدد کے لیے کہ سب کچھ ٹھیک سے کام کر رہا ہے، اپنے کلائنٹ کو پہلے ٹیسٹ نیٹ پر چلائیں۔ + +آپ کو کسی بھی کلائنٹ کی ترتیبات کا اعلان کرنے کی ضرورت ہے جو شروع میں ڈیفالٹ نہیں ہیں۔ آپ اپنی ترجیحی کنفیگریشن کا اعلان کرنے کے لیے جھنڈوں یا کنفگ فائل کا استعمال کرسکتے ہیں۔ ہر کلائنٹ کی خصوصیات اور کنفگ نحو کا سیٹ مختلف ہوتا ہے۔ تفصیلات کے لیے اپنے کلائنٹ کی دستاویزات دیکھیں۔ + +ایگزیکیوشن اور کنسینسس کلائنٹس [انجن API](https://github.com/ethereum/execution-apis/tree/main/src/engine) میں بیان کردہ ایک مستند اینڈ پوائنٹ کے ذریعے بات چیت کرتے ہیں۔ کنسینسس کلائنٹ سے جڑنے کے لیے، ایگزیکیوشن کلائنٹ کو ایک معلوم راستے پر [`jwtsecret`](https://jwt.io/) بنانا ہوگا۔ سیکیورٹی اور استحکام کی وجوہات کی بنا پر، کلائنٹس کو ایک ہی مشین پر چلنا چاہیے، اور دونوں کلائنٹس کو یہ راستہ معلوم ہونا چاہیے کیونکہ یہ ان کے درمیان مقامی RPC کنکشن کی تصدیق کے لیے استعمال ہوتا ہے۔ ایگزیکیوشن کلائنٹ کو مستند APIs کے لیے ایک سننے والا پورٹ بھی متعین کرنا ہوگا۔ + +یہ ٹوکن کلائنٹ سافٹ ویئر کے ذریعہ خود بخود تیار ہوتا ہے، لیکن کچھ معاملات میں، آپ کو اسے خود کرنے کی ضرورت پڑسکتی ہے۔ آپ اسے [OpenSSL](https://www.openssl.org/) کا استعمال کرتے ہوئے بنا سکتے ہیں: + +```sh +openssl rand -hex 32 > jwtsecret +``` + +#### ایک ایگزیکیوشن کلائنٹ چلانا {#running-an-execution-client} + +یہ سیکشن آپ کو ایگزیکیوشن کلائنٹس شروع کرنے میں رہنمائی کرے گا۔ یہ صرف ایک بنیادی کنفیگریشن کی مثال کے طور پر کام کرتا ہے، جو کلائنٹ کو ان ترتیبات کے ساتھ شروع کرے گا: + +- جڑنے کے لیے نیٹ ورک کی وضاحت کرتا ہے، ہماری مثالوں میں مین نیٹ + - آپ اس کے بجائے اپنے سیٹ اپ کی ابتدائی جانچ کے لیے [ٹیسٹ نیٹس میں سے ایک](/developers/docs/networks/) کا انتخاب کرسکتے ہیں +- ڈیٹا ڈائرکٹری کی وضاحت کرتا ہے، جہاں بلاکچین سمیت تمام ڈیٹا ذخیرہ کیا جائے گا + - راستے کو کسی حقیقی سے بدلنا یقینی بنائیں، مثلاً، آپ کی بیرونی ڈرائیو کی طرف اشارہ کرتے ہوئے +- کلائنٹ کے ساتھ بات چیت کے لیے انٹرفیس کو فعال کرتا ہے + - کنسینسس کلائنٹ کے ساتھ مواصلات کے لیے JSON-RPC اور انجن API سمیت +- مستند API کے لیے `jwtsecret` کا راستہ بیان کرتا ہے + - مثال کے راستے کو کسی حقیقی سے بدلنا یقینی بنائیں جس تک کلائنٹس رسائی حاصل کرسکیں، مثلاً، `/tmp/jwtsecret` + +براہ کرم ذہن میں رکھیں کہ یہ صرف ایک بنیادی مثال ہے، باقی تمام ترتیبات ڈیفالٹ پر سیٹ کی جائیں گی۔ ہر کلائنٹ کی دستاویزات پر توجہ دیں تاکہ ڈیفالٹ اقدار، ترتیبات، اور خصوصیات کے بارے میں جان سکیں۔ مزید خصوصیات کے لیے، مثال کے طور پر ویلیڈیٹرز چلانے، نگرانی وغیرہ کے لیے، براہ کرم مخصوص کلائنٹ کی دستاویزات سے رجوع کریں۔ + +> نوٹ کریں کہ مثالوں میں بیک سلیش `` صرف فارمیٹنگ کے مقاصد کے لیے ہیں؛ کنفگ جھنڈوں کو ایک ہی لائن میں بیان کیا جاسکتا ہے۔ + +##### Besu چلانا + +یہ مثال مین نیٹ پر Besu شروع کرتی ہے، بلاکچین ڈیٹا کو `/data/ethereum` پر ڈیفالٹ فارمیٹ میں ذخیرہ کرتی ہے، کنسینسس کلائنٹ کو جوڑنے کے لیے JSON-RPC اور انجن RPC کو فعال کرتی ہے۔ انجن API ٹوکن `jwtsecret` کے ساتھ مستند ہے اور صرف `localhost` سے کالز کی اجازت ہے۔ + +```sh +besu --network=mainnet \ + --data-path=/data/ethereum \ + --rpc-http-enabled=true \ + --engine-rpc-enabled=true \ + --engine-host-allowlist="*" \ + --engine-jwt-enabled=true \ + --engine-jwt-secret=/path/to/jwtsecret +``` + +Besu ایک لانچر آپشن کے ساتھ بھی آتا ہے جو سوالات کی ایک سیریز پوچھے گا اور کنفگ فائل بنائے گا۔ انٹرایکٹو لانچر چلائیں: + +```sh +besu --Xlauncher +``` + +[Besu کی دستاویزات](https://besu.hyperledger.org/public-networks/get-started/start-node/) اضافی اختیارات اور کنفیگریشن کی تفصیلات پر مشتمل ہیں۔ + +##### Erigon چلانا + +یہ مثال مین نیٹ پر Erigon شروع کرتی ہے، بلاکچین ڈیٹا کو `/data/ethereum` پر ذخیرہ کرتی ہے، JSON-RPC کو فعال کرتی ہے، بیان کرتی ہے کہ کن نیم اسپیسز کی اجازت ہے اور کنسینسس کلائنٹ کو جوڑنے کے لیے تصدیق کو فعال کرتی ہے جس کی تعریف `jwtsecret` راستے سے کی گئی ہے۔ + +```sh +erigon --chain mainnet \ + --datadir /data/ethereum \ + --http --http.api=engine,eth,web3,net \ + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Erigon ڈیفالٹ کے طور پر 8GB HDD کے ساتھ مکمل مطابقت پذیری کرتا ہے جس کے نتیجے میں 2TB سے زیادہ آرکائیو ڈیٹا ہوگا۔ یقینی بنائیں کہ `datadir` کافی خالی جگہ والی ڈسک کی طرف اشارہ کر رہا ہے یا `--prune` جھنڈے کو دیکھیں جو مختلف قسم کے ڈیٹا کو تراش سکتا ہے۔ مزید جاننے کے لیے Erigon کی `--help` دیکھیں۔ + +##### Geth چلانا + +یہ مثال مین نیٹ پر Geth شروع کرتی ہے، بلاکچین ڈیٹا کو `/data/ethereum` پر ذخیرہ کرتی ہے، JSON-RPC کو فعال کرتی ہے اور بیان کرتی ہے کہ کن نیم اسپیسز کی اجازت ہے۔ یہ کنسینسس کلائنٹ کو جوڑنے کے لیے تصدیق کو بھی فعال کرتا ہے جس کے لیے `jwtsecret` کا راستہ اور یہ بھی آپشن درکار ہے کہ کن کنکشنز کی اجازت ہے، ہماری مثال میں صرف `localhost` سے۔ + +```sh +geth --mainnet \ + --datadir "/data/ethereum" \ + --http --authrpc.addr localhost \ + --authrpc.vhosts="localhost" \ + --authrpc.port 8551 + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +تمام کنفیگریشن آپشنز کے لیے [دستاویزات](https://geth.ethereum.org/docs/fundamentals/command-line-options) دیکھیں اور [کنسینسس کلائنٹ کے ساتھ Geth چلانے](https://geth.ethereum.org/docs/getting-started/consensus-clients) کے بارے میں مزید جانیں۔ + +##### Nethermind چلانا + +Nethermind مختلف [انسٹالیشن کے اختیارات](https://docs.nethermind.io/get-started/installing-nethermind) پیش کرتا ہے۔ پیکیج مختلف بائنریز کے ساتھ آتا ہے، بشمول ایک گائیڈڈ سیٹ اپ والا لانچر، جو آپ کو انٹرایکٹو طور پر کنفیگریشن بنانے میں مدد کرے گا۔ متبادل کے طور پر، آپ کو رنر ملتا ہے جو خود قابل عمل ہے اور آپ اسے صرف کنفگ جھنڈوں کے ساتھ چلا سکتے ہیں۔ JSON-RPC ڈیفالٹ کے طور پر فعال ہے۔ + +```sh +Nethermind.Runner --config mainnet \ + --datadir /data/ethereum \ + --JsonRpc.JwtSecretFile=/path/to/jwtsecret +``` + +Nethermind کی دستاویزات کنسینسس کلائنٹ کے ساتھ Nethermind چلانے پر ایک [مکمل گائیڈ](https://docs.nethermind.io/get-started/running-node/) پیش کرتی ہیں۔ + +ایک ایگزیکیوشن کلائنٹ اپنے بنیادی افعال، منتخب کردہ اینڈ پوائنٹس شروع کرے گا، اور ساتھیوں کی تلاش شروع کردے گا۔ ساتھیوں کو کامیابی سے دریافت کرنے کے بعد، کلائنٹ مطابقت پذیری شروع کردیتا ہے۔ ایگزیکیوشن کلائنٹ کنسینسس کلائنٹ سے کنکشن کا انتظار کرے گا۔ موجودہ بلاکچین ڈیٹا دستیاب ہوگا جب کلائنٹ کامیابی سے موجودہ حالت کے ساتھ مطابقت پذیر ہوجائے گا۔ + +##### Reth چلانا + +یہ مثال مین نیٹ پر Reth شروع کرتی ہے، ڈیفالٹ ڈیٹا لوکیشن کا استعمال کرتے ہوئے۔ کنسینسس کلائنٹ کو جوڑنے کے لیے JSON-RPC اور انجن RPC تصدیق کو فعال کرتا ہے جس کی تعریف `jwtsecret` راستے سے کی گئی ہے، صرف `localhost` سے کالز کی اجازت ہے۔ + +```sh +reth node \ + --authrpc.jwtsecret /path/to/jwtsecret \ + --authrpc.addr 127.0.0.1 \ + --authrpc.port 8551 +``` + +ڈیفالٹ ڈیٹا ڈائرکٹریز کے بارے میں مزید جاننے کے لیے [Reth کی کنفیگریشن](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) دیکھیں۔ [Reth کی دستاویزات](https://reth.rs/run/mainnet.html) اضافی اختیارات اور کنفیگریشن کی تفصیلات پر مشتمل ہیں۔ + +#### کنسینسس کلائنٹ شروع کرنا {#starting-the-consensus-client} + +کنسینسس کلائنٹ کو ایگزیکیوشن کلائنٹ سے مقامی RPC کنکشن قائم کرنے کے لیے صحیح پورٹ کنفیگریشن کے ساتھ شروع کیا جانا چاہئے۔ کنسینسس کلائنٹس کو بے نقاب ایگزیکیوشن کلائنٹ پورٹ کے ساتھ کنفیگریشن دلیل کے طور پر چلانا ہوگا۔ + +کنسینسس کلائنٹ کو ان کے درمیان RPC کنکشن کی تصدیق کے لیے ایگزیکیوشن کلائنٹ کے `jwt-secret` کے راستے کی بھی ضرورت ہوتی ہے۔ اوپر دی گئی ایگزیکیوشن مثالوں کی طرح، ہر کنسینسس کلائنٹ کا ایک کنفیگریشن جھنڈا ہوتا ہے جو jwt ٹوکن فائل کا راستہ دلیل کے طور پر لیتا ہے۔ یہ ایگزیکیوشن کلائنٹ کو فراہم کردہ `jwtsecret` راستے کے مطابق ہونا چاہئے۔ + +اگر آپ ویلیڈیٹر چلانے کا ارادہ رکھتے ہیں، تو یقینی بنائیں کہ فیس وصول کنندہ کے ایتھریم پتے کی وضاحت کرنے والا کنفیگریشن جھنڈا شامل کریں۔ یہ وہ جگہ ہے جہاں آپ کے ویلیڈیٹر کے لیے ایتھر انعامات جمع ہوتے ہیں۔ ہر کنسینسس کلائنٹ کا ایک آپشن ہوتا ہے، مثلاً، `--suggested-fee-recipient=0xabcd1`، جو دلیل کے طور پر ایک ایتھریم پتہ لیتا ہے۔ + +ٹیسٹ نیٹ پر بیکن نوڈ شروع کرتے وقت، آپ [چیک پوائنٹ سنک](https://notes.ethereum.org/@launchpad/checkpoint-sync) کے لیے عوامی اینڈ پوائنٹ کا استعمال کرکے مطابقت پذیری کے وقت میں نمایاں بچت کرسکتے ہیں۔ + +#### ایک کنسینسس کلائنٹ چلانا {#running-a-consensus-client} + +##### Lighthouse چلانا + +Lighthouse چلانے سے پہلے، [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html) میں اسے انسٹال اور کنفیگر کرنے کے بارے میں مزید جانیں۔ + +```sh +lighthouse beacon_node \ + --network mainnet \ + --datadir /data/ethereum \ + --http \ + --execution-endpoint http://127.0.0.1:8551 \ + --execution-jwt /path/to/jwtsecret +``` + +##### Lodestar چلانا + +Lodestar سافٹ ویئر کو مرتب کرکے یا Docker امیج ڈاؤن لوڈ کرکے انسٹال کریں۔ [دستاویزات](https://chainsafe.github.io/lodestar/) اور مزید جامع [سیٹ اپ گائیڈ](https://hackmd.io/@philknows/rk5cDvKmK) میں مزید جانیں۔ + +```sh +lodestar beacon \ + --dataDir="/data/ethereum" \ + --network=mainnet \ + --eth1.enabled=true \ + --execution.urls="http://127.0.0.1:8551" \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Nimbus چلانا + +Nimbus کنسینسس اور ایگزیکیوشن دونوں کلائنٹس کے ساتھ آتا ہے۔ اسے مختلف آلات پر بھی چلایا جاسکتا ہے یہاں تک کہ بہت معمولی کمپیوٹنگ پاور کے ساتھ بھی۔ +[انحصار اور Nimbus خود انسٹال کرنے](https://nimbus.guide/quick-start.html) کے بعد، آپ اس کا کنسینسس کلائنٹ چلا سکتے ہیں: + +```sh +nimbus_beacon_node \ + --network=mainnet \ + --web3-url=http://127.0.0.1:8551 \ + --rest \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Prysm چلانا + +Prysm ایک اسکرپٹ کے ساتھ آتا ہے جو آسان خودکار انسٹالیشن کی اجازت دیتا ہے۔ تفصیلات [Prysm کی دستاویزات](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/) میں مل سکتی ہیں۔ + +```sh +./prysm.sh beacon-chain \ + --mainnet \ + --datadir /data/ethereum \ + --execution-endpoint=http://localhost:8551 \ + --jwt-secret=/path/to/jwtsecret +``` + +##### Teku چلانا + +```sh +teku --network mainnet \ + --data-path "/data/ethereum" \ + --ee-endpoint http://localhost:8551 \ + --ee-jwt-secret-file "/path/to/jwtsecret" +``` + +جب ایک کنسینسس کلائنٹ ڈیپازٹ کنٹریکٹ کو پڑھنے اور ویلیڈیٹرز کی شناخت کے لیے ایگزیکیوشن کلائنٹ سے جڑتا ہے، تو یہ دوسرے بیکن نوڈ ساتھیوں سے بھی جڑتا ہے اور جینیسس سے کنسینسس سلاٹس کی مطابقت پذیری شروع کردیتا ہے۔ ایک بار جب بیکن نوڈ موجودہ عہد تک پہنچ جاتا ہے، تو بیکن API آپ کے ویلیڈیٹرز کے لیے قابل استعمال ہوجاتا ہے۔ [بیکن نوڈ APIs](https://eth2docs.vercel.app/) کے بارے میں مزید جانیں۔ + +### ویلیڈیٹرز شامل کرنا {#adding-validators} + +ایک کنسینسس کلائنٹ ویلیڈیٹرز کے جڑنے کے لیے بیکن نوڈ کے طور پر کام کرتا ہے۔ ہر کنسینسس کلائنٹ کا اپنا ویلیڈیٹر سافٹ ویئر ہوتا ہے جس کی تفصیل اس کی متعلقہ دستاویزات میں دی گئی ہے۔ + +اپنا ویلیڈیٹر چلانے سے [سولو اسٹیکنگ](/staking/solo/) کی اجازت ملتی ہے، جو ایتھریم نیٹ ورک کو سپورٹ کرنے کا سب سے زیادہ بااثر اور ٹرس ٹلیس طریقہ ہے۔ تاہم، اس کے لیے 32 ETH کی جمع رقم درکار ہے۔ کم رقم کے ساتھ اپنے نوڈ پر ویلیڈیٹر چلانے کے لیے، ایک غیر مرکزی پول جس میں اجازت کے بغیر نوڈ آپریٹرز ہوں، جیسے کہ [Rocket Pool](https://rocketpool.net/node-operators)، آپ کو دلچسپی دے سکتا ہے۔ + +اسٹیکنگ اور ویلیڈیٹر کلیدی جنریشن کے ساتھ شروع کرنے کا سب سے آسان طریقہ [Hoodi Testnet Staking Launchpad](https://hoodi.launchpad.ethereum.org/) کا استعمال ہے، جو آپ کو [Hoodi پر نوڈس چلا کر](https://notes.ethereum.org/@launchpad/hoodi) اپنے سیٹ اپ کی جانچ کرنے کی اجازت دیتا ہے۔ جب آپ مین نیٹ کے لیے تیار ہوں، تو آپ [مین نیٹ اسٹیکنگ لانچ پیڈ](https://launchpad.ethereum.org/) کا استعمال کرتے ہوئے ان اقدامات کو دہرا سکتے ہیں۔ + +اسٹیکنگ کے اختیارات کے بارے میں ایک جائزہ کے لیے [اسٹیکنگ پیج](/staking) دیکھیں۔ + +### نوڈ کا استعمال {#using-the-node} + +ایگزیکیوشن کلائنٹس [RPC API اینڈ پوائنٹس](/developers/docs/apis/json-rpc/) پیش کرتے ہیں جنہیں آپ لین دین جمع کروانے، ایتھریم نیٹ ورک پر اسمارٹ معاہدوں کے ساتھ بات چیت کرنے یا ان کو تعینات کرنے کے لیے مختلف طریقوں سے استعمال کرسکتے ہیں: + +- ایک مناسب پروٹوکول کے ساتھ انہیں دستی طور پر کال کرنا (مثلاً، `curl` کا استعمال کرتے ہوئے) +- فراہم کردہ کنسول کو منسلک کرنا (مثلاً، `geth attach`) +- ویب 3 لائبریریوں کا استعمال کرتے ہوئے انہیں ایپلی کیشنز میں نافذ کرنا، مثلاً، [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)، [ethers](https://github.com/ethers-io/ethers.js/) + +مختلف کلائنٹس کے پاس RPC اینڈ پوائنٹس کے مختلف نفاذ ہوتے ہیں۔ لیکن ایک معیاری JSON-RPC ہے جسے آپ ہر کلائنٹ کے ساتھ استعمال کرسکتے ہیں۔ ایک جائزہ کے لیے [JSON-RPC دستاویزات](/developers/docs/apis/json-rpc/) پڑھیں۔ وہ ایپلی کیشنز جنہیں ایتھریم نیٹ ورک سے معلومات کی ضرورت ہوتی ہے وہ اس RPC کا استعمال کرسکتی ہیں۔ مثال کے طور پر، مقبول والیٹ MetaMask آپ کو [اپنے RPC اینڈ پوائنٹ سے جڑنے](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) کی اجازت دیتا ہے جس کے مضبوط رازداری اور سیکیورٹی فوائد ہیں۔ + +کنسینسس کلائنٹس سبھی ایک [بیکن API](https://ethereum.github.io/beacon-APIs) کو بے نقاب کرتے ہیں جسے کنسینسس کلائنٹ کی حیثیت کی جانچ کرنے یا بلاکس اور کنسینسس ڈیٹا کو ڈاؤن لوڈ کرنے کے لیے [Curl](https://curl.se) جیسے ٹولز کا استعمال کرتے ہوئے درخواستیں بھیج کر استعمال کیا جاسکتا ہے۔ اس بارے میں مزید معلومات ہر کنسینسس کلائنٹ کی دستاویزات میں مل سکتی ہیں۔ + +#### RPC تک پہنچنا {#reaching-rpc} + +ایگزیکیوشن کلائنٹ JSON-RPC کے لیے ڈیفالٹ پورٹ `8545` ہے لیکن آپ کنفیگریشن میں مقامی اینڈ پوائنٹس کے پورٹس کو تبدیل کرسکتے ہیں۔ پہلے سے طے شدہ طور پر، RPC انٹرفیس صرف آپ کے کمپیوٹر کے لوکل ہوسٹ پر قابل رسائی ہے۔ اسے دور سے قابل رسائی بنانے کے لیے، آپ اسے پتے کو `0.0.0.0` میں تبدیل کرکے عوام کے لیے بے نقاب کرنا چاہیں گے۔ یہ اسے مقامی نیٹ ورک اور عوامی IP پتوں پر قابل رسائی بنا دے گا۔ زیادہ تر معاملات میں آپ کو اپنے راؤٹر پر پورٹ فارورڈنگ ترتیب دینے کی بھی ضرورت ہوگی۔ + +انٹرنیٹ پر پورٹس کو بے نقاب کرنے کے نقطہ نظر سے احتیاط برتیں کیونکہ یہ انٹرنیٹ پر کسی کو بھی آپ کے نوڈ کو کنٹرول کرنے دے گا۔ بدنیتی پر مبنی اداکار آپ کے سسٹم کو نیچے لانے یا آپ کے فنڈز چوری کرنے کے لیے آپ کے نوڈ تک رسائی حاصل کرسکتے ہیں اگر آپ اپنے کلائنٹ کو والیٹ کے طور پر استعمال کر رہے ہیں۔ + +اس سے بچنے کا ایک طریقہ یہ ہے کہ ممکنہ طور پر نقصان دہ RPC طریقوں کو قابل ترمیم ہونے سے روکا جائے۔ مثال کے طور پر، Geth کے ساتھ، آپ جھنڈے کے ساتھ قابل ترمیم طریقوں کا اعلان کرسکتے ہیں: `--http.api web3,eth,txpool`۔ + +RPC انٹرفیس تک رسائی کو ایج لیئر APIs یا ویب سرور ایپلی کیشنز، جیسے Nginx، کی ترقی کے ذریعے بڑھایا جاسکتا ہے، اور انہیں آپ کے کلائنٹ کے مقامی پتے اور پورٹ سے جوڑ کر۔ ایک درمیانی پرت کا فائدہ اٹھانا ڈویلپرز کو RPC انٹرفیس سے محفوظ `https` کنکشن کے لیے سرٹیفکیٹ ترتیب دینے کی صلاحیت بھی دے سکتا ہے۔ + +ایک ویب سرور، ایک پراکسی، یا بیرونی سامنا کرنے والی Rest API کو ترتیب دینا آپ کے نوڈ کے RPC اینڈ پوائنٹ تک رسائی فراہم کرنے کا واحد طریقہ نہیں ہے۔ عوامی طور پر قابل رسائی اینڈ پوائنٹ ترتیب دینے کا ایک اور رازداری کو محفوظ رکھنے والا طریقہ یہ ہے کہ نوڈ کو اپنی [Tor](https://www.torproject.org/) پیاز سروس پر میزبانی کی جائے۔ یہ آپ کو اپنے مقامی نیٹ ورک سے باہر RPC تک پہنچنے دے گا بغیر جامد عوامی IP پتے یا کھلے پورٹس کے۔ تاہم، اس کنفیگریشن کا استعمال صرف RPC اینڈ پوائنٹ کو Tor نیٹ ورک کے ذریعے قابل رسائی بنا سکتا ہے جو تمام ایپلی کیشنز کے ذریعہ تعاون یافتہ نہیں ہے اور اس کے نتیجے میں کنکشن کے مسائل پیدا ہوسکتے ہیں۔ + +ایسا کرنے کے لیے، آپ کو اپنی [پیاز سروس](https://community.torproject.org/onion-services/) بنانی ہوگی۔ اپنی میزبانی کے لیے پیاز سروس سیٹ اپ پر [دستاویزات](https://community.torproject.org/onion-services/setup/) دیکھیں۔ آپ اسے RPC پورٹ پر پراکسی کے ساتھ ویب سرور کی طرف اشارہ کرسکتے ہیں یا صرف براہ راست RPC کی طرف۔ + +آخر میں، اور اندرونی نیٹ ورکس تک رسائی فراہم کرنے کے سب سے مشہور طریقوں میں سے ایک VPN کنکشن کے ذریعے ہے۔ آپ کے استعمال کے کیس اور آپ کے نوڈ تک رسائی کی ضرورت والے صارفین کی تعداد پر منحصر ہے، ایک محفوظ VPN کنکشن ایک آپشن ہوسکتا ہے۔ [OpenVPN](https://openvpn.net/) ایک مکمل خصوصیات والا SSL VPN ہے جو صنعت کے معیاری SSL/TLS پروٹوکول کا استعمال کرتے ہوئے OSI پرت 2 یا 3 محفوظ نیٹ ورک توسیع کو نافذ کرتا ہے، سرٹیفکیٹس، اسمارٹ کارڈز، اور/یا صارف نام/پاس ورڈ کی اسناد پر مبنی لچکدار کلائنٹ کی تصدیق کے طریقوں کی حمایت کرتا ہے، اور VPN ورچوئل انٹرفیس پر لاگو فائر وال قوانین کا استعمال کرتے ہوئے صارف یا گروپ مخصوص رسائی کنٹرول پالیسیوں کی اجازت دیتا ہے۔ + +### نوڈ کو چلانا {#operating-the-node} + +آپ کو اپنے نوڈ کی باقاعدگی سے نگرانی کرنی چاہئے تاکہ یہ یقینی بنایا جاسکے کہ یہ ٹھیک سے چل رہا ہے۔ آپ کو کبھی کبھار دیکھ بھال کرنے کی ضرورت پڑسکتی ہے۔ + +#### ایک نوڈ کو آن لائن رکھنا {#keeping-node-online} + +آپ کے نوڈ کو ہر وقت آن لائن رہنے کی ضرورت نہیں ہے، لیکن آپ کو اسے نیٹ ورک کے ساتھ مطابقت پذیر رکھنے کے لیے جتنا ممکن ہو سکے آن لائن رکھنا چاہئے۔ آپ اسے دوبارہ شروع کرنے کے لیے بند کرسکتے ہیں، لیکن ذہن میں رکھیں کہ: + +- اگر حالیہ حالت ابھی بھی ڈسک پر لکھی جارہی ہے تو بند ہونے میں چند منٹ لگ سکتے ہیں۔ +- زبردستی بند کرنے سے ڈیٹا بیس کو نقصان پہنچ سکتا ہے جس کے لیے آپ کو پورے نوڈ کو دوبارہ مطابقت پذیر کرنے کی ضرورت پڑسکتی ہے۔ +- آپ کا کلائنٹ نیٹ ورک سے مطابقت پذیر نہیں رہے گا اور جب آپ اسے دوبارہ شروع کریں گے تو اسے دوبارہ مطابقت پذیر کرنے کی ضرورت ہوگی۔ جبکہ نوڈ جہاں سے آخری بار بند ہوا تھا وہاں سے مطابقت پذیری شروع کرسکتا ہے، اس عمل میں وقت لگ سکتا ہے اس پر منحصر ہے کہ یہ کتنی دیر تک آف لائن رہا ہے۔ + +_یہ کنسینسس لیئر ویلیڈیٹر نوڈس پر لاگو نہیں ہوتا ہے۔_ اپنے نوڈ کو آف لائن لے جانے سے اس پر منحصر تمام خدمات متاثر ہوں گی۔ اگر آپ _اسٹیکنگ_ کے مقاصد کے لیے نوڈ چلا رہے ہیں تو آپ کو ڈاؤن ٹائم کو جتنا ممکن ہو سکے کم کرنے کی کوشش کرنی چاہئے۔ + +#### کلائنٹ خدمات بنانا {#creating-client-services} + +اسٹارٹ اپ پر اپنے کلائنٹس کو خود بخود چلانے کے لیے ایک سروس بنانے پر غور کریں۔ مثال کے طور پر، لینکس سرورز پر، ایک اچھی مشق ایک سروس بنانا ہوگی، مثلاً، `systemd` کے ساتھ، جو کلائنٹ کو مناسب کنفگ کے ساتھ، محدود مراعات والے صارف کے تحت چلاتی ہے اور خود بخود دوبارہ شروع ہوجاتی ہے۔ + +#### کلائنٹس کو اپ ڈیٹ کرنا {#updating-clients} + +آپ کو اپنے کلائنٹ سافٹ ویئر کو تازہ ترین سیکیورٹی پیچ، خصوصیات، اور [EIPs](/eips/) کے ساتھ تازہ ترین رکھنے کی ضرورت ہے۔ خاص طور پر [ہارڈ فورکس](/ethereum-forks/) سے پہلے، یقینی بنائیں کہ آپ صحیح کلائنٹ ورژن چلا رہے ہیں۔ + +> اہم نیٹ ورک اپ ڈیٹس سے پہلے، EF اپنے [بلاگ](https://blog.ethereum.org) پر ایک پوسٹ شائع کرتا ہے۔ آپ [ان اعلانات کو سبسکرائب کرسکتے ہیں](https://blog.ethereum.org/category/protocol#subscribe) تاکہ جب آپ کے نوڈ کو اپ ڈیٹ کی ضرورت ہو تو آپ کے میل پر ایک اطلاع مل سکے۔ + +کلائنٹس کو اپ ڈیٹ کرنا بہت آسان ہے۔ ہر کلائنٹ کی اپنی دستاویزات میں مخصوص ہدایات ہوتی ہیں، لیکن عمل عام طور پر صرف تازہ ترین ورژن ڈاؤن لوڈ کرنا اور نئے قابل عمل کے ساتھ کلائنٹ کو دوبارہ شروع کرنا ہوتا ہے۔ کلائنٹ کو وہاں سے اٹھانا چاہئے جہاں سے اس نے چھوڑا تھا، لیکن اپ ڈیٹس لاگو ہونے کے ساتھ۔ + +ہر کلائنٹ کے نفاذ میں ایک انسانی پڑھنے کے قابل ورژن سٹرنگ ہوتا ہے جو پیئر ٹو پیئر پروٹوکول میں استعمال ہوتا ہے لیکن یہ کمانڈ لائن سے بھی قابل رسائی ہے۔ یہ ورژن سٹرنگ صارفین کو یہ جانچنے کی اجازت دیتا ہے کہ وہ صحیح ورژن چلا رہے ہیں اور بلاک ایکسپلوررز اور دیگر تجزیاتی ٹولز کو نیٹ ورک پر مخصوص کلائنٹس کی تقسیم کی مقدار کا تعین کرنے میں دلچسپی رکھنے کی اجازت دیتا ہے۔ ورژن سٹرنگ کے بارے میں مزید معلومات کے لیے براہ کرم انفرادی کلائنٹ کی دستاویزات سے رجوع کریں۔ + +#### اضافی خدمات چلانا {#running-additional-services} + +اپنا نوڈ چلانے سے آپ کو ایسی خدمات استعمال کرنے کی اجازت ملتی ہے جن کے لیے ایتھریم کلائنٹ RPC تک براہ راست رسائی کی ضرورت ہوتی ہے۔ یہ وہ خدمات ہیں جو ایتھریم کے اوپر بنائی گئی ہیں جیسے [لیئر 2 حل](/developers/docs/scaling/#layer-2-scaling)، والیٹس کے لیے بیک اینڈ، بلاک ایکسپلوررز، ڈویلپر ٹولز اور دیگر ایتھریم انفراسٹرکچر۔ + +#### نوڈ کی نگرانی کرنا {#monitoring-the-node} + +اپنے نوڈ کی مناسب نگرانی کے لیے، میٹرکس جمع کرنے پر غور کریں۔ کلائنٹس میٹرکس اینڈ پوائنٹس فراہم کرتے ہیں تاکہ آپ اپنے نوڈ کے بارے میں جامع ڈیٹا حاصل کرسکیں۔ [InfluxDB](https://www.influxdata.com/get-influxdb/) یا [Prometheus](https://prometheus.io/) جیسے ٹولز کا استعمال کریں تاکہ ڈیٹا بیس بنائے جاسکیں جنہیں آپ [Grafana](https://grafana.com/) جیسے سافٹ ویئر میں ویژولائزیشنز اور چارٹس میں تبدیل کرسکتے ہیں۔ اس سافٹ ویئر کو استعمال کرنے کے لیے بہت سے سیٹ اپ اور مختلف Grafana ڈیش بورڈز ہیں تاکہ آپ اپنے نوڈ اور پورے نیٹ ورک کو دیکھ سکیں۔ مثال کے طور پر، [InfluxDB اور Grafana کے ساتھ Geth کی نگرانی پر ٹیوٹوریل](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/) دیکھیں۔ + +اپنی نگرانی کے حصے کے طور پر، اپنی مشین کی کارکردگی پر نظر رکھنا یقینی بنائیں۔ آپ کے نوڈ کی ابتدائی مطابقت پذیری کے دوران، کلائنٹ سافٹ ویئر سی پی یو اور ریم پر بہت بھاری ہوسکتا ہے۔ Grafana کے علاوہ، آپ اپنے OS کے پیش کردہ ٹولز جیسے `htop` یا `uptime` کا استعمال کرسکتے ہیں۔ + +## مزید پڑھیں {#further-reading} + +- [ایتھریم اسٹیکنگ گائیڈز](https://github.com/SomerEsat/ethereum-staking-guides) - _سومر ایسات، اکثر اپ ڈیٹ ہوتا ہے_ +- [گائیڈ | مین نیٹ پر ایتھریم اسٹیکنگ کے لیے ویلیڈیٹر کیسے سیٹ اپ کریں](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew، اکثر اپ ڈیٹ ہوتا ہے_ +- [ٹیسٹ نیٹس پر ویلیڈیٹرز چلانے پر ETHStaker گائیڈز](https://github.com/remyroy/ethstaker#guides) – _ETHStaker، باقاعدگی سے اپ ڈیٹ ہوتا ہے_ +- [ایتھریم نوڈس کے لیے نمونہ AWS بلاکچین نوڈ رنر ایپ](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) - _AWS، اکثر اپ ڈیٹ ہوتا ہے_ +- [نوڈ آپریٹرز کے لیے The Merge FAQ](https://notes.ethereum.org/@launchpad/node-faq-merge) - _جولائی 2022_ +- [ایتھریم مکمل توثیق شدہ نوڈ بننے کے لیے ہارڈویئر کی ضروریات کا تجزیہ کرنا](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– البرٹ پلاؤ، 24 ستمبر 2018_ +- [ایتھیریم فل نوڈز چلانا: بمشکل حوصلہ افزائی کے لیے ایک گائیڈ](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جسٹن لیروکس، 7 نومبر 2019_ +- [ایتھریم مین نیٹ پر ہائپرلیجر بیسو نوڈ کو تعینات کرنا: فوائد، ضروریات، اور سیٹ اپ](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– فیلیپ فاراگی، 7 مئی 2020_ +- [مانیٹرنگ اسٹیک کے ساتھ نیتھرمائنڈ ایتھریم کلائنٹ کو تعینات کرنا](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth، 8 جولائی 2020_ + +## متعلقہ موضوعات {#related-topics} + +- [نوڈز اور کلائنٹس](/developers/docs/nodes-and-clients/) +- [بلاکس](/developers/docs/blocks/) +- [نیٹ ورکس](/developers/docs/networks/) diff --git a/public/content/translations/ur/developers/docs/oracles/index.md b/public/content/translations/ur/developers/docs/oracles/index.md new file mode 100644 index 00000000000..60048a871c4 --- /dev/null +++ b/public/content/translations/ur/developers/docs/oracles/index.md @@ -0,0 +1,433 @@ +--- +title: "اوریکلز" +description: "اوریکلز Ethereum اسمارٹ کنٹریکٹس کو حقیقی دنیا کے ڈیٹا تک رسائی فراہم کرتے ہیں، جو صارفین کے لیے مزید استعمال کے معاملات اور زیادہ قدر کو کھولتے ہیں۔" +lang: ur-in +--- + +اوریکلز ایسی ایپلی کیشنز ہیں جو ڈیٹا فیڈز تیار کرتی ہیں جو آف چین ڈیٹا کے ذرائع کو اسمارٹ کنٹریکٹس کے لیے بلاک چین پر دستیاب کرتی ہیں۔ یہ ضروری ہے کیونکہ Ethereum پر مبنی اسمارٹ کنٹریکٹس، پہلے سے طے شدہ طور پر، بلاک چین نیٹ ورک کے باہر ذخیرہ شدہ معلومات تک رسائی حاصل نہیں کر سکتے ہیں۔ + +آف چین ڈیٹا کا استعمال کرتے ہوئے اسمارٹ کنٹریکٹس کو عمل درآمد کرنے کی صلاحیت دینا غیر مرکزی ایپلی کیشنز کی افادیت اور قدر کو بڑھاتا ہے۔ مثال کے طور پر، آن چین پیشین گوئی بازار نتائج کے بارے میں معلومات فراہم کرنے کے لیے اوریکلز پر انحصار کرتے ہیں جو وہ صارف کی پیشین گوئیوں کی توثیق کرنے کے لیے استعمال کرتے ہیں۔ فرض کریں کہ ایلس 20 ETH کی شرط لگاتی ہے کہ اگلا امریکی کون بنے گا۔ صدر۔ اس صورت میں، پیشین گوئی-بازار ڈیپ کو انتخابی نتائج کی تصدیق کرنے اور یہ تعین کرنے کے لیے ایک اوریکل کی ضرورت ہے کہ آیا ایلس ادائیگی کے لیے اہل ہے یا نہیں۔ + +## شرائط {#prerequisites} + +یہ صفحہ فرض کرتا ہے کہ قاری Ethereum کی بنیادی باتوں سے واقف ہے، بشمول [nodes](/developers/docs/nodes-and-clients/)، [consensus mechanisms](/developers/docs/consensus-mechanisms/)، اور [EVM](/developers/docs/evm/)۔ آپ کو [smart contracts](/developers/docs/smart-contracts/) اور [smart contract anatomy](/developers/docs/smart-contracts/anatomy/)، خاص طور پر [events](/glossary/#events) کی بھی اچھی سمجھ ہونی چاہیے۔ + +## بلاک چین اوریکل کیا ہے؟ {#what-is-a-blockchain-oracle} + +اوریکلز ایسی ایپلی کیشنز ہیں جو بیرونی معلومات (یعنی، آف چین ذخیرہ شدہ معلومات) کو حاصل کرتی، تصدیق کرتی اور بلاک چین پر چلنے والے اسمارٹ کنٹریکٹس تک منتقل کرتی ہیں۔ آف چین ڈیٹا کو "پل" کرنے اور اسے Ethereum پر نشر کرنے کے علاوہ، اوریکلز بلاک چین سے معلومات کو بیرونی نظاموں میں "پش" بھی کر سکتے ہیں، مثلاً، صارف کے Ethereum ٹرانزیکشن کے ذریعے فیس بھیجنے کے بعد اسمارٹ لاک کو کھولنا۔ + +ایک اوریکل کے بغیر، ایک اسمارٹ کنٹریکٹ مکمل طور پر آن چین ڈیٹا تک محدود ہوگا۔ + +اوریکلز ڈیٹا کے ماخذ (ایک یا ایک سے زیادہ ذرائع)، اعتماد کے ماڈلز (مرکزی یا غیر مرکزی)، اور سسٹم آرکیٹیکچر (فوری-پڑھنا، شائع-سبسکرائب، اور درخواست-جواب) کی بنیاد پر مختلف ہوتے ہیں۔ ہم اوریکلز کے درمیان اس بنیاد پر بھی فرق کر سکتے ہیں کہ آیا وہ آن چین کنٹریکٹس کے استعمال کے لیے بیرونی ڈیٹا حاصل کرتے ہیں (ان پٹ اوریکلز)، بلاک چین سے آف چین ایپلی کیشنز کو معلومات بھیجتے ہیں (آؤٹ پٹ اوریکلز)، یا آف چین کمپیوٹیشنل کام انجام دیتے ہیں (کمپیوٹیشنل اوریکلز)۔ + +## اسمارٹ کنٹریکٹس کو اوریکلز کی ضرورت کیوں ہے؟ {#why-do-smart-contracts-need-oracles} + +بہت سے ڈیولپرز اسمارٹ کنٹریکٹس کو ایسے کوڈ کے طور پر دیکھتے ہیں جو بلاک چین پر مخصوص پتوں پر چل رہا ہے۔ تاہم، [اسمارٹ کنٹریکٹس کا ایک زیادہ عمومی نظریہ](/smart-contracts/) یہ ہے کہ وہ خود کار طریقے سے عمل درآمد کرنے والے سافٹ ویئر پروگرام ہیں جو مخصوص شرائط پوری ہونے پر فریقین کے درمیان معاہدوں کو نافذ کرنے کی صلاحیت رکھتے ہیں - اسی لیے یہ اصطلاح "اسمارٹ کنٹریکٹس" ہے۔ + +لیکن لوگوں کے درمیان معاہدوں کو نافذ کرنے کے لیے اسمارٹ کنٹریکٹس کا استعمال سیدھا سادہ نہیں ہے، اس بات کو دیکھتے ہوئے کہ Ethereum حتمی ہے۔ ایک [حتمی نظام](https://en.wikipedia.org/wiki/Deterministic_algorithm) وہ ہے جو ایک ابتدائی حالت اور ایک مخصوص ان پٹ دیے جانے پر ہمیشہ ایک ہی جیسے نتائج دیتا ہے، جس کا مطلب ہے کہ ان پٹ سے آؤٹ پٹ کا حساب لگانے کے عمل میں کوئی بے ترتیب پن یا تغیر نہیں ہوتا ہے۔ + +حتمی عمل درآمد حاصل کرنے کے لیے، بلاک چینز نوڈس کو _صرف_ بلاک چین پر ہی ذخیرہ شدہ ڈیٹا کا استعمال کرتے ہوئے سادہ بائنری (صحیح/غلط) سوالات پر اتفاق رائے تک پہنچنے تک محدود کرتی ہیں۔ اس طرح کے سوالات کی مثالیں شامل ہیں: + +- "کیا اکاؤنٹ کے مالک (جس کی شناخت ایک پبلک کی سے ہوتی ہے) نے اس ٹرانزیکشن پر جوڑی والی پرائیویٹ کی کے ساتھ دستخط کیا ہے؟" +- "کیا اس اکاؤنٹ میں ٹرانزیکشن کو پورا کرنے کے لیے کافی فنڈز ہیں؟" +- "کیا یہ ٹرانزیکشن اس اسمارٹ کنٹریکٹ کے تناظر میں درست ہے؟"، وغیرہ۔ + +اگر بلاک چینز بیرونی ذرائع (یعنی حقیقی دنیا) سے معلومات حاصل کرتیں، تو حتمیت کو حاصل کرنا ناممکن ہو جاتا، جس سے نوڈس کو بلاک چین کی حالت میں تبدیلیوں کی درستی پر متفق ہونے سے روکا جاتا۔ مثال کے طور پر ایک ایسا اسمارٹ کنٹریکٹ لیں جو ایک روایتی قیمت API سے حاصل کردہ موجودہ ETH-USD ایکسچینج ریٹ کی بنیاد پر ایک ٹرانزیکشن کو عمل میں لاتا ہے۔ اس عدد کے اکثر تبدیل ہونے کا امکان ہے (یہ ذکر نہ کرنا کہ API کو متروک یا ہیک کیا جا سکتا ہے)، جس کا مطلب ہے کہ ایک ہی کنٹریکٹ کوڈ پر عمل درآمد کرنے والے نوڈس مختلف نتائج پر پہنچیں گے۔ + +Ethereum جیسے پبلک بلاک چین کے لیے، جس میں دنیا بھر میں ہزاروں نوڈس ٹرانزیکشنز پر کارروائی کر رہے ہیں، حتمیت بہت اہم ہے۔ سچائی کے منبع کے طور پر کام کرنے والی کوئی مرکزی اتھارٹی نہ ہونے کی وجہ سے، نوڈس کو ایک ہی ٹرانزیکشنز کو لاگو کرنے کے بعد ایک ہی حالت پر پہنچنے کے لیے میکانزم کی ضرورت ہوتی ہے۔ ایک ایسا معاملہ جس میں نوڈ A ایک اسمارٹ کنٹریکٹ کے کوڈ پر عمل درآمد کرتا ہے اور نتیجے کے طور پر "3" حاصل کرتا ہے، جبکہ نوڈ B اسی ٹرانزیکشن کو چلانے کے بعد "7" حاصل کرتا ہے، اتفاق رائے کو توڑنے کا سبب بنے گا اور Ethereum کی قدر کو ایک غیر مرکزی کمپیوٹنگ پلیٹ فارم کے طور پر ختم کر دے گا۔ + +یہ منظر نامہ بیرونی ذرائع سے معلومات حاصل کرنے کے لیے بلاک چینز کو ڈیزائن کرنے کے مسئلے کو بھی اجاگر کرتا ہے۔ تاہم، اوریکلز اس مسئلے کو آف چین ذرائع سے معلومات لے کر اور اسے بلاک چین پر اسمارٹ کنٹریکٹس کے استعمال کے لیے ذخیرہ کر کے حل کرتے ہیں۔ چونکہ آن چین ذخیرہ شدہ معلومات ناقابل تغیر اور عوامی طور پر دستیاب ہیں، Ethereum نوڈس اوریکل سے درآمد کردہ آف چین ڈیٹا کو اتفاق رائے کو توڑے بغیر حالت کی تبدیلیوں کا حساب لگانے کے لیے محفوظ طریقے سے استعمال کر سکتے ہیں۔ + +ایسا کرنے کے لیے، ایک اوریکل عام طور پر ایک اسمارٹ کنٹریکٹ جو آن چین چل رہا ہے اور کچھ آف چین اجزاء پر مشتمل ہوتا ہے۔ آن چین کنٹریکٹ دوسرے اسمارٹ کنٹریکٹس سے ڈیٹا کے لیے درخواستیں وصول کرتا ہے، جسے وہ آف چین جزو (جسے اوریکل نوڈ کہا جاتا ہے) کو بھیجتا ہے۔ یہ اوریکل نوڈ ڈیٹا ذرائع سے استفسار کر سکتا ہے—مثال کے طور پر، ایپلی کیشن پروگرامنگ انٹرفیس (APIs) کا استعمال کرتے ہوئے—اور درخواست کردہ ڈیٹا کو اسمارٹ کنٹریکٹ کے اسٹوریج میں ذخیرہ کرنے کے لیے ٹرانزیکشنز بھیج سکتا ہے۔ + +بنیادی طور پر، ایک بلاک چین اوریکل بلاک چین اور بیرونی ماحول کے درمیان معلوماتی خلا کو پر کرتا ہے، جس سے "ہائبرڈ اسمارٹ کنٹریکٹس" بنتے ہیں۔ ایک ہائبرڈ اسمارٹ کنٹریکٹ وہ ہے جو آن چین کنٹریکٹ کوڈ اور آف چین انفراسٹرکچر کے امتزاج کی بنیاد پر کام کرتا ہے۔ غیر مرکزی پیشین گوئی بازار ہائبرڈ اسمارٹ کنٹریکٹس کی ایک بہترین مثال ہیں۔ دیگر مثالوں میں فصلوں کی بیمہ کے اسمارٹ کنٹریکٹس شامل ہو سکتے ہیں جو اس وقت ادائیگی کرتے ہیں جب اوریکلز کا ایک سیٹ یہ طے کرتا ہے کہ کچھ موسمی مظاہر رونما ہوئے ہیں۔ + +## اوریکل کا مسئلہ کیا ہے؟ {#the-oracle-problem} + +اوریکلز ایک اہم مسئلہ حل کرتے ہیں، لیکن کچھ پیچیدگیاں بھی پیدا کرتے ہیں، مثلاً: + +- ہم یہ کیسے تصدیق کریں کہ داخل کی گئی معلومات صحیح ماخذ سے نکالی گئی ہے یا اس کے ساتھ چھیڑ چھاڑ نہیں کی گئی ہے؟ + +- ہم یہ کیسے یقینی بنائیں کہ یہ ڈیٹا ہمیشہ دستیاب رہے اور باقاعدگی سے اپ ڈیٹ ہوتا رہے؟ + +نام نہاد "اوریکل مسئلہ" ان مسائل کو ظاہر کرتا ہے جو اسمارٹ کنٹریکٹس کو ان پٹ بھیجنے کے لیے بلاک چین اوریکلز کے استعمال سے آتے ہیں۔ ایک اسمارٹ کنٹریکٹ کے صحیح طریقے سے عمل درآمد کرنے کے لیے ایک اوریکل سے حاصل کردہ ڈیٹا کا درست ہونا ضروری ہے۔ مزید یہ کہ، درست معلومات فراہم کرنے کے لیے اوریکل آپریٹرز پر 'بھروسہ' کرنا اسمارٹ کنٹریکٹس کے 'بھروسے کے بغیر' والے پہلو کو کمزور کرتا ہے۔ + +مختلف اوریکلز اوریکل کے مسئلے کے مختلف حل پیش کرتے ہیں، جس پر ہم بعد میں غور کریں گے۔ اوریکلز کا عام طور پر اس بات پر جائزہ لیا جاتا ہے کہ وہ مندرجہ ذیل چیلنجوں سے کتنی اچھی طرح نمٹ سکتے ہیں: + +1. **درستی**: ایک اوریکل کو غلط آف چین ڈیٹا کی بنیاد پر اسمارٹ کنٹریکٹس کو حالت میں تبدیلی لانے کا سبب نہیں بننا چاہیے۔ ایک اوریکل کو ڈیٹا کی _مستند ہونے_ اور _سالمیت_ کی ضمانت دینی چاہیے۔ مستند ہونے کا مطلب ہے کہ ڈیٹا صحیح ماخذ سے حاصل کیا گیا تھا، جبکہ سالمیت کا مطلب ہے کہ آن چین بھیجنے سے پہلے ڈیٹا برقرار رہا (یعنی، اس میں کوئی تبدیلی نہیں کی گئی)۔ + +2. **دستیابی**: ایک اوریکل کو اسمارٹ کنٹریکٹس کو اعمال پر عمل درآمد کرنے اور حالت کی تبدیلیوں کو متحرک کرنے میں تاخیر یا روکنا نہیں چاہیے۔ اس کا مطلب ہے کہ ایک اوریکل سے حاصل کردہ ڈیٹا _درخواست پر_ بغیر کسی رکاوٹ کے دستیاب ہونا چاہیے۔ + +3. **ترغیبی مطابقت**: ایک اوریکل کو آف چین ڈیٹا فراہم کنندگان کو اسمارٹ کنٹریکٹس کو درست معلومات جمع کرانے کی ترغیب دینی چاہیے۔ ترغیبی مطابقت میں _منسوبیت_ اور _جوابدہی_ شامل ہے۔ منسوبیت بیرونی معلومات کے ایک ٹکڑے کو اس کے فراہم کنندہ سے جوڑنے کی اجازت دیتی ہے، جبکہ جوابدہی ڈیٹا فراہم کنندگان کو ان کی دی گئی معلومات سے منسلک کرتی ہے، تاکہ انہیں فراہم کردہ معلومات کے معیار کی بنیاد پر انعام یا سزا دی جا سکے۔ + +## ایک بلاک چین اوریکل سروس کیسے کام کرتی ہے؟ {#how-does-a-blockchain-oracle-service-work} + +### صارفین {#users} + +صارفین وہ ادارے ہیں (یعنی، اسمارٹ کنٹریکٹس) جنہیں مخصوص اعمال کو مکمل کرنے کے لیے بلاک چین سے باہر کی معلومات کی ضرورت ہوتی ہے۔ ایک اوریکل سروس کا بنیادی ورک فلو صارف کے ذریعہ اوریکل کنٹریکٹ کو ڈیٹا کی درخواست بھیجنے سے شروع ہوتا ہے۔ ڈیٹا کی درخواستیں عام طور پر مندرجہ ذیل میں سے کچھ یا تمام سوالات کا جواب دیں گی: + +1. آف چین نوڈس درخواست کردہ معلومات کے لیے کن ذرائع سے مشورہ کر سکتے ہیں؟ + +2. رپورٹرز ڈیٹا کے ذرائع سے معلومات پر کارروائی کیسے کرتے ہیں اور مفید ڈیٹا پوائنٹس کیسے نکالتے ہیں؟ + +3. ڈیٹا حاصل کرنے میں کتنے اوریکل نوڈس حصہ لے سکتے ہیں؟ + +4. اوریکل رپورٹس میں تضادات کا انتظام کیسے کیا جانا چاہیے؟ + +5. گذارشات کو فلٹر کرنے اور رپورٹس کو ایک ہی قدر میں جمع کرنے کے لیے کون سا طریقہ نافذ کیا جانا چاہیے؟ + +### اوریکل کنٹریکٹ {#oracle-contract} + +اوریکل کنٹریکٹ اوریکل سروس کے لیے آن چین جزو ہے۔ یہ دوسرے کنٹریکٹس سے ڈیٹا کی درخواستیں سنتا ہے، ڈیٹا کے سوالات کو اوریکل نوڈس تک پہنچاتا ہے، اور واپس آنے والے ڈیٹا کو کلائنٹ کنٹریکٹس تک نشر کرتا ہے۔ یہ کنٹریکٹ واپس آنے والے ڈیٹا پوائنٹس پر کچھ حساب کتاب بھی کر سکتا ہے تاکہ درخواست کرنے والے کنٹریکٹ کو بھیجنے کے لیے ایک مجموعی قدر پیدا کی جا سکے۔ + +اوریکل کنٹریکٹ کچھ افعال کو ظاہر کرتا ہے جنہیں کلائنٹ کنٹریکٹس ڈیٹا کی درخواست کرتے وقت کال کرتے ہیں۔ ایک نئی استفسار موصول ہونے پر، اسمارٹ کنٹریکٹ ڈیٹا کی درخواست کی تفصیلات کے ساتھ ایک [لاگ ایونٹ](/developers/docs/smart-contracts/anatomy/#events-and-logs) خارج کرے گا۔ یہ لاگ کو سبسکرائب کرنے والے آف چین نوڈس کو مطلع کرتا ہے (عام طور پر JSON-RPC `eth_subscribe` کمانڈ جیسی کسی چیز کا استعمال کرتے ہوئے)، جو لاگ ایونٹ میں بیان کردہ ڈیٹا کو بازیافت کرنے کے لیے آگے بڑھتے ہیں۔ + +ذیل میں پیڈرو کوسٹا کا ایک [مثالی اوریکل کنٹریکٹ](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) ہے۔ یہ ایک سادہ اوریکل سروس ہے جو دوسرے اسمارٹ کنٹریکٹس کی درخواست پر آف چین APIs سے استفسار کر سکتی ہے اور درخواست کردہ معلومات کو بلاک چین پر ذخیرہ کر سکتی ہے۔ + +```solidity +pragma solidity >=0.4.21 <0.6.0; + +contract Oracle { + Request[] requests; //کنٹریکٹ کو کی گئی درخواستوں کی فہرست + uint currentId = 0; //بڑھتی ہوئی درخواست کی آئی ڈی + uint minQuorum = 2; //حتمی نتیجہ قرار دینے سے پہلے موصول ہونے والے جوابات کی کم از کم تعداد + uint totalOracleCount = 3; // ہارڈ کوڈڈ اوریکل کی گنتی + + // ایک عمومی api درخواست کی وضاحت کرتا ہے + struct Request { + uint id; //درخواست کی آئی ڈی + string urlToQuery; //API یو آر ایل + string attributeToFetch; //جواب میں بازیافت کرنے کے لیے json وصف (کلید) + string agreedValue; //کلید سے قدر + mapping(uint => string) answers; //اوریکلز کے ذریعہ فراہم کردہ جوابات + mapping(address => uint) quorum; //وہ اوریکلز جو جواب طلب کریں گے (1=اوریکل نے ووٹ نہیں دیا ہے، 2=اوریکل نے ووٹ دیا ہے) + } + + //وہ واقعہ جو بلاک چین کے باہر اوریکل کو متحرک کرتا ہے + event NewRequest ( + uint id, + string urlToQuery, + string attributeToFetch + ); + + //جب حتمی نتیجے پر اتفاق رائے ہو تو متحرک ہوتا ہے + event UpdatedRequest ( + uint id, + string urlToQuery, + string attributeToFetch, + string agreedValue + ); + + function createRequest ( + string memory _urlToQuery, + string memory _attributeToFetch + ) + public + { + uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); + Request storage r = requests[length-1]; + + // ہارڈ کوڈڈ اوریکلز کا پتہ + r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; + r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; + r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; + + // بلاک چین کے باہر اوریکل کے ذریعہ پتہ لگانے کے لیے ایک واقعہ شروع کریں + emit NewRequest ( + currentId, + _urlToQuery, + _attributeToFetch + ); + + // درخواست کی آئی ڈی میں اضافہ کریں + currentId++; + } + + //اوریکل کے ذریعہ اپنے جواب کو ریکارڈ کرنے کے لیے بلایا گیا + function updateRequest ( + uint _id, + string memory _valueRetrieved + ) public { + + Request storage currRequest = requests[_id]; + + //چیک کریں کہ آیا اوریکل قابل اعتماد اوریکلز کی فہرست میں ہے + //اور اگر اوریکل نے ابھی تک ووٹ نہیں دیا ہے + if(currRequest.quorum[address(msg.sender)] == 1){ + + //یہ نشان زد کرنا کہ اس پتے نے ووٹ دیا ہے + currRequest.quorum[msg.sender] = 2; + + //جوابات کی "سرنی" کے ذریعے تکرار کریں جب تک کہ کوئی پوزیشن خالی نہ ہو اور بازیافت شدہ قدر کو محفوظ کریں + uint tmpI = 0; + bool found = false; + while(!found) { + //پہلا خالی سلاٹ تلاش کریں + if(bytes(currRequest.answers[tmpI]).length == 0){ + found = true; + currRequest.answers[tmpI] = _valueRetrieved; + } + tmpI++; + } + + uint currentQuorum = 0; + + //اوریکل فہرست کے ذریعے تکرار کریں اور چیک کریں کہ آیا کافی اوریکلز (کم از کم کورم) ہیں + //نے موجودہ جواب کی طرح ہی ووٹ دیا ہے + for(uint i = 0; i < totalOracleCount; i++){ + bytes memory a = bytes(currRequest.answers[i]); + bytes memory b = bytes(_valueRetrieved); + + if(keccak256(a) == keccak256(b)){ + currentQuorum++; + if(currentQuorum >= minQuorum){ + currRequest.agreedValue = _valueRetrieved; + emit UpdatedRequest ( + currRequest.id, + currRequest.urlToQuery, + currRequest.attributeToFetch, + currRequest.agreedValue + ); + } + } + } + } + } +} +``` + +### اوریکل نوڈس {#oracle-nodes} + +اوریکل نوڈ اوریکل سروس کا آف چین جزو ہے۔ یہ بیرونی ذرائع، جیسے کہ فریق ثالث سرورز پر میزبانی کی گئی APIs سے معلومات نکالتا ہے، اور اسے اسمارٹ کنٹریکٹس کے استعمال کے لیے آن چین ڈالتا ہے۔ اوریکل نوڈس آن چین اوریکل کنٹریکٹ سے واقعات سنتے ہیں اور لاگ میں بیان کردہ کام کو مکمل کرنے کے لیے آگے بڑھتے ہیں۔ + +اوریکل نوڈس کے لیے ایک عام کام ایک API سروس کو [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) درخواست بھیجنا، متعلقہ ڈیٹا نکالنے کے لیے جواب کو پارس کرنا، اسے بلاک چین کے پڑھنے کے قابل آؤٹ پٹ میں فارمیٹ کرنا، اور اسے اوریکل کنٹریکٹ کو ٹرانزیکشن میں شامل کرکے آن چین بھیجنا ہے۔ اوریکل نوڈ کو + +کمپیوٹیشنل اوریکلز بھی آف چین نوڈس پر انحصار کرتے ہیں تاکہ وہ کمپیوٹیشنل کام انجام دے سکیں جو گیس کی لاگت اور بلاک سائز کی حدود کو دیکھتے ہوئے آن چین پر عمل درآمد کرنا غیر عملی ہوگا۔ مثال کے طور پر، اوریکل نوڈ کو ایک قابل تصدیق بے ترتیب عدد پیدا کرنے کا کام سونپا جا سکتا ہے (مثلاً، بلاک چین پر مبنی گیمز کے لیے)۔ + +## اوریکل ڈیزائن پیٹرنز {#oracle-design-patterns} + +اوریکلز مختلف اقسام میں آتے ہیں، جن میں _فوری-پڑھنا_، _شائع-سبسکرائب_، اور _درخواست-جواب_ شامل ہیں، جن میں سے آخری دو Ethereum اسمارٹ کنٹریکٹس میں سب سے زیادہ مقبول ہیں۔ یہاں ہم شائع-سبسکرائب اور درخواست-جواب ماڈلز کی مختصر وضاحت کرتے ہیں۔ + +### پبلش-سبسکرائب اوریکلز {#publish-subscribe-oracles} + +اس قسم کا اوریکل ایک "ڈیٹا فیڈ" کو ظاہر کرتا ہے جسے دوسرے کنٹریکٹس معلومات کے لیے باقاعدگی سے پڑھ سکتے ہیں۔ اس معاملے میں ڈیٹا کے اکثر تبدیل ہونے کی توقع ہے، اس لیے کلائنٹ کنٹریکٹس کو اوریکل کے اسٹوریج میں ڈیٹا کی اپ ڈیٹس کو سننا چاہیے۔ ایک مثال ایک اوریکل ہے جو صارفین کو تازہ ترین ETH-USD قیمت کی معلومات فراہم کرتا ہے۔ + +### درخواست-جواب اوریکلز {#request-response-oracles} + +ایک درخواست-جواب سیٹ اپ کلائنٹ کنٹریکٹ کو پبلش-سبسکرائب اوریکل کے ذریعہ فراہم کردہ ڈیٹا کے علاوہ صوابدیدی ڈیٹا کی درخواست کرنے کی اجازت دیتا ہے۔ درخواست-جواب اوریکلز اس وقت مثالی ہیں جب ڈیٹا سیٹ اتنا بڑا ہو کہ اسے اسمارٹ کنٹریکٹ کے اسٹوریج میں ذخیرہ نہ کیا جا سکے، اور/یا صارفین کو کسی بھی وقت ڈیٹا کے صرف ایک چھوٹے سے حصے کی ضرورت ہوگی۔ + +اگرچہ پبلش-سبسکرائب ماڈلز سے زیادہ پیچیدہ ہیں، لیکن درخواست-جواب اوریکلز بنیادی طور پر وہی ہیں جن کی ہم نے پچھلے حصے میں وضاحت کی ہے۔ اوریکل میں ایک آن چین جزو ہوگا جو ڈیٹا کی درخواست وصول کرتا ہے اور اسے پروسیسنگ کے لیے آف چین نوڈ کو بھیجتا ہے۔ + +ڈیٹا کے سوالات شروع کرنے والے صارفین کو آف چین ماخذ سے معلومات حاصل کرنے کی لاگت کو پورا کرنا چاہیے۔ کلائنٹ کنٹریکٹ کو درخواست میں بیان کردہ کال بیک فنکشن کے ذریعے جواب واپس کرنے میں اوریکل کنٹریکٹ کے ذریعہ ہونے والی گیس کی لاگت کو پورا کرنے کے لیے فنڈز بھی فراہم کرنا ہوں گے۔ + +## مرکزی بمقابلہ غیر مرکزی اوریکلز {#types-of-oracles} + +### مرکزی اوریکلز {#centralized-oracles} + +ایک مرکزی اوریکل ایک واحد ادارے کے ذریعہ کنٹرول کیا جاتا ہے جو آف چین معلومات کو جمع کرنے اور درخواست کے مطابق اوریکل کنٹریکٹ کے ڈیٹا کو اپ ڈیٹ کرنے کا ذمہ دار ہوتا ہے۔ مرکزی اوریکلز موثر ہیں کیونکہ وہ سچائی کے ایک واحد ماخذ پر انحصار کرتے ہیں۔ وہ ایسے معاملات میں بہتر کام کر سکتے ہیں جہاں ملکیتی ڈیٹا سیٹس مالک کے ذریعہ براہ راست ایک وسیع پیمانے پر قبول شدہ دستخط کے ساتھ شائع کیے جاتے ہیں۔ تاہم، ان کے نقصانات بھی ہیں: + +#### کم درستی کی ضمانتیں {#low-correctness-guarantees} + +مرکزی اوریکلز کے ساتھ، اس بات کی تصدیق کرنے کا کوئی طریقہ نہیں ہے کہ فراہم کردہ معلومات درست ہے یا نہیں۔ یہاں تک کہ "معتبر" فراہم کنندگان بھی بدمعاش ہو سکتے ہیں یا ہیک ہو سکتے ہیں۔ اگر اوریکل خراب ہو جاتا ہے، تو اسمارٹ کنٹریکٹس خراب ڈیٹا کی بنیاد پر عمل درآمد کریں گے۔ + +#### خراب دستیابی {#poor-availability} + +مرکزی اوریکلز کو ہمیشہ دوسرے اسمارٹ کنٹریکٹس کو آف چین ڈیٹا دستیاب کرانے کی ضمانت نہیں ہے۔ اگر فراہم کنندہ سروس بند کرنے کا فیصلہ کرتا ہے یا کوئی ہیکر اوریکل کے آف چین جزو کو ہائی جیک کر لیتا ہے، تو آپ کا اسمارٹ کنٹریکٹ ڈینائل آف سروس (DoS) حملے کے خطرے سے دوچار ہوتا ہے۔ + +#### خراب ترغیبی مطابقت {#poor-incentive-compatibility} + +مرکزی اوریکلز میں اکثر ڈیٹا فراہم کنندہ کے لیے درست/غیر تبدیل شدہ معلومات بھیجنے کے لیے خراب ڈیزائن کردہ یا غیر موجود ترغیبات ہوتی ہیں۔ درستی کے لیے اوریکل کو ادائیگی کرنا ایمانداری کی ضمانت نہیں دیتا۔ یہ مسئلہ اس وقت بڑا ہو جاتا ہے جب اسمارٹ کنٹریکٹس کے ذریعے کنٹرول کی جانے والی قدر کی مقدار بڑھ جاتی ہے۔ + +### غیر مرکزی اوریکلز {#decentralized-oracles} + +غیر مرکزی اوریکلز کو ناکامی کے واحد نکات کو ختم کرکے مرکزی اوریکلز کی حدود پر قابو پانے کے لیے ڈیزائن کیا گیا ہے۔ ایک غیر مرکزی اوریکل سروس ایک پیئر-ٹو-پیئر نیٹ ورک میں متعدد شرکاء پر مشتمل ہوتی ہے جو آف چین ڈیٹا پر اتفاق رائے قائم کرتے ہیں اس سے پہلے کہ اسے اسمارٹ کنٹریکٹ میں بھیجا جائے۔ + +ایک غیر مرکزی اوریکل (مثالی طور پر) بغیر اجازت، بغیر بھروسے، اور مرکزی پارٹی کے ذریعہ انتظامیہ سے پاک ہونا چاہیے؛ حقیقت میں، اوریکلز کے درمیان غیر مرکزیت ایک سپیکٹرم پر ہے۔ نیم غیر مرکزی اوریکل نیٹ ورکس ہیں جہاں کوئی بھی حصہ لے سکتا ہے، لیکن ایک "مالک" کے ساتھ جو تاریخی کارکردگی کی بنیاد پر نوڈس کو منظور اور ہٹاتا ہے۔ مکمل طور پر غیر مرکزی اوریکل نیٹ ورکس بھی موجود ہیں: یہ عام طور پر اسٹینڈ ایلون بلاک چینز کے طور پر چلتے ہیں اور نوڈس کو مربوط کرنے اور غلط رویے کی سزا دینے کے لیے متفقہ میکانزم کی وضاحت کرتے ہیں۔ + +غیر مرکزی اوریکلز کے استعمال سے درج ذیل فوائد حاصل ہوتے ہیں: + +### اعلی درستی کی ضمانتیں {#high-correctness-guarantees} + +غیر مرکزی اوریکلز مختلف طریقوں کا استعمال کرتے ہوئے ڈیٹا کی درستی حاصل کرنے کی کوشش کرتے ہیں۔ اس میں واپس کی گئی معلومات کی صداقت اور سالمیت کی تصدیق کرنے والے ثبوتوں کا استعمال اور متعدد اداروں سے آف چین ڈیٹا کی درستگی پر اجتماعی طور پر اتفاق کرنے کا مطالبہ شامل ہے۔ + +#### صداقت کے ثبوت {#authenticity-proofs} + +صداقت کے ثبوت کرپٹوگرافک میکانزم ہیں جو بیرونی ذرائع سے حاصل کی گئی معلومات کی آزادانہ تصدیق کو ممکن بناتے ہیں۔ یہ ثبوت معلومات کے ماخذ کی توثیق کر سکتے ہیں اور بازیافت کے بعد ڈیٹا میں ممکنہ تبدیلیوں کا پتہ لگا سکتے ہیں۔ + +صداقت کے ثبوت کی مثالیں شامل ہیں: + +**ٹرانسپورٹ لیئر سیکیورٹی (TLS) ثبوت**: اوریکل نوڈس اکثر ٹرانسپورٹ لیئر سیکیورٹی (TLS) پروٹوکول پر مبنی ایک محفوظ HTTP کنکشن کا استعمال کرتے ہوئے بیرونی ذرائع سے ڈیٹا حاصل کرتے ہیں۔ کچھ غیر مرکزی اوریکلز TLS سیشنز کی تصدیق کے لیے صداقت کے ثبوت استعمال کرتے ہیں (یعنی، ایک نوڈ اور ایک مخصوص سرور کے درمیان معلومات کے تبادلے کی تصدیق) اور اس بات کی تصدیق کرتے ہیں کہ سیشن کے مندرجات میں کوئی تبدیلی نہیں کی گئی تھی۔ + +**ٹرسٹڈ ایگزیکیوشن انوائرنمنٹ (TEE) تصدیقات**: ایک [ٹرسٹڈ ایگزیکیوشن انوائرنمنٹ](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) ایک سینڈ باکسڈ کمپیوٹیشنل ماحول ہے جو اپنے میزبان نظام کے آپریشنل عمل سے الگ تھلگ ہے۔ TEEs اس بات کو یقینی بناتے ہیں کہ کمپیوٹیشنل ماحول میں ذخیرہ/استعمال ہونے والا کوئی بھی ایپلیکیشن کوڈ یا ڈیٹا سالمیت، رازداری، اور ناقابل تغیر کو برقرار رکھتا ہے۔ صارفین یہ ثابت کرنے کے لیے ایک تصدیق بھی پیدا کر سکتے ہیں کہ ایک ایپلیکیشن مثال بھروسہ مند ایگزیکیوشن ماحول میں چل رہی ہے۔ + +غیر مرکزی اوریکلز کی کچھ کلاسیں اوریکل نوڈ آپریٹرز سے TEE تصدیقات فراہم کرنے کا مطالبہ کرتی ہیں۔ یہ ایک صارف کو تصدیق کرتا ہے کہ نوڈ آپریٹر ایک بھروسہ مند ایگزیکیوشن ماحول میں اوریکل کلائنٹ کی ایک مثال چلا رہا ہے۔ TEEs بیرونی عمل کو کسی ایپلیکیشن کے کوڈ اور ڈیٹا کو تبدیل کرنے یا پڑھنے سے روکتے ہیں، لہذا، وہ تصدیقات ثابت کرتی ہیں کہ اوریکل نوڈ نے معلومات کو برقرار اور خفیہ رکھا ہے۔ + +#### معلومات کی اتفاق رائے پر مبنی توثیق {#consensus-based-validation-of-information} + +مرکزی اوریکلز اسمارٹ کنٹریکٹس کو ڈیٹا فراہم کرتے وقت سچائی کے ایک واحد ماخذ پر انحصار کرتے ہیں، جو غلط معلومات شائع کرنے کا امکان پیدا کرتا ہے۔ غیر مرکزی اوریکلز اس مسئلے کو آف چین معلومات سے استفسار کرنے کے لیے متعدد اوریکل نوڈس پر انحصار کرکے حل کرتے ہیں۔ متعدد ذرائع سے ڈیٹا کا موازنہ کرکے، غیر مرکزی اوریکلز آن چین کنٹریکٹس کو غلط معلومات منتقل کرنے کے خطرے کو کم کرتے ہیں۔ + +تاہم، غیر مرکزی اوریکلز کو متعدد آف چین ذرائع سے حاصل کی گئی معلومات میں تضادات سے نمٹنا پڑتا ہے۔ معلومات میں اختلافات کو کم سے کم کرنے اور اس بات کو یقینی بنانے کے لیے کہ اوریکل کنٹریکٹ کو منتقل کیا گیا ڈیٹا اوریکل نوڈس کی اجتماعی رائے کی عکاسی کرتا ہے، غیر مرکزی اوریکلز درج ذیل میکانزم استعمال کرتے ہیں: + +##### ڈیٹا کی درستگی پر ووٹنگ/اسٹیکنگ + +کچھ غیر مرکزی اوریکل نیٹ ورکس شرکاء سے ڈیٹا کے سوالات کے جوابات کی درستگی پر ووٹ دینے یا اسٹیک کرنے کا مطالبہ کرتے ہیں (مثلاً، "2020 کا امریکی انتخاب کس نے جیتا؟") نیٹ ورک کے مقامی ٹوکن کا استعمال کرتے ہوئے۔ ایک ایگریگیشن پروٹوکول پھر ووٹوں اور اسٹیکس کو جمع کرتا ہے اور اکثریت کی حمایت والے جواب کو درست مانتا ہے۔ + +جن نوڈس کے جوابات اکثریت کے جواب سے انحراف کرتے ہیں، ان کے ٹوکنز کو ان لوگوں میں تقسیم کرکے سزا دی جاتی ہے جو زیادہ درست اقدار فراہم کرتے ہیں۔ نوڈس کو ڈیٹا فراہم کرنے سے پہلے بانڈ فراہم کرنے پر مجبور کرنا ایماندارانہ جوابات کی ترغیب دیتا ہے کیونکہ انہیں عقلی اقتصادی اداکار سمجھا جاتا ہے جو زیادہ سے زیادہ منافع حاصل کرنے کا ارادہ رکھتے ہیں۔ + +اسٹیکنگ/ووٹنگ غیر مرکزی اوریکلز کو [Sybil حملوں](/glossary/#sybil-attack) سے بھی بچاتی ہے جہاں بدنیتی پر مبنی اداکار اتفاق رائے کے نظام کو گیم کرنے کے لیے متعدد شناختیں بناتے ہیں۔ تاہم، اسٹیکنگ "فری لوڈنگ" (اوریکل نوڈس دوسروں سے معلومات کاپی کرنا) اور "سست توثیق" (اوریکل نوڈس خود معلومات کی تصدیق کیے بغیر اکثریت کی پیروی کرنا) کو نہیں روک سکتی۔ + +##### شیلنگ پوائنٹ میکانزم + +[شیلنگ پوائنٹ](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\)) ایک گیم-تھیوری کا تصور ہے جو یہ فرض کرتا ہے کہ متعدد ادارے کسی بھی مواصلات کی عدم موجودگی میں کسی مسئلے کے مشترکہ حل پر ہمیشہ پہلے سے طے شدہ ہوں گے۔ شیلنگ-پوائنٹ میکانزم اکثر غیر مرکزی اوریکل نیٹ ورکس میں استعمال کیے جاتے ہیں تاکہ نوڈس کو ڈیٹا کی درخواستوں کے جوابات پر اتفاق رائے تک پہنچنے میں مدد مل سکے۔ + +اس کے لیے ایک ابتدائی خیال [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) تھا، جو ایک مجوزہ ڈیٹا فیڈ ہے جہاں شرکاء "اسکیلر" سوالات (وہ سوالات جن کے جوابات شدت سے بیان کیے جاتے ہیں، مثلاً، "ETH کی قیمت کیا ہے؟") کے جوابات جمع کراتے ہیں، ساتھ ہی ایک ڈپازٹ بھی۔ جو صارفین 25ویں اور 75ویں [پرسنٹائل](https://en.wikipedia.org/wiki/Percentile) کے درمیان قدریں فراہم کرتے ہیں، انہیں انعام دیا جاتا ہے، جبکہ جن کی قدریں درمیانی قدر سے بہت زیادہ انحراف کرتی ہیں، انہیں سزا دی جاتی ہے۔ + +اگرچہ SchellingCoin آج موجود نہیں ہے، لیکن کئی غیر مرکزی اوریکلز—خاص طور پر [Maker Protocol’s Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module)—اوریکل ڈیٹا کی درستگی کو بہتر بنانے کے لیے شیلنگ-پوائنٹ میکانزم کا استعمال کرتے ہیں۔ ہر Maker Oracle نوڈس ("relayers" اور "feeds") کے ایک آف چین P2P نیٹ ورک پر مشتمل ہوتا ہے جو کولیٹرل اثاثوں کے لیے مارکیٹ کی قیمتیں جمع کراتے ہیں اور ایک آن چین "Medianizer" کنٹریکٹ جو تمام فراہم کردہ اقدار کا درمیانی حساب لگاتا ہے۔ ایک بار جب مخصوص تاخیر کی مدت ختم ہو جاتی ہے، تو یہ درمیانی قدر متعلقہ اثاثے کے لیے نئی حوالہ قیمت بن جاتی ہے۔ + +شیلنگ پوائنٹ میکانزم استعمال کرنے والے اوریکلز کی دیگر مثالوں میں [Chainlink Offchain Reporting](https://docs.chain.link/architecture-overview/off-chain-reporting) اور [Witnet](https://witnet.io/) شامل ہیں۔ دونوں نظاموں میں، پیئر-ٹو-پیئر نیٹ ورک میں اوریکل نوڈس کے جوابات کو ایک واحد مجموعی قدر میں جمع کیا جاتا ہے، جیسے کہ اوسط یا درمیانی۔ نوڈس کو اس حد تک انعام یا سزا دی جاتی ہے جس حد تک ان کے جوابات مجموعی قدر سے مطابقت رکھتے ہیں یا انحراف کرتے ہیں۔ + +شیلنگ پوائنٹ میکانزم پرکشش ہیں کیونکہ وہ آن چین فوٹ پرنٹ کو کم سے کم کرتے ہیں (صرف ایک ٹرانزیکشن بھیجنے کی ضرورت ہے) جبکہ غیر مرکزیت کی ضمانت دیتے ہیں۔ مؤخر الذکر ممکن ہے کیونکہ نوڈس کو جمع کردہ جوابات کی فہرست پر دستخط کرنا ضروری ہے اس سے پہلے کہ اسے اس الگورتھم میں فیڈ کیا جائے جو اوسط/درمیانی قدر پیدا کرتا ہے۔ + +### دستیابی {#availability} + +غیر مرکزی اوریکل خدمات اسمارٹ کنٹریکٹس کو آف چین ڈیٹا کی اعلی دستیابی کو یقینی بناتی ہیں۔ یہ آف چین معلومات کے ماخذ اور معلومات کو آن چین منتقل کرنے کے ذمہ دار نوڈس دونوں کو غیر مرکزی بنا کر حاصل کیا جاتا ہے۔ + +یہ فالٹ-ٹالرنس کو یقینی بناتا ہے کیونکہ اوریکل کنٹریکٹ دوسرے کنٹریکٹس سے سوالات پر عمل درآمد کرنے کے لیے متعدد نوڈس (جو متعدد ڈیٹا ذرائع پر بھی انحصار کرتے ہیں) پر انحصار کر سکتا ہے۔ ماخذ _اور_ نوڈ-آپریٹر کی سطح پر غیر مرکزیت اہم ہے—ایک ہی ماخذ سے حاصل کردہ معلومات کی خدمت کرنے والے اوریکل نوڈس کا ایک نیٹ ورک ایک مرکزی اوریکل جیسے ہی مسئلے میں پڑ جائے گا۔ + +اسٹیک پر مبنی اوریکلز کے لیے یہ بھی ممکن ہے کہ وہ ان نوڈ آپریٹرز کو سلیش کریں جو ڈیٹا کی درخواستوں کا فوری جواب دینے میں ناکام رہتے ہیں۔ یہ اوریکل نوڈس کو فالٹ-ٹالرنٹ انفراسٹرکچر میں سرمایہ کاری کرنے اور بروقت ڈیٹا فراہم کرنے کے لیے نمایاں طور پر ترغیب دیتا ہے۔ + +### اچھی ترغیبی مطابقت {#good-incentive-compatibility} + +غیر مرکزی اوریکلز اوریکل نوڈس کے درمیان [بیزنٹائن](https://en.wikipedia.org/wiki/Byzantine_fault) رویے کو روکنے کے لیے مختلف ترغیبی ڈیزائن نافذ کرتے ہیں۔ خاص طور پر، وہ _منسوبیت_ اور _جوابدہی_ حاصل کرتے ہیں: + +1. غیر مرکزی اوریکل نوڈس سے اکثر یہ مطالبہ کیا جاتا ہے کہ وہ ڈیٹا کی درخواستوں کے جواب میں فراہم کردہ ڈیٹا پر دستخط کریں۔ یہ معلومات اوریکل نوڈس کی تاریخی کارکردگی کا جائزہ لینے میں مدد کرتی ہے، تاکہ صارفین ڈیٹا کی درخواستیں کرتے وقت ناقابل اعتماد اوریکل نوڈس کو فلٹر کر سکیں۔ ایک مثال Witnet کا [الگورتھمک ریپوٹیشن سسٹم](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) ہے۔ + +2. غیر مرکزی اوریکلز—جیسا کہ پہلے وضاحت کی گئی ہے—نوڈس سے یہ مطالبہ کر سکتے ہیں کہ وہ جمع کردہ ڈیٹا کی سچائی پر اپنے اعتماد پر ایک اسٹیک لگائیں۔ اگر دعویٰ درست ثابت ہوتا ہے، تو یہ اسٹیک ایماندارانہ خدمت کے لیے انعامات کے ساتھ واپس کیا جا سکتا ہے۔ لیکن اگر معلومات غلط ہوں تو اسے سلیش بھی کیا جا سکتا ہے، جو کچھ حد تک جوابدہی فراہم کرتا ہے۔ + +## اسمارٹ کنٹریکٹس میں اوریکلز کی ایپلی کیشنز {#applications-of-oracles-in-smart-contracts} + +درج ذیل Ethereum میں اوریکلز کے عام استعمال کے معاملات ہیں: + +### مالیاتی ڈیٹا حاصل کرنا {#retrieving-financial-data} + +[غیر مرکزی مالیات](/defi/) (DeFi) ایپلی کیشنز اثاثوں کے پیئر-ٹو-پیئر قرض دینے، قرض لینے، اور تجارت کی اجازت دیتی ہیں۔ اس کے لیے اکثر مختلف مالیاتی معلومات حاصل کرنے کی ضرورت ہوتی ہے، بشمول ایکسچینج ریٹ ڈیٹا (کرپٹو کرنسیوں کی فیاٹ ویلیو کا حساب لگانے یا ٹوکن کی قیمتوں کا موازنہ کرنے کے لیے) اور کیپیٹل مارکیٹس ڈیٹا (ٹوکنائزڈ اثاثوں، جیسے سونا یا امریکی ڈالر کی قدر کا حساب لگانے کے لیے)۔ + +مثال کے طور پر، ایک DeFi قرض دینے والے پروٹوکول کو کولیٹرل کے طور پر جمع کردہ اثاثوں (مثلاً، ETH) کے لیے موجودہ مارکیٹ کی قیمتوں سے استفسار کرنے کی ضرورت ہے۔ یہ کنٹریکٹ کو کولیٹرل اثاثوں کی قدر کا تعین کرنے اور یہ تعین کرنے دیتا ہے کہ وہ سسٹم سے کتنا قرض لے سکتا ہے۔ + +DeFi میں مقبول "قیمت اوریکلز" (جیسا کہ انہیں اکثر کہا جاتا ہے) میں Chainlink Price Feeds، Compound Protocol کا [Open Price Feed](https://compound.finance/docs/prices)، Uniswap کے [Time-Weighted Average Prices (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)، اور [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module) شامل ہیں۔ + +بلڈرز کو ان قیمت اوریکلز کو اپنے پروجیکٹ میں ضم کرنے سے پہلے ان کے ساتھ آنے والی انتباہات کو سمجھنا چاہیے۔ یہ [مضمون](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) اس بات کا تفصیلی تجزیہ فراہم کرتا ہے کہ مذکورہ قیمت اوریکلز میں سے کسی کو استعمال کرنے کی منصوبہ بندی کرتے وقت کن باتوں پر غور کرنا چاہیے۔ + +ذیل میں ایک مثال ہے کہ آپ Chainlink قیمت فیڈ کا استعمال کرتے ہوئے اپنے اسمارٹ کنٹریکٹ میں تازہ ترین ETH قیمت کیسے حاصل کر سکتے ہیں: + +```solidity +pragma solidity ^0.6.7; + +import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; + +contract PriceConsumerV3 { + + AggregatorV3Interface internal priceFeed; + + /** + * Network: Kovan + * Aggregator: ETH/USD + * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331 + */ + constructor() public { + priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); + } + + /** + * Returns the latest price + */ + function getLatestPrice() public view returns (int) { + ( + uint80 roundID, + int price, + uint startedAt, + uint timeStamp, + uint80 answeredInRound + ) = priceFeed.latestRoundData(); + return price; + } +} +``` + +### قابل تصدیق بے ترتیب پن پیدا کرنا {#generating-verifiable-randomness} + +کچھ بلاک چین ایپلی کیشنز، جیسے بلاک چین پر مبنی گیمز یا لاٹری اسکیموں کو، مؤثر طریقے سے کام کرنے کے لیے اعلیٰ سطح کی غیر متوقعیت اور بے ترتیب پن کی ضرورت ہوتی ہے۔ تاہم، بلاک چینز کا حتمی عمل درآمد بے ترتیب پن کو ختم کر دیتا ہے۔ + +اصل نقطہ نظر سیوڈو-رینڈم کرپٹوگرافک افعال، جیسے `blockhash` کا استعمال کرنا تھا، لیکن ان کو [مائنرز کے ذریعے جوڑ توڑ کیا جا سکتا تھا](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) پروف-آف-ورک الگورتھم کو حل کرنا۔ اس کے علاوہ، Ethereum کا [پروف-آف-اسٹیک میں منتقلی](/roadmap/merge/) کا مطلب ہے کہ ڈیولپرز اب آن چین بے ترتیب پن کے لیے `blockhash` پر انحصار نہیں کر سکتے۔ بیکن چین کا [RANDAO میکانزم](https://eth2book.info/altair/part2/building_blocks/randomness) اس کے بجائے بے ترتیب پن کا ایک متبادل ذریعہ فراہم کرتا ہے۔ + +بے ترتیب قدر کو آف چین پیدا کرنا اور اسے آن چین بھیجنا ممکن ہے، لیکن ایسا کرنے سے صارفین پر اعلیٰ اعتماد کی ضروریات عائد ہوتی ہیں۔ انہیں یہ یقین کرنا ہوگا کہ قدر واقعی غیر متوقع میکانزم کے ذریعے پیدا کی گئی تھی اور ٹرانزٹ میں اس میں کوئی تبدیلی نہیں کی گئی تھی۔ + +آف چین کمپیوٹیشن کے لیے ڈیزائن کیے گئے اوریکلز اس مسئلے کو حل کرتے ہیں محفوظ طریقے سے آف چین بے ترتیب نتائج پیدا کرکے جنہیں وہ آن چین نشر کرتے ہیں ساتھ ہی کرپٹوگرافک ثبوتوں کے ساتھ جو اس عمل کی غیر متوقعیت کی تصدیق کرتے ہیں۔ ایک مثال [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (قابل تصدیق بے ترتیب فنکشن) ہے، جو ایک ثابت شدہ طور پر منصفانہ اور چھیڑ چھاڑ سے پاک رینڈم نمبر جنریٹر (RNG) ہے جو ان ایپلی کیشنز کے لیے قابل اعتماد اسمارٹ کنٹریکٹس بنانے کے لیے مفید ہے جو غیر متوقع نتائج پر انحصار کرتی ہیں۔ + +### واقعات کے نتائج حاصل کرنا {#getting-outcomes-for-events} + +اوریکلز کے ساتھ، ایسے اسمارٹ کنٹریکٹس بنانا آسان ہے جو حقیقی دنیا کے واقعات کا جواب دیتے ہیں۔ اوریکل خدمات کنٹریکٹس کو آف چین اجزاء کے ذریعے بیرونی APIs سے منسلک ہونے اور ان ڈیٹا ذرائع سے معلومات استعمال کرنے کی اجازت دے کر اسے ممکن بناتی ہیں۔ مثال کے طور پر، پہلے ذکر کردہ پیشین گوئی ڈیپ ایک اوریکل سے درخواست کر سکتی ہے کہ وہ ایک قابل اعتماد آف چین ماخذ (مثلاً، ایسوسی ایٹڈ پریس) سے انتخابی نتائج واپس کرے۔ + +حقیقی دنیا کے نتائج کی بنیاد پر ڈیٹا حاصل کرنے کے لیے اوریکلز کا استعمال دیگر نئے استعمال کے معاملات کو بھی ممکن بناتا ہے؛ مثال کے طور پر، ایک غیر مرکزی بیمہ پروڈکٹ کو مؤثر طریقے سے کام کرنے کے لیے موسم، آفات، وغیرہ کے بارے میں درست معلومات کی ضرورت ہوتی ہے۔ + +### اسمارٹ کنٹریکٹس کو خودکار بنانا {#automating-smart-contracts} + +اسمارٹ کنٹریکٹس خود بخود نہیں چلتے؛ بلکہ، ایک بیرونی ملکیت والا اکاؤنٹ (EOA)، یا کوئی دوسرا کنٹریکٹ اکاؤنٹ، کنٹریکٹ کے کوڈ پر عمل درآمد کرنے کے لیے صحیح افعال کو متحرک کرنا ضروری ہے۔ زیادہ تر معاملات میں، کنٹریکٹ کے افعال کا بڑا حصہ عوامی ہوتا ہے اور اسے EOAs اور دیگر کنٹریکٹس کے ذریعے بلایا جا سکتا ہے۔ + +لیکن ایک کنٹریکٹ کے اندر _نجی افعال_ بھی ہوتے ہیں جو دوسروں کے لیے ناقابل رسائی ہوتے ہیں؛ لیکن جو ایک ڈیپ کی مجموعی فعالیت کے لیے اہم ہوتے ہیں۔ مثالوں میں ایک `mintERC721Token()` فنکشن شامل ہے جو وقتاً فوقتاً صارفین کے لیے نئے NFTs منٹ کرتا ہے، ایک پیشین گوئی بازار میں ادائیگیوں سے نوازنے کے لیے ایک فنکشن، یا ایک DEX میں اسٹیک کیے گئے ٹوکنز کو انلاک کرنے کے لیے ایک فنکشن۔ + +ایپلیکیشن کو آسانی سے چلانے کے لیے ڈیولپرز کو وقفوں پر ایسے افعال کو متحرک کرنے کی ضرورت ہوگی۔ تاہم، یہ ڈیولپرز کے لیے دنیاوی کاموں پر مزید گھنٹے ضائع ہونے کا باعث بن سکتا ہے، یہی وجہ ہے کہ اسمارٹ کنٹریکٹس کے عمل درآمد کو خودکار بنانا پرکشش ہے۔ + +کچھ غیر مرکزی اوریکل نیٹ ورکس آٹومیشن خدمات پیش کرتے ہیں، جو آف چین اوریکل نوڈس کو صارف کے ذریعہ بیان کردہ پیرامیٹرز کے مطابق اسمارٹ کنٹریکٹ افعال کو متحرک کرنے کی اجازت دیتے ہیں۔ عام طور پر، اس کے لیے اوریکل سروس کے ساتھ ٹارگٹ کنٹریکٹ کو "رجسٹر" کرنے، اوریکل آپریٹر کو ادائیگی کے لیے فنڈز فراہم کرنے، اور کنٹریکٹ کو متحرک کرنے کے لیے شرائط یا اوقات کی وضاحت کرنے کی ضرورت ہوتی ہے۔ + +Chainlink کا [Keeper Network](https://chain.link/keepers) اسمارٹ کنٹریکٹس کو ایک بھروسہ مند اور غیر مرکزی طریقے سے باقاعدہ دیکھ بھال کے کاموں کو آؤٹ سورس کرنے کے اختیارات فراہم کرتا ہے۔ اپنے کنٹریکٹ کو Keeper-compatible بنانے اور Upkeep سروس استعمال کرنے کے بارے میں معلومات کے لیے آفیشل [Keeper's documentation](https://docs.chain.link/docs/chainlink-keepers/introduction/) پڑھیں۔ + +## بلاک چین اوریکلز کا استعمال کیسے کریں {#use-blockchain-oracles} + +متعدد اوریکل ایپلی کیشنز ہیں جنہیں آپ اپنے Ethereum ڈیپ میں ضم کر سکتے ہیں: + +**[Chainlink](https://chain.link/)** - _Chainlink غیر مرکزی اوریکل نیٹ ورکس کسی بھی بلاک چین پر جدید اسمارٹ کنٹریکٹس کی حمایت کے لیے چھیڑ چھاڑ سے پاک ان پٹ، آؤٹ پٹ، اور حسابات فراہم کرتے ہیں۔_ + +**[RedStone Oracles](https://redstone.finance/)** - _RedStone ایک غیر مرکزی ماڈیولر اوریکل ہے جو گیس-آپٹمائزڈ ڈیٹا فیڈز فراہم کرتا ہے۔ یہ ابھرتے ہوئے اثاثوں، جیسے لیکویڈ اسٹیکنگ ٹوکنز (LSTs)، لیکویڈ ری-اسٹیکنگ ٹوکنز (LRTs)، اور Bitcoin اسٹیکنگ ڈیریویٹوز کے لیے قیمت فیڈز پیش کرنے میں مہارت رکھتا ہے۔_ + +**[Chronicle](https://chroniclelabs.org/)** - _Chronicle واقعی قابل توسیع، لاگت-موثر، غیر مرکزی، اور قابل تصدیق اوریکلز تیار کرکے آن چین ڈیٹا کی منتقلی کی موجودہ حدود پر قابو پاتا ہے۔_ + +**[Witnet](https://witnet.io/)** - _Witnet ایک بغیر اجازت، غیر مرکزی، اور سنسر شپ-مزاحم اوریکل ہے جو اسمارٹ کنٹریکٹس کو مضبوط کرپٹو-اکنامک گارنٹی کے ساتھ حقیقی دنیا کے واقعات پر رد عمل ظاہر کرنے میں مدد کرتا ہے۔_ + +**[UMA Oracle](https://uma.xyz)** - _UMA کا آپٹمسٹک اوریکل اسمارٹ کنٹریکٹس کو مختلف ایپلی کیشنز، بشمول انشورنس، مالیاتی ڈیریویٹوز، اور پیشین گوئی بازاروں کے لیے کسی بھی قسم کا ڈیٹا تیزی سے اور وصول کرنے کی اجازت دیتا ہے۔_ + +**[Tellor](https://tellor.io/)** - _Tellor آپ کے اسمارٹ کنٹریکٹ کے لیے ایک شفاف اور بغیر اجازت والا اوریکل پروٹوکول ہے تاکہ جب بھی اسے ضرورت ہو آسانی سے کوئی بھی ڈیٹا حاصل کیا جا سکے۔_ + +**[Band Protocol](https://bandprotocol.com/)** - _Band Protocol ایک کراس-چین ڈیٹا اوریکل پلیٹ فارم ہے جو حقیقی دنیا کے ڈیٹا اور APIs کو اسمارٹ کنٹریکٹس سے جمع اور جوڑتا ہے۔_ + +**[Pyth Network](https://pyth.network/)** - _Pyth نیٹ ورک ایک فرسٹ-پارٹی مالیاتی اوریکل نیٹ ورک ہے جو ایک چھیڑ چھاڑ سے پاک، غیر مرکزی، اور خود-پائیدار ماحول میں آن چین پر مسلسل حقیقی دنیا کا ڈیٹا شائع کرنے کے لیے ڈیزائن کیا گیا ہے۔_ + +**[API3 DAO](https://www.api3.org/)** - _API3 DAO فرسٹ-پارٹی اوریکل حل فراہم کر رہا ہے جو اسمارٹ کنٹریکٹس کے لیے ایک غیر مرکزی حل میں زیادہ ماخذ کی شفافیت، سیکیورٹی اور اسکیل ایبلٹی فراہم کرتے ہیں_ + +**[Supra](https://supra.com/)** - کراس-چین حلوں کا ایک عمودی طور پر مربوط ٹول کٹ جو تمام بلاک چینز، عوامی (L1s اور L2s) یا نجی (انٹرپرائزز) کو آپس میں جوڑتا ہے، غیر مرکزی اوریکل قیمت فیڈز فراہم کرتا ہے جو آن چین اور آف چین استعمال کے معاملات کے لیے استعمال کیا جا سکتا ہے۔ + +**[Gas Network](https://gas.network/)** - ایک تقسیم شدہ اوریکل پلیٹ فارم جو بلاک چین بھر میں ریئل ٹائم گیس کی قیمت کا ڈیٹا فراہم کرتا ہے۔ سرکردہ گیس قیمت ڈیٹا فراہم کنندگان سے ڈیٹا آن چین لا کر، Gas Network باہمی عمل کو چلانے میں مدد کر رہا ہے۔ Gas Network 35 سے زیادہ چینز کے لیے ڈیٹا کو سپورٹ کرتا ہے، بشمول Ethereum Mainnet اور بہت سے سرکردہ L2s۔ + +## مزید پڑھیں {#further-reading} + +**مضامین** + +- [ایک بلاک چین اوریکل کیا ہے؟](https://chain.link/education/blockchain-oracles) — _Chainlink_ +- [ایک بلاک چین اوریکل کیا ہے؟](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Patrick Collins_ +- [غیر مرکزی اوریکلز: ایک جامع جائزہ](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Julien Thevenard_ +- [Ethereum پر ایک بلاک چین اوریکل کا نفاذ](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ +- [اسمارٹ کنٹریکٹس API کالز کیوں نہیں کر سکتے؟](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_ +- [تو آپ ایک قیمت اوریکل استعمال کرنا چاہتے ہیں](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_ + +**ویڈیوز** + +- [اوریکلز اور بلاک چین یوٹیلیٹی کی توسیع](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ + +**ٹیوٹوریلز** + +- [Solidity میں Ethereum کی موجودہ قیمت کیسے حاصل کریں](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_ +- [اوریکل ڈیٹا کا استعمال](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ + +**بطور مثال پروجیکٹس** + +- [Solidity میں Ethereum کے لیے مکمل Chainlink اسٹارٹر پروجیکٹ](https://github.com/hackbg/chainlink-fullstack) — _HackBG_ diff --git a/public/content/translations/ur/developers/docs/programming-languages/dart/index.md b/public/content/translations/ur/developers/docs/programming-languages/dart/index.md new file mode 100644 index 00000000000..897c43d234d --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/dart/index.md @@ -0,0 +1,32 @@ +--- +title: "ڈارٹ ڈیولپرز کے لیے ایتھریم" +description: "ڈارٹ زبان کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں" +lang: ur-in +incomplete: true +--- + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +## ٹیوٹوریلز {#tutorials} + +- [فلوٹر اور بلاک چین – ہیلو ورلڈ Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) شروع کرنے کے لیے آپ کو تمام مراحل سے گزارتا ہے: + 1. [Solidity](https://soliditylang.org/) میں ایک اسمارٹ کنٹریکٹ لکھنا + 2. ڈارٹ میں یوزر انٹرفیس لکھنا +- [فلوٹر کے ساتھ ایک موبائل dapp بنانا](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) بہت چھوٹا ہے، جو بہتر ہو سکتا ہے + اگر آپ پہلے سے ہی بنیادی باتیں جانتے ہیں +- اگر آپ ویڈیو دیکھ کر سیکھنا پسند کرتے ہیں، تو آپ [Build Your First Blockchain Flutter App](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) دیکھ سکتے ہیں، جو تقریباً ایک گھنٹے طویل ہے +- اگر آپ بے صبر ہیں، تو آپ [Building a Blockchain Decentralized-app with Flutter and Dart on Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s) کو ترجیح دے سکتے ہیں، جو صرف بیس منٹ کا ہے +- [والٹ کنیکٹ کے ذریعے Web3Modal کے ساتھ فلوٹر ایپلیکیشن میں MetaMask کو انٹیگریٹ کرنا](https://www.youtube.com/watch?v=v_M2buHCpc4) - یہ مختصر ویڈیو آپ کو والٹ کنیکٹ کی [Web3Modal](https://pub.dev/packages/web3modal_flutter) لائبریری کے ساتھ اپنے فلوٹر ایپلی کیشنز میں میٹا ماسک کو انٹیگریٹ کرنے کے مراحل سے گزارتا ہے۔ +- [سولیڈٹی اور فلوٹر کے ساتھ موبائل بلاک چین ڈیولپر بوٹ کیمپ کورس](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - فُل اسٹیک موبائل بلاک چین ڈیولپر کورس پلے لسٹ + +## ایتھریم کلائنٹس کے ساتھ کام کرنا {#working-with-ethereum-clients} + +آپ ایتھریم کا استعمال غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے کر سکتے ہیں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ +ڈارٹ کے لیے کم از کم دو موجودہ مینٹین کردہ لائبریریاں ہیں جو ایتھریم کے لیے +[JSON-RPC API](/developers/docs/apis/json-rpc/) کا استعمال کرتی ہیں۔ + +1. [pwa.ir سے Web3dart](https://pub.dev/packages/web3dart) +2. [darticulate.com سے ایتھریم 5.0.0](https://pub.dev/packages/ethereum) + +اضافی لائبریریاں بھی ہیں جو آپ کو مخصوص ایتھریم پتوں میں ہیرا پھیری کرنے کی اجازت دیتی ہیں، یا جو آپ کو مختلف کرپٹو کرنسیوں کی قیمتیں حاصل کرنے دیتی ہیں۔ +[آپ پوری فہرست یہاں دیکھ سکتے ہیں](https://pub.dev/dart/packages?q=ethereum)۔ diff --git a/public/content/translations/ur/developers/docs/programming-languages/delphi/index.md b/public/content/translations/ur/developers/docs/programming-languages/delphi/index.md new file mode 100644 index 00000000000..8eacf64fdfd --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/delphi/index.md @@ -0,0 +1,56 @@ +--- +title: "ڈیلفی ڈیولپرز کے لیے ایتھریم" +description: "ڈیلفی پروگرامنگ زبان کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنا سیکھیں" +lang: ur-in +incomplete: true +--- + + + +ڈیلفی پروگرامنگ زبان کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنا سیکھیں + + + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps قابل اعتماد ہو سکتی ہیں، یعنی ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق چلیں گی۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتی ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +ڈیلفی پروگرامنگ زبان کا استعمال کرتے ہوئے ایتھریم پر غیر مرکزی ایپلیکیشنز بنائیں اور اسمارٹ معاہدوں کے ساتھ تعامل کریں! + +## اسمارٹ کانٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-the-solidity-language} + +**ایتھریم کے ساتھ ڈیلفی کو انٹیگریٹ کرنے کی جانب اپنے پہلے قدم اٹھائیں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## ابتدائی حوالہ جات اور لنکس {#beginner-references-and-links} + +**ڈیلفیریم لائبریری کا تعارف** + +- [ڈیلفیریم کیا ہے؟](https://github.com/svanas/delphereum/blob/master/README.md) +- [ڈیلفی کو مقامی (اِن-میموری) بلاک چین سے جوڑنا](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [ڈیلفی کو ایتھریم مین نیٹ سے جوڑنا](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) +- [ڈیلفی کو اسمارٹ معاہدوں سے جوڑنا](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) + +**کیا آپ ابھی کے لیے سیٹ اپ کو چھوڑنا چاہتے ہیں، اور سیدھے نمونوں پر جانا چاہتے ہیں؟** + +- [3 منٹ کا ایک اسمارٹ معاہدہ اور ڈیلفی - حصہ 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [3 منٹ کا ایک اسمارٹ معاہدہ اور ڈیلفی - حصہ 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) + +## درمیانی سطح کے مضامین {#intermediate-articles} + +- [ڈیلفی میں ایتھریم سے دستخط شدہ پیغام کا سگنیچر بنانا](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [ڈیلفی کے ساتھ ایتھر منتقل کرنا](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) +- [ڈیلفی کے ساتھ ERC-20 ٹوکنز منتقل کرنا](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) + +## استعمال کے جدید پیٹرن {#advanced-use-patterns} + +- [ڈیلفی اور ایتھریم نیم سروس (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [کوئک نوڈ، ایتھریم اور ڈیلفی](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) +- [ڈیلفی اور ایتھریم ڈارک فاریسٹ](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [ڈیلفی میں ایک ٹوکن کو دوسرے سے سویپ کرنا](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) + +مزید وسائل کی تلاش ہے؟ [ethereum.org/developers](/developers/) دیکھیں۔ diff --git a/public/content/translations/ur/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/ur/developers/docs/programming-languages/dot-net/index.md new file mode 100644 index 00000000000..42382547f47 --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/dot-net/index.md @@ -0,0 +1,86 @@ +--- +title: ".NET ڈیولپرز کے لیے ایتھریم" +description: ".NET پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں۔" +lang: ur-in +incomplete: true +--- + +.NET پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps قابل اعتماد ہو سکتی ہیں، یعنی ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق چلیں گی۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتی ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +Microsoft ٹیکنالوجی اسٹیک کے ٹولز اور زبانوں کا استعمال کرتے ہوئے ایتھریم کے اوپر ڈی سینٹرلائزڈ ایپلیکیشنز بنائیں اور اسمارٹ کانٹریکٹس کے ساتھ تعامل کریں - VSCode اور Visual Studio جیسے ٹولنگ پر، .NET Framework/.NET Core/.NET Standard میں C#، # Visual Basic .NET، F# کو سپورٹ کرنا۔ Microsoft Azure Blockchain کا استعمال کرتے ہوئے منٹوں میں Azure پر ایتھریم بلاک چین ڈیپلائے کریں۔ .NET کا پیار ایتھریم میں لائیں! + +## اسمارٹ کانٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-the-solidity-language} + +**.NET کو ایتھریم کے ساتھ انٹیگریٹ کرنے کے لیے اپنے پہلے قدم اٹھائیں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## ابتدائی حوالہ جات اور لنکس {#beginner-references-and-links} + +**Nethereum لائبریری اور VS Code Solidity کا تعارف** + +- [Nethereum، شروعات کرنا](https://docs.nethereum.com/en/latest/getting-started/) +- [VS Code Solidity انسٹال کرنا](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) +- [ایتھریم اسمارٹ کانٹریکٹس بنانے اور کال کرنے کے لیے ایک .NET ڈیولپر کا ورک فلو](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) +- [Nethereum کے ساتھ اسمارٹ کانٹریکٹس کا انٹیگریشن](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [Nethereum کے ساتھ .NET اور ایتھریم بلاک چین اسمارٹ کانٹریکٹس کا انٹرفیس کرنا](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) میں بھی +- [Nethereum - بلاک چین کے لیے ایک اوپن سورس .NET انٹیگریشن لائبریری](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Nethereum کا استعمال کرتے ہوئے SQL ڈیٹا بیس میں ایتھریم ٹرانزیکشنز لکھنا](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [دیکھیں کہ C# اور VisualStudio کا استعمال کرتے ہوئے آسانی سے ایتھریم اسمارٹ کانٹریکٹس کیسے ڈیپلائے کیے جائیں](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) + +**کیا آپ ابھی کے لیے سیٹ اپ کو چھوڑنا چاہتے ہیں، اور سیدھے نمونوں پر جانا چاہتے ہیں؟** + +- [پلے گراؤنڈ](http://playground.nethereum.com/) - ایتھریم کے ساتھ تعامل کریں اور براؤزر کے ذریعے Nethereum استعمال کرنے کا طریقہ سیکھیں۔ + - اکاؤنٹ بیلنس کی کوئری کریں [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - ERC20 اسمارٹ کانٹریکٹ بیلنس کی کوئری کریں [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) + - ایک اکاؤنٹ میں ایتھر منتقل کریں [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) + - ... اور بھی بہت کچھ! + +## درمیانی سطح کے مضامین {#intermediate-articles} + +- [Nethereum ورک بک/سیمپل کی فہرست](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [اپنے ڈیولپمنٹ ٹیسٹ چینز ڈیپلائے کریں](https://github.com/Nethereum/Testchains) +- [Solidity کے لیے VSCode Codegen پلگ ان](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unity اور ایتھریم: کیوں اور کیسے](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [ایتھریم dapps کے لیے ASP.NET Core Web API بنائیں](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [سپلائی چین ٹریکنگ سسٹم کو لاگو کرنے کے لیے Nethereum Web3 کا استعمال](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Nethereum بلاک پروسیسنگ](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/)، [C# پلے گراؤنڈ سیمپل](http://playground.nethereum.com/csharp/id/1025) کے ساتھ +- [Nethereum ویب ساکٹ اسٹریمنگ](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) +- [Kaleido اور Nethereum](https://kaleido.io/kaleido-and-nethereum/) +- [Quorum اور Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) + +## استعمال کے جدید پیٹرن {#advanced-use-patterns} + +- [Azure Key Vault اور Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) +- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) +- [Ujo Nethereum بیک اینڈ ریفرنس آرکیٹیکچر](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) + +## .NET پروجیکٹس، ٹولز اور دیگر دلچسپ چیزیں {#dot-net-projects-tools-and-other-fun-stuff} + +- [Nethereum پلے گراؤنڈ](http://playground.nethereum.com/) - _براؤزر میں Nethereum کوڈ کے ٹکڑوں کو کمپائل، تخلیق اور چلائیں_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Blazor میں UI کے ساتھ Nethereum codegen_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _ایک .NET Wasm SPA لائٹ بلاک چین ایکسپلورر اور سادہ والیٹ_ +- [Wonka بزنس رولز انجن](https://docs.nethereum.com/en/latest/wonka/) - _ایک بزنس رولز انجن (.NET پلیٹ فارم اور ایتھریم پلیٹ فارم دونوں کے لیے) جو فطری طور پر میٹا ڈیٹا پر مبنی ہے_ +- [Nethermind](https://github.com/NethermindEth/nethermind) - _Linux، Windows، MacOS کے لیے ایک .NET Core ایتھریم کلائنٹ_ +- [eth-utils](https://github.com/ethereum/eth-utils/) - _Ethereum سے متعلقہ کوڈ بیس کے ساتھ کام کرنے کے لیے یوٹیلٹی فنکشنز_ +- [TestChains](https://github.com/Nethereum/TestChains) - _تیز ردعمل (PoA) کے لیے پہلے سے کنفیگر شدہ .NET devchains_ + +مزید وسائل کی تلاش ہے؟ [ethereum.org/developers](/developers/) دیکھیں۔ + +## .NET کمیونٹی کے تعاون کنندگان {#dot-net-community-contributors} + +Nethereum میں، ہم زیادہ تر [Gitter](https://gitter.im/Nethereum/Nethereum) پر وقت گزارتے ہیں جہاں ہر کوئی سوال پوچھنے/جواب دینے، مدد حاصل کرنے، یا صرف آرام کرنے کے لیے خوش آمدید ہے۔ [Nethereum GitHub repository](https://github.com/Nethereum) پر بلا جھجھک PR کریں یا کوئی مسئلہ کھولیں، یا ہمارے بہت سے سائیڈ/سیمپل پروجیکٹس کو براؤز کریں۔ آپ ہمیں [Discord](https://discord.gg/jQPrR58FxX) پر بھی تلاش کر سکتے ہیں! + +اگر آپ Nethermind میں نئے ہیں اور شروع کرنے میں مدد کی ضرورت ہے، تو ہمارے [Discord](http://discord.gg/PaCMRFdvWT) میں شامل ہوں۔ ہمارے ڈیولپرز آپ کے سوالات کا جواب دینے کے لیے موجود ہیں۔ [Nethermind GitHub repository](https://github.com/NethermindEth/nethermind) پر PR کھولنے یا کوئی بھی مسئلہ اٹھانے میں ہچکچاہٹ محسوس نہ کریں۔ + +## دیگر مجموعی فہرستیں {#other-aggregated-lists} + +[سرکاری Nethereum سائٹ](https://nethereum.com/) +[سرکاری Nethermind سائٹ](https://nethermind.io/) diff --git a/public/content/translations/ur/developers/docs/programming-languages/elixir/index.md b/public/content/translations/ur/developers/docs/programming-languages/elixir/index.md new file mode 100644 index 00000000000..f1cc1495707 --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/elixir/index.md @@ -0,0 +1,55 @@ +--- +title: "Elixir ڈویلپرز کے لیے Ethereum" +description: "جانیں کہ Elixir پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے کیسے ڈیولپ کریں۔" +lang: ur-in +incomplete: false +--- + +جانیں کہ Elixir پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے کیسے ڈیولپ کریں۔ + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps ٹرسٹ لیس ہو سکتے ہیں، جس کا مطلب ہے کہ ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق ہی چلیں گے۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتے ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +**Elixir کو Ethereum کے ساتھ انٹیگریٹ کرنے کے لیے اپنے پہلے قدم اٹھائیں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## ابتدائی مضامین {#beginner-articles} + +- [بالآخر Ethereum اکاؤنٹس کو سمجھنا](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Ethers — Elixir کے لیے ایک فرسٹ کلاس Ethereum Web3 لائبریری](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) + +## درمیانی سطح کے مضامین {#intermediate-articles} + +- [Elixir کے ساتھ خام Ethereum کنٹریکٹ ٹرانزیکشنز پر کیسے دستخط کریں](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) +- [Ethereum اسمارٹ کنٹریکٹس اور Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) + +## Elixir پروجیکٹس اور ٹولز {#elixir-projects-and-tools} + +### فعال {#active} + +- [block_keys](https://github.com/ExWeb3/block_keys) - _Elixir میں BIP32 اور BIP44 کا نفاذ (ڈیٹرمینسٹک والیٹس کے لیے ملٹی اکاؤنٹ ہائرارکی)_ +- [ethereumex](https://github.com/mana-ethereum/ethereumex) - _Ethereum بلاک چین کے لیے Elixir JSON-RPC کلائنٹ_ +- [ethers](https://github.com/ExWeb3/elixir_ethers) - _Elixir کا استعمال کرتے ہوئے Ethereum پر اسمارٹ کنٹریکٹس کے ساتھ تعامل کے لیے ایک جامع Web3 لائبریری_ +- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) - _Ethers کے لیے ایک KMS سائنر لائبریری (AWS KMS کے ساتھ ٹرانزیکشنز پر دستخط کریں)_ +- [ex_abi](https://github.com/poanetwork/ex_abi) - _Elixir میں Ethereum ABI پارسر/ڈیکوڈر/اینکوڈر کا نفاذ_ +- [ex_keccak](https://github.com/ExWeb3/ex_keccak) - _ایک NIF بلٹ ٹائنی-کیکک رسٹ کریٹ کا استعمال کرتے ہوئے Keccak SHA3-256 ہیشز کا حساب لگانے کے لیے Elixir لائبریری_ +- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) - _Ethereum کی RLP (ریکرسیو لینتھ پریفکس) انکوڈنگ کا Elixir نفاذ_ + +### آرکائیو شدہ / اب برقرار نہیں رکھا گیا {#archived--no-longer-maintained} + +- [eth](https://hex.pm/packages/eth) - _Elixir کے لیے Ethereum یوٹیلیٹیز_ +- [exw3](https://github.com/hswick/exw3) - _Elixir کے لیے اعلی سطح کا Ethereum RPC کلائنٹ_ +- [mana](https://github.com/mana-ethereum/mana) - _Elixir میں لکھا گیا Ethereum فل نوڈ کا نفاذ_ + +مزید وسائل کی تلاش ہے؟ [ہمارے ڈویلپرز کا ہوم](/developers/) دیکھیں۔ + +## Elixir کمیونٹی کے تعاون کنندگان {#elixir-community-contributors} + +[Elixir کا سلیک #ethereum چینل](https://elixir-lang.slack.com/archives/C5RPZ3RJL) تیزی سے بڑھتی ہوئی کمیونٹی کی میزبانی کرتا ہے اور مذکورہ بالا کسی بھی پروجیکٹ اور متعلقہ موضوعات پر بات چیت کے لیے ایک وقف شدہ وسیلہ ہے۔ diff --git a/public/content/translations/ur/developers/docs/programming-languages/golang/index.md b/public/content/translations/ur/developers/docs/programming-languages/golang/index.md new file mode 100644 index 00000000000..23ff87c1040 --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/golang/index.md @@ -0,0 +1,84 @@ +--- +title: "Go ڈیولپرز کے لیے ایتھریم" +description: "Go پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں" +lang: ur-in +incomplete: true +--- + +Go پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے ایتھریم کا استعمال کریں۔ یہ dapps قابل اعتماد ہو سکتی ہیں، یعنی ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق چلیں گی۔ وہ غیر مرکزی ہیں، یعنی وہ پیئر ٹو پیئر نیٹ ورک پر چلتے ہیں اور ناکامی کا کوئی واحد نقطہ نہیں ہے۔ کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ وہ نئی قسم کی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتے ہیں۔ + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +**Go کو ایتھریم کے ساتھ مربوط کرنے کے لیے اپنے پہلے اقدامات کریں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [کنٹریکٹ ٹیوٹوریل](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) + +## ابتدائی مضامین اور کتابیں {#beginner-articles-and-books} + +- [Geth کے ساتھ شروعات کرنا](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) +- [ایتھریم سے منسلک ہونے کے لیے Golang کا استعمال کریں](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Golang کا استعمال کرتے ہوئے ایتھریم اسمارٹ کنٹریکٹس کو ڈیپلائے کریں](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Go میں ایتھریم اسمارٹ کنٹریکٹس کی جانچ اور ڈیپلائے کرنے کے لیے ایک مرحلہ وار گائیڈ](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) +- [ای بک: Go کے ساتھ ایتھریم ڈیولپمنٹ](https://goethereumbook.org/) - _Go کے ساتھ ایتھریم ایپلی کیشنز ڈیولپ کریں_ + +## انٹرمیڈیٹ مضامین اور دستاویزات {#intermediate-articles-and-docs} + +- [Go Ethereum کی دستاویزات](https://geth.ethereum.org/docs/) - _آفیشل Ethereum Golang کے لیے دستاویزات_ +- [Erigon پروگرامر کی گائیڈ](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _اسٹیٹ ٹری، ملٹی پروفس، اور ٹرانزیکشن پروسیسنگ سمیت تصویری گائیڈ_ +- [Erigon اور اسٹیٹ لیس ایتھریم](https://youtu.be/3-Mn7OckSus?t=394) - _2020 ایتھریم کمیونٹی کانفرنس (EthCC 3)_ +- [Erigon: ایتھریم کلائنٹس کو بہتر بنانا](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_ +- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) +- [Geth کے ساتھ Go میں ایک dapp بنانا](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) +- [Golang اور Geth کے ساتھ ایتھریم پرائیویٹ نیٹ ورک کے ساتھ کام کریں](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Go کے ساتھ ایتھریم پر Solidity کنٹریکٹس کی یونٹ ٹیسٹنگ](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Geth کو لائبریری کے طور پر استعمال کرنے کے لیے فوری حوالہ](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) + +## استعمال کے جدید پیٹرن {#advanced-use-patterns} + +- [GETH سمیولیٹڈ بیک اینڈ](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) +- [ایتھریم اور Quorum کا استعمال کرتے ہوئے بلاک چین-ایز-اے-سروس ایپس](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [ایتھریم بلاک چین ایپلی کیشنز میں ڈسٹری بیوٹیڈ اسٹوریج IPFS اور Swarm](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) +- [موبائل کلائنٹس: لائبریریز اور انپراک ایتھریم نوڈس](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) +- [نیٹیو dapps: ایتھریم کنٹریکٹس کے لیے Go بائنڈنگز](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) + +## Go پروجیکٹس اور ٹولز {#go-projects-and-tools} + +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _ایتھریم پروٹوکول کا آفیشل Go نفاذ_ +- [Go Ethereum کوڈ کا تجزیہ](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go Ethereum سورس کوڈ کا جائزہ اور تجزیہ_ +- [Erigon](https://github.com/ledgerwatch/erigon) - _Go Ethereum کا تیز ترین ڈیریویٹیو، آرکائیو نوڈس پر توجہ کے ساتھ_ +- [Golem](https://github.com/golemfactory/golem) - _Golem کمپیوٹنگ پاور کے لیے ایک عالمی مارکیٹ بنا رہا ہے_ +- [Quorum](https://github.com/jpmorganchase/quorum) - _ایتھریم کا ایک اجازت یافتہ نفاذ جو ڈیٹا کی رازداری کو سپورٹ کرتا ہے_ +- [Prysm](https://github.com/prysmaticlabs/prysm) - _ایتھریم 'Serenity' 2.0 Go کا نفاذ_ +- [Eth Tweet](https://github.com/yep/eth-tweet) - _غیر مرکزی ٹویٹر: ایتھریم بلاک چین پر چلنے والی ایک مائیکرو بلاگنگ سروس_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _کم از کم قابل عمل پلازما کی تفصیلات کا Golang نفاذ اور توسیع_ +- [اوپن ایتھریم مائننگ پول](https://github.com/sammy007/open-ethereum-pool) - _ایک اوپن سورس ایتھریم مائننگ پول_ +- [ایتھریم HD والیٹ](https://github.com/miguelmota/go-ethereum-hdwallet) - _Go میں ایتھریم HD والیٹ ڈیریویشنز_ +- [ملٹی Geth](https://github.com/multi-geth/multi-geth) - _ایتھریم نیٹ ورکس کی کئی اقسام کے لیے سپورٹ_ +- [Geth لائٹ کلائنٹ](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _لائٹ ایتھریم سب پروٹوکول کا Geth نفاذ_ +- [ایتھریم Golang SDK](https://github.com/everFinance/goether) - _Golang میں ایک سادہ ایتھریم والیٹ کا نفاذ اور یوٹیلیٹیز_ +- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _200+ بلاک چینز کے لیے Go SDK کے ذریعے موثر بلاک چین ڈیٹا تک رسائی_ + +مزید وسائل کی تلاش ہے؟ [ethereum.org/developers](/developers/) دیکھیں + +## Go کمیونٹی کے تعاون کنندگان {#go-community-contributors} + +- [Geth Discord](https://discordapp.com/invite/nthXNEv) +- [Geth Gist](https://gitter.im/ethereum/go-ethereum) +- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereum چینل](https://gophers.slack.com/messages/C9HP1S9V2) +- [StackExchange - ایتھریم](https://ethereum.stackexchange.com/) +- [ملٹی Geth Gitter](https://gitter.im/ethoxy/multi-geth) +- [ایتھریم Gitter](https://gitter.im/ethereum/home) +- [Geth لائٹ کلائنٹ Gitter](https://gitter.im/ethereum/light-client) + +## دیگر مجموعی فہرستیں {#other-aggregated-lists} + +- [شاندار ایتھریم](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: ایتھریم ڈیولپر ٹولز کی ایک حتمی فہرست](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub سورس](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git a/public/content/translations/ur/developers/docs/programming-languages/index.md b/public/content/translations/ur/developers/docs/programming-languages/index.md new file mode 100644 index 00000000000..acac642d4b3 --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/index.md @@ -0,0 +1,33 @@ +--- +title: "پروگرامنگ لینگویجز" +description: "JavaScript، Python، Go، Rust، اور مزید سمیت مختلف پروگرامنگ زبانوں کے لیے ایتھیریم ڈیولپمنٹ کے وسائل دریافت کریں۔" +lang: ur-in +--- + +ایک عام غلط فہمی یہ ہے کہ ایتھیریم پر تعمیر کرنے کے لیے ڈیولپرز کو [smart contracts](/developers/docs/smart-contracts/) لکھنا ضروری ہے۔ یہ غلط ہے۔ +ایتھیریم نیٹ ورک اور کمیونٹی کی خوبیوں میں سے ایک یہ ہے کہ آپ تقریباً کسی بھی پروگرامنگ زبان میں [حصہ لے](/community/) سکتے ہیں۔ + +ایتھیریم اور اس کی کمیونٹی اوپن سورس کو اپناتے ہیں۔ آپ کمیونٹی پروجیکٹس - کلائنٹ امپلیمنٹیشنز، APIs، ڈیولپمنٹ فریم ورکس، ٹیسٹنگ ٹولز - بہت سی مختلف زبانوں میں تلاش کر سکتے ہیں۔ + +## اپنی زبان منتخب کریں {#data} + +پروجیکٹس، وسائل، اور ورچوئل کمیونٹیز تلاش کرنے کے لیے اپنی پسند کی پروگرامنگ زبان منتخب کریں: + +- [Dart ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/dart/) +- [Delphi ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/delphi/) +- [.NET ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/dot-net/) +- [Elixir ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/elixir/) +- [Go ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/golang/) +- [Java ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/java/) +- [JavaScript ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/javascript/) +- [Python ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/python/) +- [Ruby ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/ruby/) +- [Rust ڈیولپرز کے لیے ایتھیریم](/developers/docs/programming-languages/rust/) + +### کیا ہوگا اگر میری زبان سپورٹ نہیں کی جاتی {#other-lang} + +اگر آپ کسی اضافی پروگرامنگ زبان کے لیے وسائل سے لنک کرنا یا ورچوئل کمیونٹی کی طرف اشارہ کرنا چاہتے ہیں تو آپ [ایک ایشو کھول کر](https://github.com/ethereum/ethereum-org-website/issues/new/choose) ایک نئے صفحے کی درخواست کر سکتے ہیں۔ + +اگر آپ صرف ایک ایسی زبان کا استعمال کرتے ہوئے بلاک چین کے ساتھ انٹرفیس کرنے کے لیے کوڈ لکھنا چاہتے ہیں جو فی الحال سپورٹ نہیں کی جاتی ہے +تو آپ ایتھیریم نیٹ ورک سے منسلک ہونے کے لیے [JSON-RPC انٹرفیس](/developers/docs/apis/json-rpc/) کا استعمال کر سکتے ہیں۔ کوئی بھی پروگرامنگ +زبان جو TCP/IP استعمال کر سکتی ہے وہ اس انٹرفیس کا استعمال کر سکتی ہے۔ diff --git a/public/content/translations/ur/developers/docs/programming-languages/java/index.md b/public/content/translations/ur/developers/docs/programming-languages/java/index.md new file mode 100644 index 00000000000..569f3c5f99d --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/java/index.md @@ -0,0 +1,64 @@ +--- +title: "جاوا ڈیولپرز کے لیے ایتھیریم" +description: "جاوا پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھیریم کے لیے ڈیولپ کرنا سیکھیں۔" +lang: ur-in +incomplete: true +--- + +جاوا پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھیریم کے لیے ڈیولپ کرنا سیکھیں۔ + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps قابل اعتماد ہو سکتی ہیں، یعنی ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق چلیں گی۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتی ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +**جاوا کو ایتھیریم کے ساتھ انٹیگریٹ کرنے کے لیے اپنے پہلے قدم اٹھائیں۔** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers.](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## ایتھریم کلائنٹس کے ساتھ کام کرنا {#working-with-ethereum-clients} + +دو معروف جاوا ایتھیریم کلائنٹس، [Web3J](https://github.com/web3j/web3j) اور Hyperledger Besu کا استعمال کرنا سیکھیں۔ + +- [جاوا، ایکلپس، اور Web3J کے ساتھ ایک ایتھیریم کلائنٹ سے کنیکٹ کرنا](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) +- [جاوا اور Web3j کے ساتھ ایک ایتھیریم اکاؤنٹ کا نظم کرنا](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) +- [اپنے اسمارٹ کنٹریکٹ سے ایک جاوا ریپر جنریٹ کرنا](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [ایک ایتھیریم اسمارٹ کنٹریکٹ کے ساتھ تعامل کرنا](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [ایتھیریم اسمارٹ کنٹریکٹ ایونٹس کو سننا](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [بیسو (پینتھیون)، جاوا ایتھیریم کلائنٹ کا لینکس کے ساتھ استعمال](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [جاوا انٹیگریشن ٹیسٹس میں ایک ہائپرلیجر بیسو (پینتھیون) نوڈ چلانا](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Web3j چیٹ شیٹ](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c) + +[ethers-kt](https://github.com/Kr1ptal/ethers-kt) کا استعمال کرنا سیکھیں، جو EVM پر مبنی بلاک چینز کے ساتھ تعامل کے لیے ایک غیر مطابقت پذیر، اعلی کارکردگی والی کوٹلن لائبریری ہے۔ JVM اور اینڈرائڈ پلیٹ فارمز کو ہدف بنانا۔ + +- [ERC20 ٹوکنز منتقل کریں](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) +- [ایونٹ لسننگ کے ساتھ UniswapV2 سویپ](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) +- [ETH / ERC20 بیلنس ٹریکر](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) + +## درمیانی سطح کے مضامین {#intermediate-articles} + +- [IPFS کے ساتھ ایک جاوا ایپلیکیشن میں اسٹوریج کا نظم کرنا](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) +- [Web3j کے ساتھ جاوا میں ERC20 ٹوکنز کا نظم کرنا](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) +- [Web3j ٹرانزیکشن مینیجرز](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) + +## استعمال کے جدید پیٹرن {#advanced-use-patterns} + +- [ایک جاوا اسمارٹ کنٹریکٹ ڈیٹا کیشے بنانے کے لیے Eventeum کا استعمال کرنا](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) + +## جاوا پروجیکٹس اور ٹولز {#java-projects-and-tools} + +- [Web3J (ایتھیریم کلائنٹس کے ساتھ تعامل کے لیے لائبریری)](https://github.com/web3j/web3j) +- [ethers-kt (EVM پر مبنی بلاک چینز کے لیے غیر مطابقت پذیر، اعلی کارکردگی والی کوٹلن/جاوا/اینڈرائڈ لائبریری۔)](https://github.com/Kr1ptal/ethers-kt) +- [Eventeum (ایونٹ لسنر)](https://github.com/ConsenSys/eventeum) +- [Mahuta (IPFS ڈیولپمنٹ ٹولز)](https://github.com/ConsenSys/mahuta) + +مزید وسائل کی تلاش ہے؟ [ethereum.org/developers.](/developers/) دیکھیں + +## جاوا کمیونٹی کے معاونین {#java-community-contributors} + +- [IO Builders](https://io.builders) +- [Kauri](https://kauri.io) diff --git a/public/content/translations/ur/developers/docs/programming-languages/javascript/index.md b/public/content/translations/ur/developers/docs/programming-languages/javascript/index.md new file mode 100644 index 00000000000..3eb5c4ccd71 --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/javascript/index.md @@ -0,0 +1,72 @@ +--- +title: "جاوا اسکرپٹ ڈیولپرز کے لیے Ethereum" +description: "جاوا اسکرپٹ پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے ڈیولپ کرنے کا طریقہ سیکھیں۔" +lang: ur-in +--- + +جاوا اسکرپٹ Ethereum ایکو سسٹم کی سب سے مقبول زبانوں میں سے ایک ہے۔ درحقیقت، ایک [ٹیم](https://github.com/ethereumjs) موجود ہے جو زیادہ سے زیادہ Ethereum کو جاوا اسکرپٹ میں لانے کے لیے وقف ہے۔ + +[اسٹیک کے تمام لیولز پر](/developers/docs/ethereum-stack/) جاوا اسکرپٹ (یا اس سے ملتی جلتی کوئی چیز) لکھنے کے مواقع موجود ہیں۔ + +## Ethereum کے ساتھ تعامل کریں {#interact-with-ethereum} + +### جاوا اسکرپٹ API لائبریریاں {#javascript-api-libraries} + +اگر آپ بلاک چین کو کوئری کرنے، ٹرانزیکشنز بھیجنے اور مزید بہت کچھ کے لیے جاوا اسکرپٹ لکھنا چاہتے ہیں، تو ایسا کرنے کا سب سے آسان طریقہ [جاوا اسکرپٹ API لائبریری](/developers/docs/apis/javascript/) کا استعمال کرنا ہے۔ یہ APIs ڈیولپرز کو [Ethereum نیٹ ورک میں موجود نوڈز](/developers/docs/nodes-and-clients/) کے ساتھ آسانی سے تعامل کرنے کی اجازت دیتی ہیں۔ + +آپ Ethereum پر اسمارٹ کنٹریکٹس کے ساتھ تعامل کرنے کے لیے ان لائبریریوں کا استعمال کر سکتے ہیں، لہذا ایک ایسی dApp بنانا ممکن ہے جہاں آپ پہلے سے موجود کنٹریکٹس کے ساتھ تعامل کرنے کے لیے صرف جاوا اسکرپٹ کا استعمال کریں۔ + +**ملاحظہ کریں** + +- [Web3.js](https://web3js.readthedocs.io) +- [Ethers.js](https://ethers.org) – _اس میں جاوا اسکرپٹ اور ٹائپ اسکرپٹ میں Ethereum والیٹ کا نفاذ اور یوٹیلیٹیز شامل ہیں۔_ +- [viem](https://viem.sh) – _Ethereum کے لیے ایک ٹائپ اسکرپٹ انٹرفیس جو Ethereum کے ساتھ تعامل کے لیے نچلی سطح کے اسٹیٹ لیس پریمیٹیوز فراہم کرتا ہے۔_ +- [Drift](https://ryangoree.github.io/drift/) – _ایک ٹائپ اسکرپٹ میٹا لائبریری جس میں بلٹ ان کیشنگ، ہکس، اور ٹیسٹ موکس شامل ہیں تاکہ ویب 3 لائبریریوں میں آسانی سے Ethereum ڈیولپمنٹ کی جا سکے۔_ + +### اسمارٹ کنٹریکٹس {#smart-contracts} + +اگر آپ جاوا اسکرپٹ ڈیولپر ہیں اور اپنا اسمارٹ کنٹریکٹ لکھنا چاہتے ہیں، تو آپ [Solidity](https://solidity.readthedocs.io) سے واقف ہونا چاہیں گے۔ یہ سب سے مقبول اسمارٹ کنٹریکٹ زبان ہے اور یہ نحوی طور پر جاوا اسکرپٹ سے ملتی جلتی ہے، جو اسے سیکھنا آسان بنا سکتا ہے۔ + +[اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) کے بارے میں مزید۔ + +## پروٹوکول کو سمجھیں {#understand-the-protocol} + +### Ethereum ورچوئل مشین {#the-ethereum-virtual-machine} + +[Ethereum کی ورچوئل مشین](/developers/docs/evm/) کا ایک جاوا اسکرپٹ نفاذ موجود ہے۔ یہ جدید ترین فورک رولز کو سپورٹ کرتا ہے۔ فورک رولز سے مراد منصوبہ بند اپ گریڈ کے نتیجے میں EVM میں کی گئی تبدیلیاں ہیں۔ + +اسے مختلف جاوا اسکرپٹ پیکیجز میں تقسیم کیا گیا ہے جنہیں آپ بہتر طور پر سمجھنے کے لیے دیکھ سکتے ہیں: + +- اکاؤنٹس +- بلاک +- خود بلاک چین +- ٹرانزیکشنز +- اور مزید... + +اس سے آپ کو یہ سمجھنے میں مدد ملے گی کہ "ایک اکاؤنٹ کا ڈیٹا اسٹرکچر کیا ہے؟"۔ + +اگر آپ کوڈ پڑھنا پسند کرتے ہیں، تو یہ جاوا اسکرپٹ ہمارے دستاویزات کو پڑھنے کا ایک بہترین متبادل ہو سکتا ہے۔ + +**EVM کو ملاحظہ کریں** +[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) + +### نوڈز اور کلائنٹس {#nodes-and-clients} + +ایک Ethereumjs کلائنٹ فعال ڈیولپمنٹ میں ہے جو آپ کو یہ جاننے کی اجازت دیتا ہے کہ Ethereum کلائنٹس آپ کی سمجھی جانے والی زبان میں کیسے کام کرتے ہیں؛ جاوا اسکرپٹ! + +**کلائنٹ کو ملاحظہ کریں** +[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) + +## دیگر پروجیکٹس {#other-projects} + +Ethereum جاوا اسکرپٹ کی دنیا میں اور بھی بہت کچھ ہو رہا ہے، بشمول: + +- والیٹ یوٹیلیٹیز کی لائبریریاں۔ +- Ethereum کیز کو جنریٹ، امپورٹ، اور ایکسپورٹ کرنے کے ٹولز۔ +- `merkle-patricia-tree` کا نفاذ – ایک ڈیٹا اسٹرکچر جس کا خاکہ Ethereum ییلو پیپر میں دیا گیا ہے۔ + +[EthereumJS ریپو](https://github.com/ethereumjs) پر جو بھی آپ کو سب سے زیادہ دلچسپ لگے اس کا جائزہ لیں۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/programming-languages/python/index.md b/public/content/translations/ur/developers/docs/programming-languages/python/index.md new file mode 100644 index 00000000000..34383154dce --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/python/index.md @@ -0,0 +1,99 @@ +--- +title: "پائیتھن ڈیولپرز کے لیے Ethereum" +description: "پائیتھن پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے ڈیولپ کرنے کا طریقہ سیکھیں" +lang: ur-in +incomplete: true +--- + +پائیتھن پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے ڈیولپ کرنے کا طریقہ سیکھیں + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps قابل اعتماد ہو سکتی ہیں، یعنی ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق چلیں گی۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتی ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +**Python کو Ethereum کے ساتھ مربوط کرنے کے لیے اپنے پہلے قدم اٹھائیں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [بلاک چین 2023 رپورٹ میں پائیتھن کی حالت](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) + +## ابتدائی مضامین {#beginner-articles} + +- [web3.py کا جائزہ](https://web3py.readthedocs.io/en/latest/overview.html) +- [Ethereum پائیتھن ایکو سسٹم کا ٹور](https://snakecharmers.ethereum.org/python-ecosystem/) +- [Ethereum کے لیے ایک (پائیتھن) ڈیولپر کی گائیڈ](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [انعام کے لائق: ایک Ethereum پائیتھن ہیکاتھون گائیڈ](https://snakecharmers.ethereum.org/prize-worthy/) +- [Vyper کے ساتھ اسمارٹ کنٹریکٹس کا تعارف](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Python Flask کا استعمال کرتے ہوئے Ethereum کنٹریکٹ کیسے ڈیولپ کریں؟](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Web3.py کا تعارف · پائیتھن ڈیولپرز کے لیے Ethereum](https://www.dappuniversity.com/articles/web3-py-intro) +- [Python اور web3.py کا استعمال کرتے ہوئے اسمارٹ کنٹریکٹ فنکشن کو کیسے کال کریں](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) + +## درمیانی سطح کے مضامین {#intermediate-articles} + +- [web3.py کے دوست: Ape کا تعارف](https://snakecharmers.ethereum.org/intro-to-ape/) +- [پائیتھن پروگرامرز کے لیے Dapp ڈیولپمنٹ](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) +- [ایک پائیتھن Ethereum انٹرفیس بنانا: حصہ 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [پائیتھن میں Ethereum اسمارٹ کنٹریکٹس: ایک جامع (ish) گائیڈ](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) + +## استعمال کے جدید پیٹرن {#advanced-use-patterns} + +- [web3.py پیٹرنز: ریئل ٹائم ایونٹ سبسکرپشنز](https://snakecharmers.ethereum.org/subscriptions/) +- [web3.py پیٹرنز: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/) +- [Python کا استعمال کرتے ہوئے Ethereum اسمارٹ کنٹریکٹ کو کمپائل، ڈیپلائے اور کال کرنا](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [Slither کے ساتھ Solidity اسمارٹ کنٹریکٹس کا تجزیہ کریں](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [بلاک چین فنٹیک ٹیوٹوریل: پائیتھن کے ساتھ قرض دینا اور لینا](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) + +## آرکائیو شدہ مضامین + +- [Python اور Brownie کے ساتھ اپنا ERC20 ٹوکن ڈیپلائے کریں](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [اسمارٹ کنٹریکٹس کو ڈیپلائے کرنے کے لیے Brownie اور Python کا استعمال](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [Brownie کے ساتھ OpenSea پر NFTs بنانا](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) + +## پائیتھن پروجیکٹس اور ٹولز {#python-projects-and-tools} + +### فعال: {#active} + +- [Web3.py](https://github.com/ethereum/web3.py) - _Ethereum کے ساتھ تعامل کے لیے پائیتھن لائبریری_ +- [Vyper](https://github.com/ethereum/vyper/) - _EVM کے لیے پائیتھونک اسمارٹ کنٹریکٹ زبان_ +- [Ape](https://github.com/ApeWorX/ape) - _Pythonistas، ڈیٹا سائنسدانوں، اور سیکیورٹی پروفیشنلز کے لیے اسمارٹ کنٹریکٹ ڈیولپمنٹ ٹول_ +- [py-evm](https://github.com/ethereum/py-evm) - _Ethereum ورچوئل مشین کا نفاذ_ +- [eth-tester](https://github.com/ethereum/eth-tester) - _Ethereum پر مبنی ایپلی کیشنز کی جانچ کے لیے ٹولز_ +- [eth-utils](https://github.com/ethereum/eth-utils/) - _Ethereum سے متعلقہ کوڈ بیس کے ساتھ کام کرنے کے لیے یوٹیلٹی فنکشنز_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) - _0.5.x سپورٹ کے ساتھ solc solidity کمپائلر کے ارد گرد پائیتھن ریپر_ +- [pymaker](https://github.com/makerdao/pymaker) - _Maker کنٹریکٹس کے لیے پائیتھن API_ +- [siwe](https://github.com/signinwithethereum/siwe-py) - _پائیتھن کے لیے Ethereum کے ساتھ سائن ان کریں (siwe)_ +- [Ethereum انٹیگریشنز کے لیے Web3 DeFi](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _ERC-20, Uniswap اور دیگر مقبول پروجیکٹس کے لیے تیار انٹیگریشنز کے ساتھ ایک پائیتھن پیکیج_ +- [Wake](https://getwake.io) - _کنٹریکٹس کی جانچ، فزنگ، ڈیپلائمنٹ، کمزوری اسکیننگ اور کوڈ نیویگیشن کے لیے آل-ان-ون پائیتھن فریم ورک (لینگویج سرور - [Solidity کے لیے ٹولز](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ + +### آرکائیو شدہ / اب برقرار نہیں رکھا گیا: {#archived--no-longer-maintained} + +- [Trinity](https://github.com/ethereum/trinity) - _Ethereum پائیتھن کلائنٹ_ +- [Mamba](https://github.com/arjunaskykok/mamba) - _Vyper زبان میں لکھے گئے اسمارٹ کنٹریکٹس کو لکھنے، کمپائل کرنے اور ڈیپلائے کرنے کا فریم ورک_ +- [Brownie](https://github.com/eth-brownie/brownie) - _Ethereum اسمارٹ کنٹریکٹس کو ڈیپلائے کرنے، جانچنے اور ان کے ساتھ تعامل کے لیے پائیتھن فریم ورک_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) - _Ethereum P2P اسٹیک کا نفاذ_ +- [py-wasm](https://github.com/ethereum/py-wasm) - _ویب اسمبلی انٹرپریٹر کا پائیتھن نفاذ_ + +مزید وسائل کی تلاش ہے؟ [ethereum.org/developers](/developers/) دیکھیں۔ + +## پائیتھن ٹولنگ کا استعمال کرنے والے پروجیکٹس {#projects-using-python-tooling} + +درج ذیل Ethereum پر مبنی پروجیکٹس اس صفحہ پر مذکور ٹولز کا استعمال کرتے ہیں۔ متعلقہ اوپن سورس ریپوزٹریز مثال کے طور پر کوڈ اور بہترین طریقوں کے لیے ایک اچھا حوالہ کے طور پر کام کرتی ہیں۔ + +- [Yearn Finance](https://yearn.finance/) اور [Yearn Vault Contracts repository](https://github.com/yearn/yearn-vaults) +- [Curve](https://www.curve.finance/) اور [Curve smart contracts repository](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/) اور [Brownie ٹول چین کا استعمال کرتے ہوئے اسمارٹ کنٹریکٹس](https://github.com/Badger-Finance/badger-system) +- [Sushi](https://sushi.com/) [اپنے ویسٹنگ کنٹریکٹس کو منظم کرنے اور ڈیپلائے کرنے میں پائیتھن کا استعمال کرتا ہے](https://github.com/sushiswap/sushi-vesting-protocols) +- [Alpha Finance](https://alphafinance.io/)، جو Alpha Homora کی شہرت کا حامل ہے، [اسمارٹ کنٹریکٹس کی جانچ اور ڈیپلائے کرنے کے لیے Brownie کا استعمال کرتا ہے](https://github.com/AlphaFinanceLab/alpha-staking-contract) + +## پائیتھن کمیونٹی ڈسکشن {#python-community-contributors} + +- Web3.py اور دیگر پائیتھن فریم ورک ڈسکشن کے لیے [Ethereum Python Community Discord](https://discord.gg/9zk7snTfWe) +- Vyper اسمارٹ کنٹریکٹ پروگرامنگ ڈسکشن کے لیے [Vyper Discord](https://discord.gg/SdvKC79cJk) + +## دیگر مجموعی فہرستیں {#other-aggregated-lists} + +Vyper وکی میں [Vyper کے لیے وسائل کی ایک ناقابل یقین فہرست](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) ہے \ No newline at end of file diff --git a/public/content/translations/ur/developers/docs/programming-languages/ruby/index.md b/public/content/translations/ur/developers/docs/programming-languages/ruby/index.md new file mode 100644 index 00000000000..bea411df1b0 --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/ruby/index.md @@ -0,0 +1,60 @@ +--- +title: "روبی ڈیولپرز کے لیے ایتھریم" +description: "روبی پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں۔" +lang: ur-in +incomplete: false +--- + +روبی پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے ایتھریم کے لیے ڈیولپ کرنے کا طریقہ سیکھیں۔ + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps ٹرسٹ لیس ہو سکتے ہیں، جس کا مطلب ہے کہ ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق ہی چلیں گے۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتے ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +**روبی کو ایتھریم کے ساتھ انٹیگریٹ کرنے کے لیے اپنے پہلے قدم اٹھائیں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## ابتدائی مضامین {#beginner-articles} + +- [بالآخر Ethereum اکاؤنٹس کو سمجھنا](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [آخرکار MetaMask کے ساتھ ریل یوزرس کی توثیق کرنا](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) +- [روبی کا استعمال کرتے ہوئے ایتھریم نیٹ ورک سے کیسے جڑیں](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) +- [روبی میں نیا ایتھریم ایڈریس کیسے جنریٹ کریں](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) + +## درمیانی سطح کے مضامین {#intermediate-articles} + +- [روبی کے ساتھ بلاک چین ایپ](https://www.nopio.com/blog/blockchain-app-ruby/) +- [ایتھریم سے منسلک روبی کا استعمال کرکے، اسمارٹ کنٹریکٹ کو ایگزیکیوٹ کریں](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) + +## روبی پروجیکٹس اور ٹولز {#ruby-projects-and-tools} + +### فعال {#active} + +- [eth.rb](https://github.com/q9f/eth.rb) - _ایتھریم اکاؤنٹس، میسیجز، اور ٹرانزیکشنز کو ہینڈل کرنے کے لیے روبی لائبریری اور RPC-کلائنٹ_ +- [keccak.rb](https://github.com/q9f/keccak.rb) - _ایتھریم کے ذریعے استعمال کیا جانے والا Keccak (SHA3) ہیش_ +- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Sign-In with Ethereum کا روبی امپلیمنٹیشن_ +- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _ریلز جیم جو SIWE لوکل سائن ان روٹس کو شامل کرتا ہے_ +- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _کسٹم کنٹرولر کے ساتھ روبی آن ریلز کا استعمال کرتے ہوئے SIWE کی مثال_ +- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _Sign In With Ethereum (SIWE) کے لیے OmniAuth اسٹریٹجی_ +- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _NFT کی ملکیت کے ذریعے توثیق کے لیے OmniAuth اسٹریٹجی_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _ایتھریم آن ریلز ٹیمپلیٹ جو MetaMask کو روبی آن ریلز سے جوڑنے کی اجازت دیتا ہے_ + +### آرکائیو شدہ / اب برقرار نہیں رکھا گیا {#archived--no-longer-maintained} + +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _روبی کے ساتھ ایتھریم نوڈ کے RPC میتھڈز کو کال کرنا_ +- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _BIP32 اسٹینڈرڈ کے مطابق ایک ہائیرارکیکل ڈیٹرمنسٹک والیٹ سے ETH ایڈریسز جنریٹ کرنے کے لیے روبی لائبریری_ +- [etherlite](https://github.com/budacom/etherlite) - _روبی آن ریلز کے لیے ایتھریم انٹیگریشن_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _روبی ایتھریم کلائنٹ جو ٹرانزیکشنز بھیجنے، کنٹریکٹس بنانے اور ان کے ساتھ تعامل کرنے کے لیے JSON-RPC انٹرفیس کا استعمال کرتا ہے اور ساتھ ہی ایتھریم نوڈ کے ساتھ کام کرنے کے لیے مفید ٹول کٹ بھی ہے_ +- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _OmniAuth کے لیے ایتھریم پرووائیڈر اسٹریٹجی کو امپلیمنٹ کرتا ہے_ + +مزید وسائل کی تلاش ہے؟ [ہمارے ڈویلپرز کا ہوم](/developers/) دیکھیں۔ + +## روبی کمیونٹی کنٹریبیوٹرز {#ruby-community-contributors} + +[ایتھریم روبی ٹیلیگرام گروپ](https://t.me/ruby_eth) تیزی سے بڑھتی ہوئی کمیونٹی کا میزبان ہے اور مذکورہ بالا کسی بھی پروجیکٹ اور متعلقہ عنوانات پر بات چیت کے لیے ایک وقف شدہ وسیلہ ہے۔ diff --git a/public/content/translations/ur/developers/docs/programming-languages/rust/index.md b/public/content/translations/ur/developers/docs/programming-languages/rust/index.md new file mode 100644 index 00000000000..32703da38bb --- /dev/null +++ b/public/content/translations/ur/developers/docs/programming-languages/rust/index.md @@ -0,0 +1,65 @@ +--- +title: "Rust ڈیولپرز کے لیے Ethereum" +description: "rust پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے ڈیولپ کرنے کا طریقہ سیکھیں" +lang: ur-in +incomplete: true +--- + +Rust پر مبنی پروجیکٹس اور ٹولنگ کا استعمال کرتے ہوئے Ethereum کے لیے ڈیولپ کرنے کا طریقہ سیکھیں + +غیر مرکزی ایپلی کیشنز (یا "dapps") بنانے کے لیے Ethereum کا استعمال کریں جو کرپٹو کرنسی اور بلاک چین ٹیکنالوجی کے فوائد کا استعمال کرتی ہیں۔ یہ dapps قابل اعتماد ہو سکتی ہیں، یعنی ایک بار جب انہیں Ethereum پر ڈیپلائے کر دیا جاتا ہے، تو وہ ہمیشہ پروگرام کے مطابق چلیں گی۔ وہ نئی قسم کی مالیاتی ایپلی کیشنز بنانے کے لیے ڈیجیٹل اثاثوں کو کنٹرول کر سکتی ہیں۔ وہ غیر مرکزی ہو سکتی ہیں، یعنی کوئی واحد ادارہ یا شخص انہیں کنٹرول نہیں کرتا ہے اور انہیں سنسر کرنا تقریباً ناممکن ہے۔ + +## اسمارٹ کنٹریکٹس اور Solidity زبان کے ساتھ شروعات کرنا {#getting-started-with-smart-contracts-and-solidity} + +**Rust کو Ethereum کے ساتھ مربوط کرنے کے لیے اپنے پہلے قدم اٹھائیں** + +پہلے مزید بنیادی پرائمر کی ضرورت ہے؟ [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/) دیکھیں۔ + +- [بلاک چین کی وضاحت](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [اسمارٹ کنٹریکٹس کو سمجھنا](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [اپنا پہلا اسمارٹ کنٹریکٹ لکھیں](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidity کو کمپائل اور ڈیپلائے کرنے کا طریقہ سیکھیں](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## ابتدائی مضامین {#beginner-articles} + +- [Rust Ethereum کلائنٹ](https://openethereum.github.io/) \* **نوٹ کریں کہ OpenEthereum [کو فرسودہ قرار دے دیا گیا ہے](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) اور اب اس کی دیکھ بھال نہیں کی جا رہی ہے۔** اسے احتیاط کے ساتھ استعمال کریں اور ترجیحاً کسی دوسرے کلائنٹ کے نفاذ پر سوئچ کریں۔ +- [Rust کا استعمال کرتے ہوئے Ethereum پر ٹرانزیکشن بھیجنا](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) +- [Kovan کے لیے rust Wasm میں کنٹریکٹس لکھنے کے طریقے پر ایک مرحلہ وار ٹیوٹوریل](https://github.com/paritytech/pwasm-tutorial) + +## درمیانی سطح کے مضامین {#intermediate-articles} + +## استعمال کے جدید پیٹرن {#advanced-use-patterns} + +- [Ethereum جیسے نیٹ ورک کے ساتھ تعامل کرنے کے لیے pwasm_ethereum externs لائبریری](https://github.com/openethereum/pwasm-ethereum) + +- [JavaScript اور Rust کا استعمال کرتے ہوئے ایک غیر مرکزی چیٹ بنائیں](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) + +- [Vue.js اور Rust کا استعمال کرتے ہوئے ایک غیر مرکزی ٹوڈو ایپ بنائیں](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) + +- [Rust میں ایک بلاک چین بنائیں](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) + +## Rust پروجیکٹس اور ٹولز {#rust-projects-and-tools} + +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Ethereum جیسے نیٹ ورک کے ساتھ تعامل کرنے کے لیے externs کا مجموعہ_ +- [Lighthouse](https://github.com/sigp/lighthouse) - _تیز رفتار Ethereum کنسینسس لیئر کلائنٹ_ +- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _WebAssembly کے ایک ڈیٹرمنسٹک سب سیٹ کا استعمال کرتے ہوئے Ethereum اسمارٹ کنٹریکٹ ایگزیکیوشن لیئر کا مجوزہ ری ڈیزائن_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API حوالہ_ +- [Solaris](https://github.com/paritytech/sol-rs) - _مقامی Parity کلائنٹ EVM کا استعمال کرتے ہوئے Solidity اسمارٹ کنٹریکٹس یونٹ ٹیسٹ ہارنس۔_ +- [SputnikVM](https://github.com/rust-blockchain/evm) - _Rust Ethereum ورچوئل مشین کا نفاذ_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Rust میں Wavelet اسمارٹ کنٹریکٹ_ +- [Foundry](https://github.com/foundry-rs/foundry) - _Ethereum ایپلیکیشن ڈیولپمنٹ کے لیے ٹول کٹ_ +- [Alloy](https://alloy.rs) - _Ethereum اور دیگر EVM پر مبنی چینز کے ساتھ تعامل کے لیے اعلی کارکردگی والی، اچھی طرح سے آزمائی گئی اور دستاویزی لائبریریاں۔_ +- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Ethereum لائبریری اور والیٹ کا نفاذ_ +- [SewUp](https://github.com/second-state/SewUp) - _ایک لائبریری جو آپ کو Rust کے ساتھ اپنا Ethereum ویب اسمبلی کنٹریکٹ بنانے میں مدد کرتی ہے اور بالکل ایک عام بیک اینڈ میں ڈیولپ کرنے کی طرح ہے_ +- [Substreams](https://github.com/streamingfast/substreams) - _متوازی بلاک چین ڈیٹا انڈیکسنگ ٹیکنالوجی_ +- [Reth](https://github.com/paradigmxyz/reth) Reth (Rust Ethereum کا مخفف) ایک نیا Ethereum فل نوڈ نفاذ ہے +- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Ethereum ایکو سسٹم میں Rust میں لکھے گئے پروجیکٹس کا ایک منتخب کردہ مجموعہ_ + +مزید وسائل کی تلاش ہے؟ [ethereum.org/developers.](/developers/) دیکھیں + +## Rust کمیونٹی کے شراکت دار {#rust-community-contributors} + +- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) +- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) +- [Parity Gitter](https://gitter.im/paritytech/parity) +- [Enigma](https://discord.gg/SJK32GY) diff --git a/public/content/translations/ur/developers/docs/scaling/index.md b/public/content/translations/ur/developers/docs/scaling/index.md new file mode 100644 index 00000000000..41d0283834c --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/index.md @@ -0,0 +1,113 @@ +--- +title: "پیمانہ کاری" +description: "مختلف اسکیلنگ کے اختیارات کا ایک تعارف جو فی الحال Ethereum کمیونٹی کی طرف سے تیار کیے جا رہے ہیں۔" +lang: ur-in +sidebarDepth: 3 +--- + +## اسکیلنگ کا جائزہ {#scaling-overview} + +جیسے جیسے Ethereum استعمال کرنے والے لوگوں کی تعداد میں اضافہ ہوا ہے، بلاک چین صلاحیت کی کچھ حدود تک پہنچ گیا ہے۔ اس نے نیٹ ورک کو استعمال کرنے کی لاگت میں اضافہ کیا ہے، جس سے "اسکیلنگ حل" کی ضرورت پیدا ہوئی ہے۔ ایسے متعدد حل ہیں جن پر تحقیق، جانچ اور عمل درآمد کیا جا رہا ہے جو یکساں اہداف حاصل کرنے کے لیے مختلف طریقے اپناتے ہیں۔ + +اسکیل ایبلیٹی کا بنیادی مقصد وکندریقرت یا سیکورٹی پر سمجھوتہ کیے بغیر ٹرانزیکشن کی رفتار (تیز تر حتمیت) اور ٹرانزیکشن تھرو پٹ (فی سیکنڈ ٹرانزیکشنز کی زیادہ تعداد) کو بڑھانا ہے۔ لیئر 1 Ethereum بلاک چین پر، زیادہ مانگ کی وجہ سے ٹرانزیکشنز سست ہو جاتی ہیں اور ناقابل عمل [گیس کی قیمتیں](/developers/docs/gas/)۔ رفتار اور تھرو پٹ کے لحاظ سے نیٹ ورک کی صلاحیت کو بڑھانا Ethereum کو بامعنی اور بڑے پیمانے پر اپنانے کے لیے بنیادی ہے۔ + +اگرچہ رفتار اور تھرو پٹ اہم ہیں، یہ ضروری ہے کہ ان اہداف کو فعال کرنے والے اسکیلنگ حل وکندریقرت اور محفوظ رہیں۔ نوڈ آپریٹرز کے لیے داخلے کی رکاوٹ کو کم رکھنا مرکزی اور غیر محفوظ کمپیوٹنگ طاقت کی طرف پیشرفت کو روکنے کے لیے اہم ہے۔ + +تصوراتی طور پر ہم پہلے اسکیلنگ کی درجہ بندی آن چین اسکیلنگ یا آف چین اسکیلنگ کے طور پر کرتے ہیں۔ + +## شرائط {#prerequisites} + +آپ کو تمام بنیادی موضوعات کی اچھی سمجھ ہونی چاہیے۔ اسکیلنگ حل کو نافذ کرنا ایک جدید کام ہے کیونکہ ٹیکنالوجی کم آزمائی گئی ہے، اور اس پر تحقیق اور ترقی کا کام جاری ہے۔ + +## آن چین اسکیلنگ {#onchain-scaling} + +آن چین اسکیلنگ کے لیے Ethereum پروٹوکول (لیئر 1 [Mainnet](/glossary/#mainnet)) میں تبدیلیوں کی ضرورت ہوتی ہے۔ ایک طویل عرصے سے، یہ توقع کی جاتی تھی کہ بلاک چین کی شارڈنگ سے Ethereum کو اسکیل کیا جائے گا۔ اس میں بلاک چین کو الگ الگ ٹکڑوں (شارڈز) میں تقسیم کرنا شامل تھا جن کی تصدیق توثیق کاروں (validators) کے ذیلی سیٹوں کے ذریعے کی جانی تھی۔ تاہم، لیئر-2 رول اپس کے ذریعے اسکیلنگ نے بنیادی اسکیلنگ تکنیک کے طور پر جگہ لے لی ہے۔ اس کی حمایت ڈیٹا کی ایک نئی سستی شکل کے اضافے سے ہوتی ہے جو Ethereum بلاکس کے ساتھ منسلک ہوتی ہے جسے خاص طور پر صارفین کے لیے رول اپس سستے بنانے کے لیے ڈیزائن کیا گیا ہے۔ + +### شارڈنگ {#sharding} + +شارڈنگ ڈیٹا بیس کو تقسیم کرنے کا عمل ہے۔ توثیق کاروں (validators) کے ذیلی سیٹ انفرادی شارڈز کے لیے ذمہ دار ہوں گے بجائے اس کے کہ وہ پورے Ethereum کا ٹریک رکھیں۔ شارڈنگ ایک طویل عرصے تک Ethereum [روڈ میپ](/roadmap/) پر تھا، اور ایک بار اس کا مقصد The Merge سے پہلے پروف-آف-اسٹیک پر بھیجنا تھا۔ تاہم، [لیئر 2 رول اپس](#layer-2-scaling) کی تیز رفتار ترقی اور [Danksharding](/roadmap/danksharding) کی ایجاد (رول اپ ڈیٹا کے بلا بس کو Ethereum بلاکس میں شامل کرنا جن کی توثیق کاروں (validators) کے ذریعہ بہت موثر طریقے سے تصدیق کی جا سکتی ہے) نے Ethereum کمیونٹی کو شارڈنگ کے ذریعے اسکیلنگ کے بجائے رول اپ-سینٹرک اسکیلنگ کی حمایت کرنے پر مجبور کیا ہے۔ اس سے Ethereum کی اتفاق رائے کی منطق کو آسان رکھنے میں بھی مدد ملے گی۔ + +## آف چین اسکیلنگ {#offchain-scaling} + +آف چین حل لیئر 1 مین نیٹ سے الگ نافذ کیے جاتے ہیں - انہیں موجودہ Ethereum پروٹوکول میں کسی تبدیلی کی ضرورت نہیں ہے۔ کچھ حل، جنہیں "لیئر 2" حل کہا جاتا ہے، اپنی سیکیورٹی براہ راست لیئر 1 Ethereum اتفاق رائے سے حاصل کرتے ہیں، جیسے کہ [آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups/)، [زیرو-نالج رول اپس](/developers/docs/scaling/zk-rollups/) یا [اسٹیٹ چینلز](/developers/docs/scaling/state-channels/)۔ دیگر حلوں میں مختلف شکلوں میں نئی ​​چینز کی تخلیق شامل ہے جو اپنی سیکیورٹی مین نیٹ سے الگ حاصل کرتی ہیں، جیسے [سائیڈ چینز](#sidechains)، [ویلیڈیمز](#validium)، یا [پلازما چینز](#plasma)۔ یہ حل مین نیٹ کے ساتھ بات چیت کرتے ہیں لیکن مختلف قسم کے اہداف حاصل کرنے کے لیے اپنی سیکیورٹی مختلف طریقے سے حاصل کرتے ہیں۔ + +### لیئر 2 اسکیلنگ {#layer-2-scaling} + +آف چین حلوں کا یہ زمرہ اپنی سیکیورٹی مین نیٹ Ethereum سے حاصل کرتا ہے۔ + +لیئر 2 حلوں کے لیے ایک اجتماعی اصطلاح ہے جو آپ کی ایپلیکیشن کو اسکیل کرنے میں مدد کے لیے ڈیزائن کیے گئے ہیں، یہ Ethereum مین نیٹ (لیئر 1) سے باہر ٹرانزیکشنز کو سنبھال کر مین نیٹ کے مضبوط وکندریقرت سیکیورٹی ماڈل سے فائدہ اٹھاتے ہیں۔ جب نیٹ ورک مصروف ہوتا ہے تو ٹرانزیکشن کی رفتار متاثر ہوتی ہے، جس سے کچھ قسم کے dapps کے لیے صارف کا تجربہ خراب ہوتا ہے۔ اور جیسے جیسے نیٹ ورک مصروف ہوتا جاتا ہے، گیس کی قیمتیں بڑھ جاتی ہیں کیونکہ ٹرانزیکشن بھیجنے والے ایک دوسرے سے زیادہ بولی لگانے کی کوشش کرتے ہیں۔ یہ Ethereum کے استعمال کو بہت مہنگا بنا سکتا ہے۔ + +زیادہ تر لیئر 2 حل ایک سرور یا سرورز کے کلسٹر کے ارد گرد مرکوز ہوتے ہیں، جن میں سے ہر ایک کو نوڈ، ویلیڈیٹر، آپریٹر، سیکوینسر، بلاک پروڈیوسر، یا اسی طرح کی اصطلاح کہا جا سکتا ہے۔ نفاذ پر منحصر ہے، یہ لیئر 2 نوڈس ان افراد، کاروباروں یا اداروں کے ذریعے چلائے جا سکتے ہیں جو انہیں استعمال کرتے ہیں، یا کسی تیسرے فریق آپریٹر کے ذریعے، یا افراد کے ایک بڑے گروپ کے ذریعے (مین نیٹ کی طرح)۔ عام طور پر، ٹرانزیکشنز ان لیئر 2 نوڈس کو جمع کی جاتی ہیں بجائے اس کے کہ انہیں براہ راست لیئر 1 (مین نیٹ) میں جمع کیا جائے۔ کچھ حلوں کے لیے، لیئر 2 مثال پھر انہیں گروپوں میں بیچ کرتی ہے انہیں لیئر 1 پر اینکر کرنے سے پہلے، جس کے بعد وہ لیئر 1 کے ذریعے محفوظ ہو جاتے ہیں اور انہیں تبدیل نہیں کیا جا سکتا۔ یہ کیسے کیا جاتا ہے اس کی تفصیلات مختلف لیئر 2 ٹیکنالوجیز اور نفاذ کے درمیان نمایاں طور پر مختلف ہوتی ہیں۔ + +ایک مخصوص لیئر 2 مثال بہت سی ایپلی کیشنز کے ذریعے کھلی اور مشترکہ ہو سکتی ہے، یا کسی ایک پروجیکٹ کے ذریعے تعینات کی جا سکتی ہے اور صرف ان کی ایپلیکیشن کو سپورٹ کرنے کے لیے وقف ہو۔ + +#### لیئر 2 کی ضرورت کیوں ہے؟ {#why-is-layer-2-needed} + +- فی سیکنڈ ٹرانزیکشنز میں اضافہ صارف کے تجربے کو بہت بہتر بناتا ہے، اور مین نیٹ Ethereum پر نیٹ ورک کی بھیڑ کو کم کرتا ہے۔ +- ٹرانزیکشنز کو مین نیٹ Ethereum پر ایک ہی ٹرانزیکشن میں رول اپ کیا جاتا ہے، جس سے صارفین کے لیے گیس کی فیس کم ہوتی ہے اور Ethereum کو ہر جگہ لوگوں کے لیے زیادہ جامع اور قابل رسائی بناتا ہے۔ +- اسکیل ایبلیٹی میں کوئی بھی اپ ڈیٹ وکندریقرت یا سیکیورٹی کی قیمت پر نہیں ہونی چاہیے – لیئر 2 Ethereum کے اوپر بنتا ہے۔ +- یہاں ایپلیکیشن کے لیے مخصوص لیئر 2 نیٹ ورکس ہیں جو بڑے پیمانے پر اثاثوں کے ساتھ کام کرتے وقت اپنی اپنی افادیت لاتے ہیں۔ + +[لیئر 2 پر مزید](/layer-2/)۔ + +#### رول اپس {#rollups} + +رول اپس لیئر 1 کے باہر ٹرانزیکشن کا عمل انجام دیتے ہیں اور پھر ڈیٹا کو لیئر 1 پر پوسٹ کیا جاتا ہے جہاں اتفاق رائے تک پہنچا جاتا ہے۔ چونکہ ٹرانزیکشن ڈیٹا لیئر 1 بلاکس میں شامل ہوتا ہے، یہ رول اپس کو مقامی Ethereum سیکیورٹی کے ذریعے محفوظ رکھنے کی اجازت دیتا ہے۔ + +مختلف سیکیورٹی ماڈلز کے ساتھ رول اپس کی دو قسمیں ہیں: + +- **آپٹیمسٹک رول اپس**: یہ فرض کرتا ہے کہ ٹرانزیکشنز بطور ڈیفالٹ درست ہیں اور کسی چیلنج کی صورت میں، [**فراڈ پروف**](/glossary/#fraud-proof) کے ذریعے، صرف کمپیوٹیشن چلاتا ہے۔ [آپٹیمسٹک رول اپس پر مزید](/developers/docs/scaling/optimistic-rollups/)۔ +- **زیرو-نالج رول اپس**: آف چین کمپیوٹیشن چلاتا ہے اور چین کو [**ویلیڈیٹی پروف**](/glossary/#validity-proof) جمع کرتا ہے۔ [زیرو-نالج رول اپس پر مزید](/developers/docs/scaling/zk-rollups/)۔ + +#### اسٹیٹ چینلز {#channels} + +اسٹیٹ چینلز ملٹی سگ کنٹریکٹس کا استعمال کرتے ہیں تاکہ شرکاء کو آف چین تیزی اور آزادانہ طور پر ٹرانزیکشن کرنے کے قابل بنایا جا سکے، پھر مین نیٹ کے ساتھ حتمیت کو طے کریں۔ یہ نیٹ ورک کی بھیڑ، فیس، اور تاخیر کو کم سے کم کرتا ہے۔ چینلز کی دو قسمیں فی الحال اسٹیٹ چینلز اور ادائیگی کے چینلز ہیں۔ + +[اسٹیٹ چینلز](/developers/docs/scaling/state-channels/) کے بارے میں مزید جانیں۔ + +### سائیڈ چینز {#sidechains} + +سائیڈ چین ایک آزاد EVM-مطابقت رکھنے والا بلاک چین ہے جو مین نیٹ کے متوازی چلتا ہے۔ یہ دو طرفہ برجز کے ذریعے Ethereum کے ساتھ مطابقت رکھتے ہیں اور اپنے منتخب کردہ اتفاق رائے کے قوانین اور بلاک پیرامیٹرز کے تحت چلتے ہیں۔ + +[سائیڈ چینز](/developers/docs/scaling/sidechains/) کے بارے میں مزید جانیں۔ + +### پلازما {#plasma} + +پلازما چین ایک علیحدہ بلاک چین ہے جو مرکزی Ethereum چین سے منسلک ہے اور تنازعات کو ثالثی کرنے کے لیے فراڈ پروفس (جیسے [آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups/)) کا استعمال کرتی ہے۔ + +[پلازما](/developers/docs/scaling/plasma/) کے بارے میں مزید جانیں۔ + +### ویلیڈیم {#validium} + +ایک ویلیڈیم چین زیرو-نالج رول اپس کی طرح ویلیڈیٹی پروفس کا استعمال کرتی ہے لیکن ڈیٹا مرکزی لیئر 1 Ethereum چین پر ذخیرہ نہیں ہوتا ہے۔ اس سے فی ویلیڈیم چین 10 ہزار ٹرانزیکشنز فی سیکنڈ ہو سکتی ہیں اور متعدد چینز متوازی طور پر چلائی جا سکتی ہیں۔ + +[ویلیڈیم](/developers/docs/scaling/validium/) کے بارے میں مزید جانیں۔ + +## اتنے سارے اسکیلنگ حلوں کی ضرورت کیوں ہے؟ {#why-do-we-need-these} + +- متعدد حل نیٹ ورک کے کسی ایک حصے پر مجموعی بھیڑ کو کم کرنے میں مدد کر سکتے ہیں اور ناکامی کے واحد نکات کو بھی روکتے ہیں۔ +- کل اس کے حصوں کے مجموعے سے بڑا ہے۔ مختلف حل ہم آہنگی کے ساتھ موجود اور کام کر سکتے ہیں، جس سے مستقبل میں ٹرانزیکشن کی رفتار اور تھرو پٹ پر ایک تیز رفتار اثر پڑتا ہے۔ +- تمام حلوں کو براہ راست Ethereum اتفاق رائے الگورتھم استعمال کرنے کی ضرورت نہیں ہے، اور متبادل ایسے فوائد پیش کر سکتے ہیں جو دوسری صورت میں حاصل کرنا مشکل ہوگا۔ + +## کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + + + +_نوٹ کریں کہ ویڈیو میں وضاحت "لیئر 2" کی اصطلاح کا استعمال تمام آف چین اسکیلنگ حلوں کے لیے کرتی ہے، جبکہ ہم "لیئر 2" کو ایک آف چین حل کے طور پر مختلف کرتے ہیں جو اپنی سیکیورٹی لیئر 1 مین نیٹ اتفاق رائے کے ذریعے حاصل کرتا ہے۔_ + + + +## مزید پڑھیں {#further-reading} + +- [ایک رول اپ-سینٹرک Ethereum روڈ میپ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ +- [Ethereum کے لیے لیئر 2 اسکیلنگ حلوں پر تازہ ترین تجزیات](https://www.l2beat.com/) +- [Ethereum لیئر 2 اسکیلنگ حلوں کا جائزہ: ایک موازنہ فریم ورک](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [رول اپس کے لیے ایک نامکمل گائیڈ](https://vitalik.eth.limo/general/2021/01/05/rollup.html) +- [Ethereum سے چلنے والے ZK-Rollups: ورلڈ بیٹرز](https://hackmd.io/@canti/rkUT0BD8K) +- [آپٹیمسٹک رول اپس بمقابلہ ZK رول اپس](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [کیوں رول اپس + ڈیٹا شارڈز اعلیٰ اسکیل ایبلیٹی کے لیے واحد پائیدار حل ہیں](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [کس قسم کے لیئر 3s معنی رکھتے ہیں؟](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) +- [ڈیٹا کی دستیابی یا: رول اپس نے پریشان ہونا چھوڑ کر ایتھیریم سے محبت کرنا کیسے سیکھا](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [Ethereum رول اپس کے لیے عملی گائیڈ](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/ur/developers/docs/scaling/optimistic-rollups/index.md new file mode 100644 index 00000000000..86fa898a5c5 --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/optimistic-rollups/index.md @@ -0,0 +1,265 @@ +--- +title: "امید پسندانہ رول اپس" +description: "امید پسندانہ رول اپس کا ایک تعارف— ایک اسکیلنگ حل جو Ethereum کمیونٹی کے ذریعہ استعمال کیا جاتا ہے۔" +lang: ur-in +--- + +امید پسندانہ رول اپس لیئر 2 (L2) پروٹوکولز ہیں جو Ethereum کی بیس لیئر کی تھرو پٹ کو بڑھانے کے لیے ڈیزائن کیے گئے ہیں۔ وہ آف چین ٹرانزیکشنز پر کارروائی کرکے مرکزی Ethereum چین پر کمپیوٹیشن کو کم کرتے ہیں، جس سے پروسیسنگ کی رفتار میں نمایاں بہتری آتی ہے۔ دیگر اسکیلنگ حلوں کے برعکس، جیسے کہ [sidechains](/developers/docs/scaling/sidechains/)، امید پسندانہ رول اپس آن چین ٹرانزیکشن کے نتائج شائع کرکے Mainnet سے سیکیورٹی حاصل کرتے ہیں، یا [plasma chains](/developers/docs/scaling/plasma/)، جو فراڈ پروف کے ساتھ Ethereum پر ٹرانزیکشنز کی تصدیق بھی کرتے ہیں، لیکن ٹرانزیکشن کا ڈیٹا کہیں اور اسٹور کرتے ہیں۔ + +چونکہ کمپیوٹیشن Ethereum استعمال کرنے کا سست، مہنگا حصہ ہے، اس لیے امید پسندانہ رول اپس اسکیل ایبلٹی میں 10-100x تک بہتری پیش کر سکتے ہیں۔ امید پسندانہ رول اپس `calldata` کے طور پر یا [blobs](/roadmap/danksharding/) میں Ethereum میں ٹرانزیکشنز بھی لکھتے ہیں، جس سے صارفین کے لیے گیس کے اخراجات کم ہوتے ہیں۔ + +## شرائط {#prerequisites} + +آپ کو [ایتھیریم اسکیلنگ](/developers/docs/scaling/) اور [لیئر 2](/layer-2/) پر ہمارے صفحات کو پڑھنا اور سمجھنا چاہیے تھا۔ + +## امید پسندانہ رول اپ کیا ہے؟ {#what-is-an-optimistic-rollup} + +ایک امید پسندانہ رول اپ Ethereum کو اسکیل کرنے کا ایک طریقہ ہے جس میں کمپیوٹیشن اور اسٹیٹ اسٹوریج کو آف چین منتقل کرنا شامل ہے۔ امید پسندانہ رول اپس Ethereum کے باہر ٹرانزیکشنز کو انجام دیتے ہیں، لیکن ٹرانزیکشن ڈیٹا کو `calldata` کے طور پر یا [blobs](/roadmap/danksharding/) میں Mainnet پر پوسٹ کرتے ہیں۔ + +امید پسندانہ رول اپ آپریٹرز Ethereum میں جمع کرنے سے پہلے متعدد آف چین ٹرانزیکشنز کو بڑے بیچوں میں ایک ساتھ بنڈل کرتے ہیں۔ یہ نقطہ نظر ہر بیچ میں متعدد ٹرانزیکشنز پر مقررہ اخراجات کو پھیلانے کے قابل بناتا ہے، جس سے آخری صارفین کے لیے فیس کم ہوتی ہے۔ امید پسندانہ رول اپس Ethereum پر پوسٹ کیے گئے ڈیٹا کی مقدار کو کم کرنے کے لیے کمپریشن تکنیک کا بھی استعمال کرتے ہیں۔ + +امید پسندانہ رول اپس کو ”امید پسندانہ“ سمجھا جاتا ہے کیونکہ وہ فرض کرتے ہیں کہ آف چین ٹرانزیکشنز درست ہیں اور آن چین پوسٹ کیے گئے ٹرانزیکشن بیچوں کے لیے موزونیت کے ثبوت شائع نہیں کرتے ہیں۔ یہ امید پسندانہ رول اپس کو [zero-knowledge rollups](/developers/docs/scaling/zk-rollups) سے الگ کرتا ہے جو آف چین ٹرانزیکشنز کے لیے کرپٹوگرافک [proofs of validity](/glossary/#validity-proof) شائع کرتے ہیں۔ + +امید پسندانہ رول اپس اس کے بجائے ان معاملات کا پتہ لگانے کے لیے فراڈ پروف اسکیم پر انحصار کرتے ہیں جہاں ٹرانزیکشنز کا صحیح حساب نہیں لگایا جاتا ہے۔ Ethereum پر رول اپ بیچ جمع ہونے کے بعد، ایک ٹائم ونڈو ہوتی ہے (جسے چیلنج پیریڈ کہا جاتا ہے) جس کے دوران کوئی بھی [fraud proof](/glossary/#fraud-proof) کا حساب لگا کر رول اپ ٹرانزیکشن کے نتائج کو چیلنج کر سکتا ہے۔ + +اگر فراڈ پروف کامیاب ہو جاتا ہے، تو رول اپ پروٹوکول ٹرانزیکشن (ٹرانزیکشنز) کو دوبارہ انجام دیتا ہے اور اسی کے مطابق رول اپ کی اسٹیٹ کو اپ ڈیٹ کرتا ہے۔ کامیاب فراڈ پروف کا دوسرا اثر یہ ہے کہ غلط طریقے سے انجام دیے گئے ٹرانزیکشن کو بلاک میں شامل کرنے کے لیے ذمہ دار سیکوینسر کو جرمانہ ملتا ہے۔ + +اگر چیلنج کی مدت ختم ہونے کے بعد رول اپ بیچ غیر چیلنج شدہ رہتا ہے (یعنی، تمام ٹرانزیکشنز صحیح طریقے سے انجام پائے ہیں)، تو اسے Ethereum پر درست اور قبول شدہ سمجھا جاتا ہے۔ دوسرے غیر مصدقہ رول اپ بلاک پر تعمیر جاری رکھ سکتے ہیں، لیکن ایک انتباہ کے ساتھ: اگر پہلے شائع شدہ غلط طریقے سے انجام دیے گئے ٹرانزیکشن پر مبنی ہو تو ٹرانزیکشن کے نتائج الٹ دیے جائیں گے۔ + +## امید پسندانہ رول اپس Ethereum کے ساتھ کیسے تعامل کرتے ہیں؟ {#optimistic-rollups-and-Ethereum} + +امید پسندانہ رول اپس [offchain scaling solutions](/developers/docs/scaling/#offchain-scaling) ہیں جو Ethereum کے اوپر کام کرنے کے لیے بنائے گئے ہیں۔ ہر امید پسندانہ رول اپ کا انتظام Ethereum نیٹ ورک پر تعینات اسمارٹ کنٹریکٹس کے ایک سیٹ کے ذریعے کیا جاتا ہے۔ امید پسندانہ رول اپس مرکزی Ethereum چین سے باہر ٹرانزیکشنز پر کارروائی کرتے ہیں، لیکن آف چین ٹرانزیکشنز (بیچوں میں) کو آن چین رول اپ کنٹریکٹ میں پوسٹ کرتے ہیں۔ Ethereum بلاک چین کی طرح، یہ ٹرانزیکشن ریکارڈ ناقابل تغیر ہے اور "امید پسندانہ رول اپ چین" بناتا ہے۔ + +امید پسندانہ رول اپ کے فن تعمیر میں درج ذیل حصے شامل ہیں: + +**آن چین کنٹریکٹس**: امید پسندانہ رول اپ کا آپریشن Ethereum پر چلنے والے اسمارٹ کنٹریکٹس کے ذریعے کنٹرول کیا جاتا ہے۔ اس میں وہ کنٹریکٹس شامل ہیں جو رول اپ بلاکس کو اسٹور کرتے ہیں، رول اپ پر اسٹیٹ اپ ڈیٹس کی نگرانی کرتے ہیں، اور صارف کے ڈپازٹس کو ٹریک کرتے ہیں۔ اس لحاظ سے، Ethereum امید پسندانہ رول اپس کے لیے بیس لیئر یا "لیئر 1" کے طور پر کام کرتا ہے۔ + +**آف چین ورچوئل مشین (VM)**: اگرچہ امید پسندانہ رول اپ پروٹوکول کا انتظام کرنے والے کنٹریکٹس Ethereum پر چلتے ہیں، رول اپ پروٹوکول [Ethereum Virtual Machine](/developers/docs/evm/) سے الگ ایک اور ورچوئل مشین پر کمپیوٹیشن اور اسٹیٹ اسٹوریج انجام دیتا ہے۔ آف چین VM وہ جگہ ہے جہاں ایپلی کیشنز رہتی ہیں اور اسٹیٹ میں تبدیلیاں کی جاتی ہیں۔ یہ ایک امید پسندانہ رول اپ کے لیے اوپری لیئر یا "لیئر 2" کے طور پر کام کرتا ہے۔ + +چونکہ امید پسندانہ رول اپس EVM کے لیے لکھے گئے یا مرتب کیے گئے پروگراموں کو چلانے کے لیے بنائے گئے ہیں، آف چین VM میں بہت سے EVM ڈیزائن کی خصوصیات شامل ہیں۔ مزید برآں، آن چین کمپیوٹ کیے گئے فراڈ پروف Ethereum نیٹ ورک کو آف چین VM میں کمپیوٹ کی گئی اسٹیٹ تبدیلیوں کی موزونیت کو نافذ کرنے کی اجازت دیتے ہیں۔ + +امید پسندانہ رول اپس کو 'ہائبرڈ اسکیلنگ حل' کے طور پر بیان کیا گیا ہے کیونکہ، اگرچہ وہ الگ الگ پروٹوکول کے طور پر موجود ہیں، ان کی سیکیورٹی کی خصوصیات Ethereum سے حاصل کی گئی ہیں۔ دیگر چیزوں کے علاوہ، Ethereum رول اپ کے آف چین کمپیوٹیشن کی درستگی اور کمپیوٹیشن کے پیچھے ڈیٹا کی دستیابی کی ضمانت دیتا ہے۔ یہ امید پسندانہ رول اپس کو خالص آف چین اسکیلنگ پروٹوکولز (مثلاً، [sidechains](/developers/docs/scaling/sidechains/)) سے زیادہ محفوظ بناتا ہے جو سیکیورٹی کے لیے Ethereum پر انحصار نہیں کرتے ہیں۔ + +امید پسندانہ رول اپس درج ذیل کے لیے مرکزی Ethereum پروٹوکول پر انحصار کرتے ہیں: + +### ڈیٹا کی دستیابی {#data-availability} + +جیسا کہ ذکر کیا گیا ہے، امید پسندانہ رول اپس ٹرانزیکشن ڈیٹا کو `calldata` یا [blobs](/roadmap/danksharding/) کے طور پر Ethereum پر پوسٹ کرتے ہیں۔ چونکہ رول اپ چین کا عمل درآمد جمع کردہ ٹرانزیکشنز پر مبنی ہے، کوئی بھی اس معلومات کا استعمال کر سکتا ہے — جو Ethereum کی بیس لیئر پر لنگر انداز ہے — رول اپ کی اسٹیٹ کو انجام دینے اور اسٹیٹ کی منتقلی کی درستگی کی تصدیق کرنے کے لیے۔ + +[ڈیٹا کی دستیابی](/developers/docs/data-availability/) اہم ہے کیونکہ اسٹیٹ ڈیٹا تک رسائی کے بغیر، چیلنجرز غلط رول اپ آپریشنز پر تنازعہ کرنے کے لیے فراڈ پروف نہیں بنا سکتے۔ Ethereum کے ڈیٹا کی دستیابی فراہم کرنے کے ساتھ، رول اپ آپریٹرز کے بدنیتی پر مبنی کاموں (مثلاً، غلط بلاکس جمع کرنا) سے بچنے کا خطرہ کم ہو جاتا ہے۔ + +### سنسرشپ مزاحمت {#censorship-resistance} + +امید پسندانہ رول اپس سنسرشپ مزاحمت کے لیے Ethereum پر بھی انحصار کرتے ہیں۔ ایک امید پسندانہ رول اپ میں ایک مرکزی ادارہ (آپریٹر) ٹرانزیکشنز پر کارروائی کرنے اور Ethereum میں رول اپ بلاکس جمع کرنے کا ذمہ دار ہے۔ اس کے کچھ مضمرات ہیں: + +- رول اپ آپریٹرز مکمل طور پر آف لائن جا کر، یا ایسے بلاکس تیار کرنے سے انکار کر کے صارفین کو سنسر کر سکتے ہیں جن میں کچھ ٹرانزیکشنز شامل ہوں۔ + +- رول اپ آپریٹرز ملکیت کے Merkle پروف کے لیے ضروری اسٹیٹ ڈیٹا کو روک کر صارفین کو رول اپ کنٹریکٹ میں جمع کردہ فنڈز نکالنے سے روک سکتے ہیں۔ اسٹیٹ ڈیٹا کو روکنا صارفین سے رول اپ کی اسٹیٹ کو بھی چھپا سکتا ہے اور انہیں رول اپ کے ساتھ تعامل کرنے سے روک سکتا ہے۔ + +امید پسندانہ رول اپس آپریٹرز کو Ethereum پر اسٹیٹ اپ ڈیٹس سے وابستہ ڈیٹا شائع کرنے پر مجبور کر کے اس مسئلے کو حل کرتے ہیں۔ رول اپ ڈیٹا کو آن چین شائع کرنے کے درج ذیل فوائد ہیں: + +- اگر کوئی امید پسندانہ رول اپ آپریٹر آف لائن ہو جاتا ہے یا ٹرانزیکشن بیچ بنانا بند کر دیتا ہے، تو دوسرا نوڈ دستیاب ڈیٹا کا استعمال کر کے رول اپ کی آخری اسٹیٹ کو دوبارہ تیار کر سکتا ہے اور بلاک کی پیداوار جاری رکھ سکتا ہے۔ + +- صارفین فنڈز کی ملکیت ثابت کرنے والے Merkle پروف بنانے اور رول اپ سے اپنے اثاثے نکالنے کے لیے ٹرانزیکشن ڈیٹا کا استعمال کر سکتے ہیں۔ + +- صارفین سیکوینسر کے بجائے L1 پر بھی اپنے ٹرانزیکشنز جمع کرا سکتے ہیں، ایسی صورت میں سیکوینسر کو درست بلاکس کی تیاری جاری رکھنے کے لیے ایک مخصوص وقت کی حد کے اندر ٹرانزیکشن کو شامل کرنا ہوگا۔ + +### سیٹلمنٹ {#settlement} + +امید پسندانہ رول اپس کے تناظر میں Ethereum کا ایک اور کردار سیٹلمنٹ لیئر کا ہے۔ ایک سیٹلمنٹ لیئر پورے بلاک چین ایکو سسٹم کو لنگر انداز کرتی ہے، سیکیورٹی قائم کرتی ہے، اور اگر کسی دوسری چین (اس معاملے میں امید پسندانہ رول اپس) پر کوئی تنازعہ ہوتا ہے جس کے لیے ثالثی کی ضرورت ہوتی ہے تو معروضی حتمیت فراہم کرتی ہے۔ + +Ethereum Mainnet امید پسندانہ رول اپس کو فراڈ پروف کی تصدیق کرنے اور تنازعات کو حل کرنے کے لیے ایک مرکز فراہم کرتا ہے۔ مزید یہ کہ، رول اپ پر کیے گئے ٹرانزیکشنز صرف _اس کے بعد_ حتمی ہوتے ہیں جب رول اپ بلاک Ethereum پر قبول ہو جاتا ہے۔ ایک بار جب کوئی رول اپ ٹرانزیکشن Ethereum کی بیس لیئر کے لیے پرعزم ہو جاتا ہے، تو اسے واپس نہیں کیا جا سکتا (سوائے چین کی تنظیم نو کے انتہائی غیر متوقع معاملے کے)۔ + +## امید پسندانہ رول اپس کیسے کام کرتے ہیں؟ {#how-optimistic-rollups-work} + +### ٹرانزیکشن کا نفاذ اور جمع کرنا {#transaction-execution-and-aggregation} + +صارفین ”آپریٹرز“ کو ٹرانزیکشنز جمع کراتے ہیں، جو امید پسندانہ رول اپ پر ٹرانزیکشنز پر کارروائی کے ذمہ دار نوڈز ہیں۔ ”ویلیڈیٹر“ یا ”ایگریگیٹر“ کے نام سے بھی جانا جاتا ہے، آپریٹر ٹرانزیکشنز کو جمع کرتا ہے، بنیادی ڈیٹا کو کمپریس کرتا ہے، اور بلاک کو Ethereum پر شائع کرتا ہے۔ + +اگرچہ کوئی بھی ویلیڈیٹر بن سکتا ہے، لیکن امید پسندانہ رول اپ ویلیڈیٹرز کو بلاکس تیار کرنے سے پہلے ایک بانڈ فراہم کرنا چاہیے، بالکل اسی طرح جیسے [proof-of-stake system](/developers/docs/consensus-mechanisms/pos/)۔ اگر ویلیڈیٹر کوئی غلط بلاک پوسٹ کرتا ہے یا پرانے لیکن غلط بلاک پر بناتا ہے تو اس بانڈ کو سلیش کیا جاسکتا ہے (چاہے ان کا بلاک درست ہی کیوں نہ ہو)۔ اس طرح امید پسندانہ رول اپس اس بات کو یقینی بنانے کے لیے کرپٹو اکنامک ترغیبات کا استعمال کرتے ہیں کہ ویلیڈیٹرز ایمانداری سے کام کریں۔ + +امید پسندانہ رول اپ چین پر موجود دیگر ویلیڈیٹرز سے توقع کی جاتی ہے کہ وہ رول اپ کی اسٹیٹ کی اپنی کاپی کا استعمال کرتے ہوئے جمع کرائے گئے ٹرانزیکشنز کو انجام دیں گے۔ اگر کسی ویلیڈیٹر کی حتمی اسٹیٹ آپریٹر کی مجوزہ اسٹیٹ سے مختلف ہے، تو وہ ایک چیلنج شروع کر سکتے ہیں اور فراڈ پروف کا حساب لگا سکتے ہیں۔ + +کچھ امید پسندانہ رول اپس اجازت کے بغیر ویلیڈیٹر سسٹم کو ترک کر سکتے ہیں اور چین کو انجام دینے کے لیے ایک ہی ”سیکوینسر“ استعمال کر سکتے ہیں۔ ویلیڈیٹر کی طرح، سیکوینسر ٹرانزیکشنز پر کارروائی کرتا ہے، رول اپ بلاکس تیار کرتا ہے، اور L1 چین (Ethereum) میں رول اپ ٹرانزیکشنز جمع کرتا ہے۔ + +سیکوینسر ایک باقاعدہ رول اپ آپریٹر سے مختلف ہے کیونکہ اس کا ٹرانزیکشنز کی ترتیب پر زیادہ کنٹرول ہوتا ہے۔ اس کے علاوہ، سیکوینسر کو رول اپ چین تک ترجیحی رسائی حاصل ہے اور وہ آن چین کنٹریکٹ میں ٹرانزیکشنز جمع کرانے کا واحد مجاز ادارہ ہے۔ نان سیکوینسر نوڈس یا باقاعدہ صارفین کے ٹرانزیکشنز کو صرف ایک الگ ان باکس میں قطار میں رکھا جاتا ہے جب تک کہ سیکوینسر انہیں ایک نئے بیچ میں شامل نہ کر لے۔ + +#### Ethereum میں رول اپ بلاکس جمع کرنا {#submitting-blocks-to-ethereum} + +جیسا کہ ذکر کیا گیا ہے، ایک امید پسندانہ رول اپ کا آپریٹر آف چین ٹرانزیکشنز کو ایک بیچ میں بنڈل کرتا ہے اور اسے نوٹرائزیشن کے لیے Ethereum کو بھیجتا ہے۔ اس عمل میں ٹرانزیکشن سے متعلقہ ڈیٹا کو کمپریس کرنا اور اسے Ethereum پر `calldata` یا بلابز میں شائع کرنا شامل ہے۔ + +`calldata` ایک اسمارٹ کنٹریکٹ میں ایک غیر قابل ترمیم، غیر مستقل علاقہ ہے جو زیادہ تر [میموری](/developers/docs/smart-contracts/anatomy/#memory) کی طرح برتاؤ کرتا ہے۔ اگرچہ `calldata` بلاک چین کے [ہسٹری لاگز](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) کے حصے کے طور پر آن چین برقرار رہتا ہے، لیکن اسے Ethereum کی اسٹیٹ کے حصے کے طور پر اسٹور نہیں کیا جاتا ہے۔ چونکہ `calldata` Ethereum کی اسٹیٹ کے کسی بھی حصے کو نہیں چھوتا، یہ آن چین ڈیٹا اسٹور کرنے کے لیے اسٹیٹ سے سستا ہے۔ + +`calldata` کلیدی لفظ Solidity میں بھی استعمال ہوتا ہے تاکہ عمل درآمد کے وقت اسمارٹ کنٹریکٹ فنکشن میں دلائل منتقل کیے جاسکیں۔ `calldata` ٹرانزیکشن کے دوران کال کیے جانے والے فنکشن کی نشاندہی کرتا ہے اور بائٹس کی ایک صوابدیدی ترتیب کی شکل میں فنکشن کے لیے ان پٹ رکھتا ہے۔ + +امید پسندانہ رول اپس کے تناظر میں، `calldata` کا استعمال کمپریسڈ ٹرانزیکشن ڈیٹا کو آن چین کنٹریکٹ میں بھیجنے کے لیے کیا جاتا ہے۔ رول اپ آپریٹر رول اپ کنٹریکٹ میں مطلوبہ فنکشن کو کال کرکے اور کمپریسڈ ڈیٹا کو فنکشن دلائل کے طور پر پاس کرکے ایک نیا بیچ شامل کرتا ہے۔ `calldata` کا استعمال صارف کی فیس کو کم کرتا ہے کیونکہ رول اپس کے زیادہ تر اخراجات آن چین ڈیٹا اسٹور کرنے سے آتے ہیں۔ + +یہاں [ایک مثال](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) ہے کہ یہ تصور کیسے کام کرتا ہے یہ دکھانے کے لیے ایک رول اپ بیچ جمع کرنے کا۔ سیکوینسر نے `appendSequencerBatch()` طریقہ کو طلب کیا اور کمپریسڈ ٹرانزیکشن ڈیٹا کو `calldata` کا استعمال کرتے ہوئے ان پٹ کے طور پر پاس کیا۔ + +کچھ رول اپس اب Ethereum میں ٹرانزیکشنز کے بیچ پوسٹ کرنے کے لیے بلابز کا استعمال کرتے ہیں۔ + +بلابز غیر قابل ترمیم اور غیر مستقل ہیں (بالکل `calldata` کی طرح) لیکن ~18 دنوں کے بعد تاریخ سے کاٹ دیے جاتے ہیں۔ بلابز کے بارے میں مزید معلومات کے لیے، [Danksharding](/roadmap/danksharding) دیکھیں۔ + +### اسٹیٹ کمٹمنٹس {#state-commitments} + +کسی بھی وقت، امید پسندانہ رول اپ کی اسٹیٹ (اکاؤنٹس، بیلنس، کنٹریکٹ کوڈ، وغیرہ) ایک [Merkle tree](/whitepaper/#merkle-trees) کے طور پر منظم ہے جسے ”اسٹیٹ ٹری“ کہا جاتا ہے۔ اس Merkle tree کی جڑ (اسٹیٹ روٹ)، جو رول اپ کی تازہ ترین اسٹیٹ کا حوالہ دیتی ہے، کو ہیش کیا جاتا ہے اور رول اپ کنٹریکٹ میں اسٹور کیا جاتا ہے۔ چین پر ہر اسٹیٹ کی منتقلی ایک نئی رول اپ اسٹیٹ پیدا کرتی ہے، جسے ایک آپریٹر ایک نئی اسٹیٹ روٹ کا حساب لگا کر انجام دیتا ہے۔ + +بیچ پوسٹ کرتے وقت آپریٹر کو پرانی اسٹیٹ روٹس اور نئی اسٹیٹ روٹس دونوں جمع کرانے کی ضرورت ہوتی ہے۔ اگر پرانی اسٹیٹ روٹ آن چین کنٹریکٹ میں موجودہ اسٹیٹ روٹ سے میل کھاتی ہے، تو بعد والے کو مسترد کر دیا جاتا ہے اور نئی اسٹیٹ روٹ سے بدل دیا جاتا ہے۔ + +رول اپ آپریٹر کو خود ٹرانزیکشن بیچ کے لیے Merkle روٹ بھی دینا ہوتا ہے۔ یہ کسی کو بھی ایک [Merkle proof](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) پیش کرکے بیچ میں (L1 پر) ٹرانزیکشن کی شمولیت کو ثابت کرنے کی اجازت دیتا ہے۔ + +اسٹیٹ کے وعدے، خاص طور پر اسٹیٹ روٹس، ایک امید پسندانہ رول اپ میں اسٹیٹ تبدیلیوں کی درستگی کو ثابت کرنے کے لیے ضروری ہیں۔ رول اپ کنٹریکٹ آپریٹرز سے نئی اسٹیٹ روٹس کو پوسٹ کیے جانے کے فوراً بعد قبول کر لیتا ہے، لیکن بعد میں رول اپ کو اس کی درست اسٹیٹ پر بحال کرنے کے لیے غلط اسٹیٹ روٹس کو حذف کر سکتا ہے۔ + +### فراڈ ثابت کرنا {#fraud-proving} + +جیسا کہ وضاحت کی گئی ہے، امید پسندانہ رول اپس کسی کو بھی موزونیت کے ثبوت فراہم کیے بغیر بلاکس شائع کرنے کی اجازت دیتے ہیں۔ تاہم، یہ یقینی بنانے کے لیے کہ چین محفوظ رہے، امید پسندانہ رول اپس ایک ٹائم ونڈو کی وضاحت کرتے ہیں جس کے دوران کوئی بھی اسٹیٹ کی منتقلی پر تنازعہ کر سکتا ہے۔ اس لیے، رول اپ بلاکس کو ”دعویٰ“ کہا جاتا ہے کیونکہ کوئی بھی ان کی موزونیت پر تنازعہ کر سکتا ہے۔ + +اگر کوئی دعویٰ پر تنازعہ کرتا ہے، تو رول اپ پروٹوکول فراڈ پروف کمپیوٹیشن شروع کرے گا۔ ہر قسم کا فراڈ پروف انٹرایکٹو ہوتا ہے— کسی کو دعویٰ پوسٹ کرنا چاہیے اس سے پہلے کہ کوئی دوسرا اسے چیلنج کر سکے۔ فرق اس بات میں ہے کہ فراڈ پروف کا حساب لگانے کے لیے کتنے راؤنڈز کے تعامل کی ضرورت ہے۔ + +سنگل راؤنڈ انٹرایکٹو پروفنگ اسکیمیں غلط دعووں کا پتہ لگانے کے لیے L1 پر متنازعہ ٹرانزیکشنز کو دوبارہ چلاتی ہیں۔ رول اپ پروٹوکول ایک تصدیق کنندہ کنٹریکٹ کا استعمال کرتے ہوئے L1 (Ethereum) پر متنازعہ ٹرانزیکشن کے دوبارہ نفاذ کی تقلید کرتا ہے، جس میں کمپیوٹ کی گئی اسٹیٹ روٹ یہ طے کرتی ہے کہ چیلنج کون جیتتا ہے۔ اگر چیلنجر کا رول اپ کی درست اسٹیٹ کے بارے میں دعویٰ درست ہے، تو آپریٹر کو اس کے بانڈ کو سلیش کر کے جرمانہ کیا جاتا ہے۔ + +تاہم، فراڈ کا پتہ لگانے کے لیے L1 پر ٹرانزیکشنز کو دوبارہ انجام دینے کے لیے انفرادی ٹرانزیکشنز کے لیے اسٹیٹ کے وعدوں کو شائع کرنے کی ضرورت ہوتی ہے اور اس ڈیٹا میں اضافہ ہوتا ہے جسے رول اپس کو آن چین شائع کرنا چاہیے۔ ٹرانزیکشنز کو دوبارہ چلانے میں بھی گیس کے اہم اخراجات آتے ہیں۔ ان وجوہات کی بنا پر، امید پسندانہ رول اپس ملٹی راؤنڈ انٹرایکٹو پروفنگ کی طرف منتقل ہو رہے ہیں، جو زیادہ کارکردگی کے ساتھ اسی مقصد (یعنی، غلط رول اپ آپریشنز کا پتہ لگانا) کو حاصل کرتا ہے۔ + +#### ملٹی راؤنڈ انٹرایکٹو پروفنگ {#multi-round-interactive-proving} + +ملٹی راؤنڈ انٹرایکٹو پروفنگ میں دعویدار اور چیلنجر کے درمیان ایک آگے پیچھے کا پروٹوکول شامل ہوتا ہے جس کی نگرانی L1 تصدیق کنندہ کنٹریکٹ کرتا ہے، جو بالآخر جھوٹی پارٹی کا فیصلہ کرتا ہے۔ L2 نوڈ کے دعویٰ کو چیلنج کرنے کے بعد، دعویدار کو متنازعہ دعویٰ کو دو برابر حصوں میں تقسیم کرنے کی ضرورت ہوتی ہے۔ اس معاملے میں ہر انفرادی دعویٰ میں اتنے ہی کمپیوٹیشن کے مراحل ہوں گے جتنے دوسرے میں۔ + +چیلنجر پھر انتخاب کرے گا کہ وہ کس دعوے کو چیلنج کرنا چاہتا ہے۔ تقسیم کا عمل (جسے ”بائیسیکشن پروٹوکول“ کہا جاتا ہے) اس وقت تک جاری رہتا ہے جب تک کہ دونوں فریقین عمل درآمد کے _ایک_ مرحلے کے بارے میں دعوے پر تنازعہ نہ کر رہے ہوں۔ اس موقع پر، L1 کنٹریکٹ دھوکہ دہی والی پارٹی کو پکڑنے کے لیے ہدایت (اور اس کے نتیجے) کا جائزہ لے کر تنازعہ کو حل کرے گا۔ + +دعویدار کو متنازعہ سنگل اسٹیپ کمپیوٹیشن کی موزونیت کی تصدیق کرنے والا ”ایک قدمی ثبوت“ فراہم کرنے کی ضرورت ہے۔ اگر دعویدار ایک قدمی ثبوت فراہم کرنے میں ناکام رہتا ہے، یا L1 تصدیق کنندہ ثبوت کو غلط سمجھتا ہے، تو وہ چیلنج ہار جاتے ہیں۔ + +اس قسم کے فراڈ پروف کے بارے میں کچھ نوٹس: + +1. ملٹی راؤنڈ انٹرایکٹو فراڈ پروفنگ کو موثر سمجھا جاتا ہے کیونکہ یہ اس کام کو کم کرتا ہے جو L1 چین کو تنازعہ ثالثی میں کرنا چاہیے۔ پورے ٹرانزیکشن کو دوبارہ چلانے کے بجائے، L1 چین کو صرف رول اپ کے عمل درآمد میں ایک قدم کو دوبارہ انجام دینے کی ضرورت ہے۔ + +2. بائیسیکشن پروٹوکول آن چین پوسٹ کیے گئے ڈیٹا کی مقدار کو کم کرتے ہیں (ہر ٹرانزیکشن کے لیے اسٹیٹ کمٹ شائع کرنے کی ضرورت نہیں)۔ اس کے علاوہ، امید پسندانہ رول اپ ٹرانزیکشنز Ethereum کی گیس کی حد سے محدود نہیں ہیں۔ اس کے برعکس، امید پسندانہ رول اپس ٹرانزیکشنز کو دوبارہ انجام دینے کے لیے یہ یقینی بنانا چاہیے کہ L2 ٹرانزیکشن میں ایک ہی Ethereum ٹرانزیکشن کے اندر اس کے عمل درآمد کی تقلید کے لیے کم گیس کی حد ہے۔ + +3. بدنیتی پر مبنی دعویدار کے بانڈ کا کچھ حصہ چیلنجر کو دیا جاتا ہے، جبکہ دوسرا حصہ جلا دیا جاتا ہے۔ جلنا ویلیڈیٹرز کے درمیان ملی بھگت کو روکتا ہے؛ اگر دو ویلیڈیٹرز بوگس چیلنجز شروع کرنے کے لیے ملی بھگت کرتے ہیں، تو وہ پھر بھی پورے اسٹیک کا ایک بڑا حصہ ضبط کر لیں گے۔ + +4. ملٹی راؤنڈ انٹرایکٹو پروفنگ کے لیے دونوں فریقین (دعویدار اور چیلنجر) کو مقررہ وقت کی کھڑکی کے اندر حرکت کرنے کی ضرورت ہوتی ہے۔ آخری تاریخ سے پہلے کارروائی کرنے میں ناکامی سے ڈیفالٹ کرنے والی پارٹی چیلنج ہار جاتی ہے۔ + +#### امید پسندانہ رول اپس کے لیے فراڈ پروف کیوں اہم ہیں {#fraud-proof-benefits} + +فراڈ پروف اہم ہیں کیونکہ وہ امید پسندانہ رول اپس میں _ٹرسٹ لیس فائنلٹی_ کی سہولت فراہم کرتے ہیں۔ ٹرسٹ لیس فائنلٹی امید پسندانہ رول اپس کا ایک معیار ہے جو اس بات کی ضمانت دیتا ہے کہ ایک ٹرانزیکشن— جب تک کہ یہ درست ہے— بالآخر تصدیق ہو جائے گا۔ + +بدنیتی پر مبنی نوڈس جھوٹے چیلنجز شروع کرکے ایک درست رول اپ بلاک کی تصدیق میں تاخیر کرنے کی کوشش کر سکتے ہیں۔ تاہم، فراڈ پروف بالآخر رول اپ بلاک کی موزونیت کو ثابت کریں گے اور اس کی تصدیق کا سبب بنیں گے۔ + +اس کا تعلق امید پسندانہ رول اپس کی ایک اور سیکیورٹی پراپرٹی سے بھی ہے: چین کی موزونیت _ایک_ ایماندار نوڈ کے وجود پر منحصر ہے۔ ایماندار نوڈ درست دعوے پوسٹ کرکے یا غلط دعووں پر تنازعہ کرکے چین کو صحیح طریقے سے آگے بڑھا سکتا ہے۔ جو بھی معاملہ ہو، بدنیتی پر مبنی نوڈس جو ایماندار نوڈ کے ساتھ تنازعات میں داخل ہوتے ہیں، وہ فراڈ پروفنگ کے عمل کے دوران اپنے اسٹیک کھو دیں گے۔ + +### L1/L2 انٹرآپریبلٹی {#l1-l2-interoperability} + +امید پسندانہ رول اپس Ethereum Mainnet کے ساتھ انٹرآپریبلٹی کے لیے ڈیزائن کیے گئے ہیں اور صارفین کو L1 اور L2 کے درمیان پیغامات اور صوابدیدی ڈیٹا منتقل کرنے کی اجازت دیتے ہیں۔ وہ EVM کے ساتھ بھی مطابقت رکھتے ہیں، لہذا آپ موجودہ [dapps](/developers/docs/dapps/) کو امید پسندانہ رول اپس میں پورٹ کرسکتے ہیں یا Ethereum ڈیولپمنٹ ٹولز کا استعمال کرکے نئے dapps بناسکتے ہیں۔ + +#### 1۔ اثاثوں کی نقل و حرکت {#asset-movement} + +##### رول اپ میں داخل ہونا + +امید پسندانہ رول اپ استعمال کرنے کے لیے، صارفین ETH, ERC-20 ٹوکنز، اور دیگر قبول شدہ اثاثے L1 پر رول اپ کے [برج](/developers/docs/bridges/) کنٹریکٹ میں جمع کرتے ہیں۔ برج کنٹریکٹ ٹرانزیکشن کو L2 پر ریلے کرے گا، جہاں اثاثوں کی مساوی رقم منٹ کی جائے گی اور امید پسندانہ رول اپ پر صارف کے منتخب کردہ پتے پر بھیجی جائے گی۔ + +صارف کے ذریعہ تیار کردہ ٹرانزیکشنز (جیسے L1 > L2 ڈپازٹ) عام طور پر اس وقت تک قطار میں رہتی ہیں جب تک کہ سیکوینسر انہیں رول اپ کنٹریکٹ میں دوبارہ جمع نہیں کرتا۔ تاہم، سنسرشپ مزاحمت کو برقرار رکھنے کے لیے، امید پسندانہ رول اپس صارفین کو براہ راست آن چین رول اپ کنٹریکٹ میں ٹرانزیکشن جمع کرانے کی اجازت دیتے ہیں اگر اس میں زیادہ سے زیادہ اجازت یافتہ وقت سے زیادہ تاخیر ہوئی ہو۔ + +کچھ امید پسندانہ رول اپس سیکوینسرز کو صارفین کو سنسر کرنے سے روکنے کے لیے ایک زیادہ سیدھا سادا طریقہ اپناتے ہیں۔ یہاں، ایک بلاک کی تعریف پچھلے بلاک (مثلاً، ڈپازٹس) کے بعد سے L1 کنٹریکٹ میں جمع کرائے گئے تمام ٹرانزیکشنز کے علاوہ رول اپ چین پر کارروائی کیے گئے ٹرانزیکشنز کے ذریعے کی جاتی ہے۔ اگر کوئی سیکوینسر L1 ٹرانزیکشن کو نظر انداز کرتا ہے، تو وہ (ثابت شدہ) غلط اسٹیٹ روٹ شائع کرے گا؛ لہذا، سیکوینسرز L1 پر پوسٹ ہونے کے بعد صارف کے ذریعہ تیار کردہ پیغامات میں تاخیر نہیں کر سکتے ہیں۔ + +##### رول اپ سے باہر نکلنا + +فراڈ پروفنگ اسکیم کی وجہ سے امید پسندانہ رول اپ سے Ethereum میں واپس نکلنا زیادہ مشکل ہے۔ اگر کوئی صارف L1 پر ایسکرو شدہ فنڈز نکالنے کے لیے L2 > L1 ٹرانزیکشن شروع کرتا ہے، تو اسے چیلنج کی مدت— تقریباً سات دن تک— ختم ہونے تک انتظار کرنا ہوگا۔ بہر حال، واپسی کا عمل خود کافی سیدھا ہے۔ + +L2 رول اپ پر واپسی کی درخواست شروع ہونے کے بعد، ٹرانزیکشن کو اگلے بیچ میں شامل کیا جاتا ہے، جبکہ رول اپ پر صارف کے اثاثے جلا دیے جاتے ہیں۔ ایک بار جب بیچ Ethereum پر شائع ہو جاتا ہے، تو صارف بلاک میں اپنی خارجی ٹرانزیکشن کی شمولیت کی تصدیق کرنے والے Merkle پروف کا حساب لگا سکتا ہے۔ پھر L1 پر ٹرانزیکشن کو حتمی شکل دینے اور Mainnet میں فنڈز نکالنے کے لیے تاخیر کی مدت کا انتظار کرنا پڑتا ہے۔ + +Ethereum میں فنڈز نکالنے سے پہلے ایک ہفتہ انتظار کرنے سے بچنے کے لیے، امید پسندانہ رول اپ صارفین **لیکویڈیٹی پرووائیڈر** (LP) کا استعمال کر سکتے ہیں۔ ایک لیکویڈیٹی پرووائیڈر زیر التواء L2 واپسی کی ملکیت سنبھالتا ہے اور صارف کو L1 پر (فیس کے بدلے) ادائیگی کرتا ہے۔ + +لیکویڈیٹی پرووائیڈرز فنڈز جاری کرنے سے پہلے صارف کی واپسی کی درخواست کی موزونیت کی جانچ کر سکتے ہیں (خود چین کو انجام دے کر)۔ اس طرح انہیں یقین دہانی ہوتی ہے کہ ٹرانزیکشن بالآخر تصدیق ہو جائے گا (یعنی، ٹرسٹ لیس فائنلٹی)۔ + +#### 2۔ EVM مطابقت {#evm-compatibility} + +ڈویلپرز کے لیے، امید پسندانہ رول اپس کا فائدہ [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) کے ساتھ ان کی مطابقت—یا، اس سے بھی بہتر، مساوات— ہے۔ EVM-مطابق رول اپس [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) میں دی گئی خصوصیات کی تعمیل کرتے ہیں اور بائٹ کوڈ کی سطح پر EVM کو سپورٹ کرتے ہیں۔ + +امید پسندانہ رول اپس میں EVM-مطابقت کے درج ذیل فوائد ہیں: + +i. ڈویلپرز Ethereum پر موجودہ اسمارٹ کنٹریکٹس کو کوڈ بیسز میں بڑے پیمانے پر ترمیم کیے بغیر امید پسندانہ رول اپ چینز میں منتقل کر سکتے ہیں۔ یہ L2 پر Ethereum اسمارٹ کنٹریکٹس کو تعینات کرتے وقت ڈیولپمنٹ ٹیموں کا وقت بچا سکتا ہے۔ + +ii. امید پسندانہ رول اپس کا استعمال کرنے والے ڈویلپرز اور پروجیکٹ ٹیمیں Ethereum کے بنیادی ڈھانچے سے فائدہ اٹھا سکتی ہیں۔ اس میں پروگرامنگ زبانیں، کوڈ لائبریریاں، ٹیسٹنگ ٹولز، کلائنٹ سافٹ ویئر، تعیناتی کا بنیادی ڈھانچہ وغیرہ شامل ہیں۔ + +موجودہ ٹولنگ کا استعمال اہم ہے کیونکہ ان ٹولز کا برسوں سے وسیع پیمانے پر آڈٹ، ڈیبگ اور بہتر کیا گیا ہے۔ یہ Ethereum ڈویلپرز کے لیے ایک بالکل نئے ڈیولپمنٹ اسٹیک کے ساتھ تعمیر کرنے کا طریقہ سیکھنے کی ضرورت کو بھی دور کرتا ہے۔ + +#### 3۔ کراس چین کنٹریکٹ کالز {#cross-chain-contract-calls} + +صارفین (بیرونی طور پر ملکیت والے اکاؤنٹس) L2 کنٹریکٹس کے ساتھ رول اپ کنٹریکٹ میں ٹرانزیکشن جمع کر کے یا سیکوینسر یا ویلیڈیٹر سے کروا کر تعامل کرتے ہیں۔ امید پسندانہ رول اپس Ethereum پر کنٹریکٹ اکاؤنٹس کو L1 اور L2 کے درمیان پیغامات کو ریلے کرنے اور ڈیٹا منتقل کرنے کے لیے برجنگ کنٹریکٹس کا استعمال کرتے ہوئے L2 کنٹریکٹس کے ساتھ تعامل کرنے کی بھی اجازت دیتے ہیں۔ اس کا مطلب ہے کہ آپ Ethereum Mainnet پر ایک L1 کنٹریکٹ کو پروگرام کر سکتے ہیں تاکہ L2 امید پسندانہ رول اپ پر کنٹریکٹس سے تعلق رکھنے والے فنکشنز کو طلب کیا جا سکے۔ + +کراس چین کنٹریکٹ کالز غیر مطابقت پذیر طور پر ہوتی ہیں— یعنی کال پہلے شروع کی جاتی ہے، پھر بعد میں عمل میں لائی جاتی ہے۔ یہ Ethereum پر دو کنٹریکٹس کے درمیان کالز سے مختلف ہے، جہاں کال فوری طور پر نتائج پیدا کرتی ہے۔ + +کراس چین کنٹریکٹ کال کی ایک مثال پہلے بیان کردہ ٹوکن ڈپازٹ ہے۔ L1 پر ایک کنٹریکٹ صارف کے ٹوکنز کو ایسکرو کرتا ہے اور ایک جوڑے والے L2 کنٹریکٹ کو ایک پیغام بھیجتا ہے تاکہ رول اپ پر ٹوکنز کی مساوی رقم منٹ کی جا سکے۔ + +چونکہ کراس چین میسج کالز کے نتیجے میں کنٹریکٹ پر عمل درآمد ہوتا ہے، بھیجنے والے کو عام طور پر کمپیوٹیشن کے لیے [گیس کے اخراجات](/developers/docs/gas/) کو پورا کرنے کی ضرورت ہوتی ہے۔ ٹرانزیکشن کو ٹارگٹ چین پر ناکام ہونے سے بچانے کے لیے ایک اعلیٰ گیس کی حد مقرر کرنے کا مشورہ دیا جاتا ہے۔ ٹوکن برجنگ کا منظرنامہ ایک اچھی مثال ہے؛ اگر ٹرانزیکشن کا L1 حصہ (ٹوکنز جمع کرنا) کام کرتا ہے، لیکن L2 حصہ (نئے ٹوکنز منٹ کرنا) کم گیس کی وجہ سے ناکام ہو جاتا ہے، تو ڈپازٹ ناقابل وصول ہو جاتا ہے۔ + +آخر میں، ہمیں یہ نوٹ کرنا چاہیے کہ کنٹریکٹس کے درمیان L2 > L1 میسج کالز کو تاخیر کا حساب دینا ہوگا (L1 > L2 کالز عام طور پر کچھ منٹ بعد عمل میں لائی جاتی ہیں)۔ اس کی وجہ یہ ہے کہ امید پسندانہ رول اپ سے Mainnet کو بھیجے گئے پیغامات اس وقت تک عمل میں نہیں لائے جا سکتے جب تک کہ چیلنج ونڈو کی میعاد ختم نہ ہو جائے۔ + +## امید پسندانہ رول اپ فیس کیسے کام کرتی ہے؟ {#how-do-optimistic-rollup-fees-work} + +امید پسندانہ رول اپس ایک گیس فیس اسکیم کا استعمال کرتے ہیں، بالکل Ethereum کی طرح، یہ ظاہر کرنے کے لیے کہ صارفین فی ٹرانزیکشن کتنا ادائیگی کرتے ہیں۔ امید پسندانہ رول اپس پر وصول کی جانے والی فیس درج ذیل اجزاء پر منحصر ہے: + +1. **اسٹیٹ رائٹ**: امید پسندانہ رول اپس ٹرانزیکشن ڈیٹا اور بلاک ہیڈرز (پچھلے بلاک ہیڈر ہیش، اسٹیٹ روٹ، بیچ روٹ پر مشتمل) کو Ethereum پر ایک `blob`، یا "بائنری لارج آبجیکٹ" کے طور پر شائع کرتے ہیں۔ [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) نے آن چین ڈیٹا شامل کرنے کے لیے ایک سستا حل متعارف کرایا۔ ایک `blob` ایک نیا ٹرانزیکشن فیلڈ ہے جو رول اپس کو کمپریسڈ اسٹیٹ ٹرانزیشن ڈیٹا کو Ethereum L1 پر پوسٹ کرنے کی اجازت دیتا ہے۔ `calldata` کے برعکس، جو مستقل طور پر آن چین رہتا ہے، بلابز قلیل مدتی ہوتے ہیں اور [4096 epochs](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (تقریباً 18 دن) کے بعد کلائنٹس سے کاٹے جا سکتے ہیں۔ کمپریسڈ ٹرانزیکشنز کے بیچ پوسٹ کرنے کے لیے بلابز کا استعمال کرکے، امید پسندانہ رول اپس L1 پر ٹرانزیکشنز لکھنے کی لاگت کو نمایاں طور پر کم کرسکتے ہیں۔ + +2. **استعمال شدہ بلاب گیس**: بلاب لے جانے والے ٹرانزیکشنز [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) کے ذریعہ متعارف کرائے گئے ایک متحرک فیس میکانزم کا استعمال کرتے ہیں۔ ٹائپ-3 ٹرانزیکشنز کے لیے گیس فیس بلابز کے لیے بیس فیس کو مدنظر رکھتی ہے، جس کا تعین نیٹ ورک بلاب-اسپیس کی طلب اور بھیجے جانے والے ٹرانزیکشن کے بلاب-اسپیس کے استعمال کی بنیاد پر کرتا ہے۔ + +3. **L2 آپریٹر فیس**: یہ وہ رقم ہے جو رول اپ نوڈس کو ٹرانزیکشنز پر کارروائی میں ہونے والے کمپیوٹیشنل اخراجات کے معاوضے کے طور پر ادا کی جاتی ہے، بالکل Ethereum پر گیس فیس کی طرح۔ رول اپ نوڈس کم ٹرانزیکشن فیس وصول کرتے ہیں کیونکہ L2s میں زیادہ پروسیسنگ کی صلاحیت ہوتی ہے اور انہیں نیٹ ورک کی بھیڑ کا سامنا نہیں کرنا پڑتا ہے جو Ethereum پر ویلیڈیٹرز کو زیادہ فیس والے ٹرانزیکشنز کو ترجیح دینے پر مجبور کرتی ہے۔ + +امید پسندانہ رول اپس صارفین کے لیے فیس کم کرنے کے لیے کئی میکانزم کا اطلاق کرتے ہیں، بشمول ٹرانزیکشنز کو بیچ کرنا اور ڈیٹا پبلیکیشن کے اخراجات کو کم کرنے کے لیے `calldata` کو کمپریس کرنا۔ Ethereum پر مبنی امید پسندانہ رول اپس استعمال کرنے میں کتنا خرچ آتا ہے اس کا حقیقی وقت کا جائزہ لینے کے لیے آپ [L2 فیس ٹریکر](https://l2fees.info/) کو چیک کر سکتے ہیں۔ + +## امید پسندانہ رول اپس Ethereum کو کیسے اسکیل کرتے ہیں؟ {#scaling-ethereum-with-optimistic-rollups} + +جیسا کہ وضاحت کی گئی ہے، امید پسندانہ رول اپس ڈیٹا کی دستیابی کی ضمانت کے لیے Ethereum پر کمپریسڈ ٹرانزیکشن ڈیٹا شائع کرتے ہیں۔ آن چین شائع کردہ ڈیٹا کو کمپریس کرنے کی صلاحیت امید پسندانہ رول اپس کے ساتھ Ethereum پر تھرو پٹ کو اسکیل کرنے کے لیے اہم ہے۔ + +مرکزی Ethereum چین اس بات کی حدود لگاتی ہے کہ بلاکس کتنا ڈیٹا رکھ سکتے ہیں، جو گیس یونٹس میں ظاہر ہوتا ہے ([اوسط بلاک سائز](/developers/docs/blocks/#block-size) 15 ملین گیس ہے)۔ اگرچہ یہ ہر ٹرانزیکشن کے لیے استعمال ہونے والی گیس کی مقدار کو محدود کرتا ہے، اس کا مطلب یہ بھی ہے کہ ہم ٹرانزیکشن سے متعلقہ ڈیٹا کو کم کرکے فی بلاک پروسیس ہونے والے ٹرانزیکشنز کو بڑھا سکتے ہیں— جس سے براہ راست اسکیل ایبلٹی میں بہتری آتی ہے۔ + +امید پسندانہ رول اپس ٹرانزیکشن ڈیٹا کمپریشن حاصل کرنے اور TPS کی شرحوں کو بہتر بنانے کے لیے کئی تکنیکوں کا استعمال کرتے ہیں۔ مثال کے طور پر، یہ [مضمون](https://vitalik.eth.limo/general/2021/01/05/rollup.html) اس بات کا موازنہ کرتا ہے کہ ایک بنیادی صارف ٹرانزیکشن (ایتھر بھیجنا) Mainnet پر کتنا ڈیٹا پیدا کرتا ہے بمقابلہ وہی ٹرانزیکشن رول اپ پر کتنا ڈیٹا پیدا کرتا ہے: + +| پیرامیٹر | ایتھیریم (L1) | رول اپ (L2) | +| -------- | ---------------------------------------------------- | ------------------------------------ | +| نونس | ~3 | 0 | +| Gasprice | ~8 | 0-0.5 | +| گیس | 3 | 0-0.5 | +| کو | 21 | 4 | +| قدر | 9 | ~3 | +| دستخط | ~68 (2 + 33 + 33) | ~0.5 | +| سے | 0 (sig سے بازیافت) | 4 | +| **کل** | **~112 بائٹس** | **~12 بائٹس** | + +ان اعداد و شمار پر کچھ موٹے حسابات کرنے سے ایک امید پسندانہ رول اپ کے ذریعہ فراہم کردہ اسکیل ایبلٹی میں بہتری کو ظاہر کرنے میں مدد مل سکتی ہے: + +1. ہر بلاک کے لیے ہدف کا سائز 15 ملین گیس ہے اور ایک بائٹ ڈیٹا کی تصدیق کے لیے 16 گیس خرچ ہوتی ہے۔ اوسط بلاک سائز کو 16 گیس سے تقسیم کرنا (15,000,000/16) ظاہر کرتا ہے کہ اوسط بلاک **937,500 بائٹس ڈیٹا** رکھ سکتا ہے۔ +2. اگر ایک بنیادی رول اپ ٹرانزیکشن میں 12 بائٹس استعمال ہوتی ہیں، تو اوسط Ethereum بلاک **78,125 رول اپ ٹرانزیکشنز** (937,500/12) یا **39 رول اپ بیچز** پر کارروائی کر سکتا ہے (اگر ہر بیچ میں اوسطاً 2,000 ٹرانزیکشنز ہوں)۔ +3. اگر Ethereum پر ہر 15 سیکنڈ میں ایک نیا بلاک تیار ہوتا ہے، تو رول اپ کی پروسیسنگ کی رفتار تقریباً **5,208 ٹرانزیکشنز فی سیکنڈ** ہوگی۔ یہ Ethereum بلاک میں رکھے جا سکنے والے بنیادی رول اپ ٹرانزیکشنز کی تعداد (**78,125**) کو اوسط بلاک ٹائم (**15 سیکنڈ**) سے تقسیم کرکے کیا جاتا ہے۔ + +یہ ایک کافی امید پسندانہ تخمینہ ہے، اس بات کو مدنظر رکھتے ہوئے کہ امید پسندانہ رول اپ ٹرانزیکشنز ممکنہ طور پر Ethereum پر ایک پورا بلاک نہیں بنا سکتے ہیں۔ تاہم، یہ ایک موٹا اندازہ دے سکتا ہے کہ امید پسندانہ رول اپس Ethereum صارفین کو کتنی اسکیل ایبلٹی حاصل کر سکتے ہیں (موجودہ نفاذ 2,000 TPS تک پیش کرتے ہیں)۔ + +Ethereum پر [ڈیٹا شارڈنگ](/roadmap/danksharding/) کے تعارف سے امید پسندانہ رول اپس میں اسکیل ایبلٹی میں بہتری کی توقع ہے۔ چونکہ رول اپ ٹرانزیکشنز کو دیگر غیر رول اپ ٹرانزیکشنز کے ساتھ بلاک اسپیس کا اشتراک کرنا پڑتا ہے، ان کی پروسیسنگ کی صلاحیت مرکزی Ethereum چین پر ڈیٹا تھرو پٹ سے محدود ہے۔ Danksharding L2 چینز کے لیے مہنگے، مستقل `CALLDATA` کے بجائے سستے، غیر مستقل "بلاب" اسٹوریج کا استعمال کرتے ہوئے، فی بلاک ڈیٹا شائع کرنے کے لیے دستیاب جگہ میں اضافہ کرے گا۔ + +### امید پسندانہ رول اپس کے فوائد اور نقصانات {#optimistic-rollups-pros-and-cons} + +| فوائد | نقصانات | +| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| سیکیورٹی یا بھروسے کی ضرورت کو قربان کیے بغیر اسکیل ایبلٹی میں بڑے پیمانے پر بہتری کی پیشکش کرتا ہے۔ | ممکنہ فراڈ چیلنجز کی وجہ سے ٹرانزیکشن کی حتمیت میں تاخیر۔ | +| ٹرانزیکشن ڈیٹا لیئر 1 چین پر اسٹور کیا جاتا ہے، جس سے شفافیت، سیکیورٹی، سنسرشپ مزاحمت، اور وکندریقرت میں بہتری آتی ہے۔ | مرکزی رول اپ آپریٹرز (سیکوینسرز) ٹرانزیکشن کی ترتیب کو متاثر کر سکتے ہیں۔ | +| فراڈ پروفنگ بھروسے کی ضرورت کے بغیر حتمیت کی ضمانت دیتا ہے اور ایماندار اقلیتوں کو چین کو محفوظ بنانے کی اجازت دیتا ہے۔ | اگر کوئی ایماندار نوڈ نہیں ہے تو ایک بدنیتی پر مبنی آپریٹر غلط بلاکس اور اسٹیٹ کمٹمنٹ پوسٹ کرکے فنڈز چرا سکتا ہے۔ | +| فراڈ پروف کا حساب لگانا باقاعدہ L2 نوڈ کے لیے کھلا ہے، موزونیت کے ثبوت (ZK-rollups میں استعمال ہونے والے) کے برعکس جن کے لیے خصوصی ہارڈ ویئر کی ضرورت ہوتی ہے۔ | سیکیورٹی ماڈل کم از کم ایک ایماندار نوڈ پر منحصر ہے جو رول اپ ٹرانزیکشنز کو انجام دیتا ہے اور غلط اسٹیٹ ٹرانزیشنز کو چیلنج کرنے کے لیے فراڈ پروف جمع کرتا ہے۔ | +| رول اپس کو "ٹرسٹ لیس لائیونیس" سے فائدہ ہوتا ہے (کوئی بھی ٹرانزیکشنز کو انجام دے کر اور دعوے پوسٹ کرکے چین کو آگے بڑھانے پر مجبور کرسکتا ہے) | صارفین کو Ethereum میں فنڈز واپس نکالنے سے پہلے ایک ہفتے کی چیلنج کی مدت ختم ہونے کا انتظار کرنا پڑتا ہے۔ | +| امید پسندانہ رول اپس چین پر سیکیورٹی بڑھانے کے لیے اچھی طرح سے ڈیزائن کردہ کرپٹو اکنامک ترغیبات پر انحصار کرتے ہیں۔ | رول اپس کو تمام ٹرانزیکشن ڈیٹا آن چین پوسٹ کرنا پڑتا ہے، جس سے اخراجات بڑھ سکتے ہیں۔ | +| EVM اور Solidity کے ساتھ مطابقت ڈویلپرز کو Ethereum-مقامی اسمارٹ کنٹریکٹس کو رول اپس میں پورٹ کرنے یا نئے dapps بنانے کے لیے موجودہ ٹولنگ کا استعمال کرنے کی اجازت دیتی ہے۔ | | + +### امید پسندانہ رول اپس کی ایک بصری وضاحت {#optimistic-video} + +کیا آپ زیادہ بصری سیکھنے والے ہیں؟ Finematics کو امید پسندانہ رول اپس کی وضاحت کرتے ہوئے دیکھیں: + + + +## امید پسندانہ رول اپس پر مزید پڑھیں + +- [امید پسندانہ رول اپس کیسے کام کرتے ہیں (مکمل گائیڈ)](https://www.alchemy.com/overviews/optimistic-rollups) +- [بلاک چین رول اپ کیا ہے؟ ایک تکنیکی تعارف](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) +- [آربیٹرم کے لیے ضروری گائیڈ](https://www.bankless.com/the-essential-guide-to-arbitrum) +- [ایتھیریم رولپس کے لیے عملی گائیڈ](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [ایتھیریم L2s میں فراڈ پروف کی حالت](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s) +- [امید پرستی کا رول اپ واقعی کیسے کام کرتا ہے؟](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) +- [OVM ڈیپ ڈائیو](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [امید پسندانہ ورچوئل مشین کیا ہے؟](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git a/public/content/translations/ur/developers/docs/scaling/plasma/index.md b/public/content/translations/ur/developers/docs/scaling/plasma/index.md new file mode 100644 index 00000000000..680beea6b92 --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/plasma/index.md @@ -0,0 +1,176 @@ +--- +title: "پلازما چینز" +description: "ایتھیریم کمیونٹی کی جانب سے فی الحال استعمال ہونے والے اسکیلنگ حل کے طور پر پلازما چینز کا تعارف۔" +lang: ur-in +incomplete: true +sidebarDepth: 3 +--- + +ایک پلازما چین ایک علیحدہ بلاک چین ہے جو Ethereum Mainnet سے منسلک ہے لیکن بلاک کی توثیق کے لیے اپنے میکانزم کے ساتھ آف چین ٹرانزیکشنز کو انجام دیتی ہے۔ پلازما چینز کو کبھی کبھی "چائلڈ" چینز بھی کہا جاتا ہے، جو بنیادی طور پر Ethereum Mainnet کی چھوٹی کاپیاں ہوتی ہیں۔ پلازما چینز تنازعات کو حل کرنے کے لیے [fraud proofs](/glossary/#fraud-proof) (جیسے [optimistic rollups](/developers/docs/scaling/optimistic-rollups/)) کا استعمال کرتی ہیں۔ + +مرکل ٹریز ان چینز کا ایک لامتناہی اسٹیک بنانے کے قابل بناتے ہیں جو پیرنٹ چینز (بشمول Ethereum Mainnet) سے بینڈوتھ کو آف لوڈ کرنے کے لیے کام کر سکتی ہیں۔ تاہم، جب کہ یہ چینز Ethereum سے کچھ سیکورٹی حاصل کرتی ہیں (fraud proofs کے ذریعے)، ان کی سیکورٹی اور کارکردگی کئی ڈیزائن کی حدود سے متاثر ہوتی ہے۔ + +## شرائط {#prerequisites} + +آپ کو تمام بنیادی موضوعات کی اچھی سمجھ اور [Ethereum اسکیلنگ](/developers/docs/scaling/) کی اعلیٰ سطحی سمجھ ہونی چاہیے۔ + +## پلازما کیا ہے؟ + +پلازما Ethereum جیسے عوامی بلاک چینز میں اسکیل ایبلٹی کو بہتر بنانے کا ایک فریم ورک ہے۔ جیسا کہ اصل [Plasma وائٹ پیپر](http://plasma.io/plasma.pdf) میں بیان کیا گیا ہے، پلازما چینز ایک دوسرے بلاک چین (جسے "روٹ چین" کہا جاتا ہے) کے اوپر بنائی گئی ہیں۔ ہر "چائلڈ چین" روٹ چین سے پھیلتی ہے اور عام طور پر پیرنٹ چین پر تعینات اسمارٹ کنٹریکٹ کے ذریعے اس کا انتظام کیا جاتا ہے۔ + +پلازما کنٹریکٹ دیگر چیزوں کے علاوہ، ایک [برج](/developers/docs/bridges/) کے طور پر کام کرتا ہے جو صارفین کو Ethereum Mainnet اور پلازما چین کے درمیان اثاثوں کو منتقل کرنے کی اجازت دیتا ہے۔ اگرچہ یہ انہیں [سائیڈ چینز](/developers/docs/scaling/sidechains/) کی طرح بناتا ہے، پلازما چینز کو — کم از کم، کسی حد تک — Ethereum Mainnet کی سیکورٹی سے فائدہ ہوتا ہے۔ یہ ان سائیڈ چینز کے برعکس ہے جو صرف اپنی سیکورٹی کے لیے ذمہ دار ہیں۔ + +## پلازما کیسے کام کرتا ہے؟ + +پلازما فریم ورک کے بنیادی اجزاء یہ ہیں: + +### آف چین کمپیوٹیشن {#offchain-computation} + +Ethereum کی موجودہ پروسیسنگ کی رفتار ~ 15-20 ٹرانزیکشنز فی سیکنڈ تک محدود ہے، جس سے زیادہ صارفین کو سنبھالنے کے لیے اسکیلنگ کے قلیل مدتی امکانات کم ہو جاتے ہیں۔ یہ مسئلہ بنیادی طور پر اس لیے موجود ہے کیونکہ Ethereum کے [اتفاق رائے کے میکانزم](/developers/docs/consensus-mechanisms/) کو بلاک چین کی حالت میں ہر اپ ڈیٹ کی تصدیق کے لیے بہت سے پیئر ٹو پیئر نوڈس کی ضرورت ہوتی ہے۔ + +اگرچہ Ethereum کا اتفاق رائے کا میکانزم سیکورٹی کے لیے ضروری ہے، لیکن ہو سکتا ہے کہ یہ ہر استعمال کے معاملے پر لاگو نہ ہو۔ مثال کے طور پر، ایلس کو ایک کپ کافی کے لیے باب کو اپنی روزانہ کی ادائیگیوں کی تصدیق پورے Ethereum نیٹ ورک سے کروانے کی ضرورت نہیں ہو سکتی ہے کیونکہ دونوں فریقوں کے درمیان کچھ بھروسہ موجود ہے۔ + +پلازما یہ فرض کرتا ہے کہ Ethereum Mainnet کو تمام ٹرانزیکشنز کی تصدیق کرنے کی ضرورت نہیں ہے۔ اس کے بجائے، ہم Mainnet سے باہر ٹرانزیکشنز پر کارروائی کر سکتے ہیں، جس سے نوڈس کو ہر ٹرانزیکشن کی توثیق کرنے سے آزاد کیا جا سکتا ہے۔ + +آف چین کمپیوٹیشن ضروری ہے کیونکہ پلازما چینز رفتار اور لاگت کے لیے بہتر بنا سکتی ہیں۔ مثال کے طور پر، ایک پلازما چین — اور اکثر ایسا کرتی ہے — ٹرانزیکشنز کی ترتیب اور عمل کو منظم کرنے کے لیے ایک ہی "آپریٹر" کا استعمال کر سکتی ہے۔ صرف ایک ادارے کے ٹرانزیکشنز کی تصدیق کرنے کے ساتھ، پلازما چین پر پروسیسنگ کا وقت Ethereum Mainnet سے تیز ہوتا ہے۔ + +### اسٹیٹ کمٹمنٹس {#state-commitments} + +جبکہ پلازما آف چین ٹرانزیکشنز کو انجام دیتا ہے، وہ مرکزی Ethereum ایگزیکیوشن لیئر پر طے پاتے ہیں—بصورت دیگر، پلازما چینز Ethereum کی سیکورٹی گارنٹی سے فائدہ نہیں اٹھا سکتیں۔ لیکن پلازما چین کی حالت کو جانے بغیر آف چین ٹرانزیکشنز کو حتمی شکل دینا سیکورٹی ماڈل کو توڑ دے گا اور غلط ٹرانزیکشنز کے پھیلاؤ کی اجازت دے گا۔ یہی وجہ ہے کہ آپریٹر، جو پلازما چین پر بلاکس بنانے کا ذمہ دار ادارہ ہے، کو وقتاً فوقتاً Ethereum پر "اسٹیٹ کمٹمنٹس" شائع کرنے کی ضرورت ہوتی ہے۔ + +ایک [کمٹمنٹ اسکیم](https://en.wikipedia.org/wiki/Commitment_scheme) کسی قدر یا بیان کے لیے کسی دوسرے فریق پر ظاہر کیے بغیر اسے کمٹ کرنے کی ایک کرپٹوگرافک تکنیک ہے۔ کمٹمنٹس اس معنی میں "پابند" ہیں کہ ایک بار جب آپ کسی قدر یا بیان کے لیے کمٹ کر لیتے ہیں تو آپ اسے تبدیل نہیں کر سکتے ہیں۔ پلازما میں اسٹیٹ کمٹمنٹس "مرکل روٹس" کی شکل اختیار کرتے ہیں (جو [مرکل ٹری](/whitepaper/#merkle-trees) سے اخذ کیے گئے ہیں) جسے آپریٹر وقفے وقفے سے Ethereum چین پر پلازما کنٹریکٹ کو بھیجتا ہے۔ + +مرکل روٹس کرپٹوگرافک پرائمیٹوز ہیں جو بڑی مقدار میں معلومات کو کمپریس کرنے کے قابل بناتے ہیں۔ ایک مرکل روٹ (اس معاملے میں اسے "بلاک روٹ" بھی کہا جاتا ہے) ایک بلاک میں تمام ٹرانزیکشنز کی نمائندگی کر سکتا ہے۔ مرکل روٹس اس بات کی تصدیق کرنا بھی آسان بناتے ہیں کہ ڈیٹا کا ایک چھوٹا سا حصہ بڑے ڈیٹا سیٹ کا حصہ ہے۔ مثال کے طور پر، ایک صارف کسی مخصوص بلاک میں ٹرانزیکشن کی شمولیت کو ثابت کرنے کے لیے [مرکل پروف](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) تیار کر سکتا ہے۔ + +مرکل روٹس Ethereum کو آف چین کی حالت کے بارے میں معلومات فراہم کرنے کے لیے اہم ہیں۔ آپ مرکل روٹس کو "سیو پوائنٹس" کے طور پر سوچ سکتے ہیں: آپریٹر کہہ رہا ہے، "یہ وقت کے x نقطہ پر پلازما چین کی حالت ہے، اور یہ ثبوت کے طور پر مرکل روٹ ہے۔" آپریٹر مرکل روٹ کے ساتھ پلازما چین کی _موجودہ حالت_ کے لیے کمٹ کر رہا ہے، یہی وجہ ہے کہ اسے "اسٹیٹ کمٹمنٹ" کہا جاتا ہے۔ + +### اندراج اور اخراج {#entries-and-exits} + +ایتھیریم کے صارفین کو پلازما سے فائدہ اٹھانے کے لیے، Mainnet اور پلازما چینز کے درمیان فنڈز کی منتقلی کا ایک میکانزم ہونا ضروری ہے۔ ہم من مانی طور پر پلازما چین پر کسی ایڈریس پر ایتھر نہیں بھیج سکتے، اگرچہ — یہ چینز غیر مطابقت پذیر ہیں، لہذا ٹرانزیکشن یا تو ناکام ہو جائے گی یا فنڈز کے نقصان کا باعث بنے گی۔ + +پلازما صارف کے اندراج اور اخراج پر کارروائی کرنے کے لیے Ethereum پر چلنے والے ماسٹر کنٹریکٹ کا استعمال کرتا ہے۔ یہ ماسٹر کنٹریکٹ اسٹیٹ کمٹمنٹس (پہلے بیان کیا گیا ہے) کو ٹریک کرنے اور فراڈ پروفس کے ذریعے بے ایمانی کے رویے کو سزا دینے کا بھی ذمہ دار ہے (اس پر بعد میں مزید)۔ + +#### پلازما چین میں داخل ہونا {#entering-the-plasma-chain} + +پلازما چین میں داخل ہونے کے لیے، ایلس (صارف) کو پلازما کنٹریکٹ میں ETH یا کوئی ERC-20 ٹوکن جمع کرنا ہوگا۔ پلازما آپریٹر، جو کنٹریکٹ کے ذخائر کو دیکھتا ہے، ایلس کی ابتدائی ڈپازٹ کے برابر رقم دوبارہ بناتا ہے اور اسے پلازما چین پر اس کے ایڈریس پر جاری کرتا ہے۔ ایلس کو چائلڈ چین پر فنڈز وصول کرنے کی تصدیق کرنا ضروری ہے اور پھر وہ ان فنڈز کو ٹرانزیکشنز کے لیے استعمال کر سکتی ہے۔ + +#### پلازما چین سے باہر نکلنا {#exiting-the-plasma-chain} + +پلازما چین سے باہر نکلنا کئی وجوہات کی بنا پر اس میں داخل ہونے سے زیادہ پیچیدہ ہے۔ سب سے بڑی بات یہ ہے کہ، جب کہ Ethereum کے پاس پلازما چین کی حالت کے بارے میں معلومات ہیں، وہ اس بات کی تصدیق نہیں کر سکتا کہ آیا معلومات سچی ہیں یا نہیں۔ ایک بدنیتی پر مبنی صارف غلط دعویٰ کر سکتا ہے ("میرے پاس 1000 ETH ہیں") اور دعوے کی پشت پناہی کے لیے جعلی ثبوت فراہم کر کے بچ سکتا ہے۔ + +بدنیتی پر مبنی انخلا کو روکنے کے لیے، ایک "چیلنج پیریڈ" متعارف کرایا گیا ہے۔ چیلنج کی مدت کے دوران (عام طور پر ایک ہفتہ)، کوئی بھی فراڈ پروف کا استعمال کرتے ہوئے واپسی کی درخواست کو چیلنج کر سکتا ہے۔ اگر چیلنج کامیاب ہو جاتا ہے، تو واپسی کی درخواست مسترد کر دی جاتی ہے۔ + +تاہم، یہ عام طور پر ہوتا ہے کہ صارفین ایماندار ہوتے ہیں اور اپنے فنڈز کے بارے میں صحیح دعوے کرتے ہیں۔ اس منظر نامے میں، ایلس روٹ چین (Ethereum) پر پلازما کنٹریکٹ کو ایک ٹرانزیکشن جمع کر کے واپسی کی درخواست شروع کرے گی۔ + +اسے ایک مرکل پروف بھی فراہم کرنا ہوگا جو اس بات کی تصدیق کرتا ہے کہ پلازما چین پر اس کے فنڈز بنانے والی ٹرانزیکشن کو ایک بلاک میں شامل کیا گیا تھا۔ یہ پلازما کے تکرار کے لیے ضروری ہے، جیسے [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html)، جو [Unspent Transaction Output (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output) ماڈل کا استعمال کرتے ہیں۔ + +دیگر، جیسے [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html)، UTXOs کے بجائے فنڈز کو [non-fungible tokens](/developers/docs/standards/tokens/erc-721/) کے طور پر نمائندگی کرتے ہیں۔ اس معاملے میں، واپس لینے کے لیے پلازما چین پر ٹوکنز کی ملکیت کا ثبوت درکار ہوتا ہے۔ یہ ٹوکن سے متعلق دو تازہ ترین ٹرانزیکشنز جمع کر کے اور ان ٹرانزیکشنز کی ایک بلاک میں شمولیت کی تصدیق کرنے والا مرکل پروف فراہم کر کے کیا جاتا ہے۔ + +صارف کو ایماندارانہ رویے کی ضمانت کے طور پر واپسی کی درخواست میں ایک بانڈ بھی شامل کرنا ہوگا۔ اگر کوئی چیلنجر ایلس کی واپسی کی درخواست کو غلط ثابت کرتا ہے، تو اس کا بانڈ سلیش کر دیا جاتا ہے، اور اس میں سے کچھ چیلنجر کو انعام کے طور پر دیا جاتا ہے۔ + +اگر چیلنج کی مدت کسی کے فراڈ پروف فراہم کیے بغیر گزر جاتی ہے، تو ایلس کی واپسی کی درخواست کو درست سمجھا جاتا ہے، جس سے وہ Ethereum پر پلازما کنٹریکٹ سے ڈپازٹ حاصل کر سکتی ہے۔ + +### تنازعات کا ثالثی {#dispute-arbitration} + +کسی بھی بلاک چین کی طرح، پلازما چینز کو ٹرانزیکشنز کی سالمیت کو نافذ کرنے کے لیے ایک میکانزم کی ضرورت ہوتی ہے اگر شرکاء بدنیتی سے کام کرتے ہیں (مثلاً، فنڈز کو دوگنا خرچ کرنا)۔ اس مقصد کے لیے، پلازما چینز اسٹیٹ ٹرانزیشنز کی درستگی سے متعلق تنازعات کو حل کرنے اور برے رویے کو سزا دینے کے لیے فراڈ پروفس کا استعمال کرتی ہیں۔ فراڈ پروفس کو ایک ایسے میکانزم کے طور پر استعمال کیا جاتا ہے جس کے ذریعے ایک پلازما چائلڈ چین اپنی پیرنٹ چین یا روٹ چین سے شکایت درج کراتی ہے۔ + +ایک فراڈ پروف صرف یہ دعویٰ ہے کہ ایک خاص اسٹیٹ ٹرانزیشن غلط ہے۔ ایک مثال یہ ہے کہ اگر کوئی صارف (ایلس) ایک ہی فنڈ کو دو بار خرچ کرنے کی کوشش کرتی ہے۔ شاید اس نے UTXO کو باب کے ساتھ ایک ٹرانزیکشن میں خرچ کیا ہو اور وہی UTXO (جو اب باب کا ہے) کسی دوسرے ٹرانزیکشن میں خرچ کرنا چاہتی ہو۔ + +واپسی کو روکنے کے لیے، باب ایلس کی پچھلی ٹرانزیکشن میں مذکورہ UTXO کو خرچ کرنے کے ثبوت اور ٹرانزیکشن کی ایک بلاک میں شمولیت کا مرکل پروف فراہم کر کے ایک فراڈ پروف تیار کرے گا۔ یہی عمل پلازما کیش میں کام کرتا ہے — باب کو یہ ثبوت فراہم کرنے کی ضرورت ہوگی کہ ایلس نے پہلے وہ ٹوکن منتقل کیے تھے جنہیں وہ واپس لینے کی کوشش کر رہی ہے۔ + +اگر باب کا چیلنج کامیاب ہو جاتا ہے، تو ایلس کی واپسی کی درخواست منسوخ کر دی جاتی ہے۔ تاہم، یہ طریقہ کار واپسی کی درخواستوں کے لیے چین کو دیکھنے کی باب کی صلاحیت پر انحصار کرتا ہے۔ اگر باب آف لائن ہے، تو ایلس چیلنج کی مدت ختم ہونے کے بعد بدنیتی پر مبنی واپسی پر کارروائی کر سکتی ہے۔ + +## پلازما میں بڑے پیمانے پر اخراج کا مسئلہ {#the-mass-exit-problem-in-plasma} + +بڑے پیمانے پر اخراج کا مسئلہ اس وقت ہوتا ہے جب بڑی تعداد میں صارفین ایک ہی وقت میں پلازما چین سے واپس لینے کی کوشش کرتے ہیں۔ یہ مسئلہ کیوں موجود ہے اس کا تعلق پلازما کے سب سے بڑے مسائل میں سے ایک سے ہے: **ڈیٹا کی عدم دستیابی**۔ + +ڈیٹا کی دستیابی اس بات کی تصدیق کرنے کی صلاحیت ہے کہ مجوزہ بلاک کے لیے معلومات دراصل بلاک چین نیٹ ورک پر شائع کی گئی تھیں۔ ایک بلاک "غیر دستیاب" ہوتا ہے اگر پروڈیوسر بلاک کو خود شائع کرتا ہے لیکن بلاک بنانے کے لیے استعمال ہونے والے ڈیٹا کو روک لیتا ہے۔ + +بلاکس دستیاب ہونے چاہئیں اگر نوڈس کو بلاک ڈاؤن لوڈ کرنے اور ٹرانزیکشنز کی درستگی کی تصدیق کرنے کے قابل ہونا ہے۔ بلاک چینز بلاک پروڈیوسرز کو تمام ٹرانزیکشن ڈیٹا آن چین پوسٹ کرنے پر مجبور کر کے ڈیٹا کی دستیابی کو یقینی بناتے ہیں۔ + +ڈیٹا کی دستیابی آف چین اسکیلنگ پروٹوکول کو محفوظ بنانے میں بھی مدد کرتی ہے جو Ethereum کی بیس لیئر پر بنتے ہیں۔ ان چینز پر آپریٹرز کو Ethereum پر ٹرانزیکشن ڈیٹا شائع کرنے پر مجبور کر کے، کوئی بھی چین کی صحیح حالت کا حوالہ دیتے ہوئے فراڈ پروفس بنا کر غلط بلاکس کو چیلنج کر سکتا ہے۔ + +پلازما چینز بنیادی طور پر آپریٹر کے ساتھ ٹرانزیکشن ڈیٹا کو اسٹور کرتی ہیں اور **Mainnet پر کوئی ڈیٹا شائع نہیں کرتی ہیں** (یعنی، وقتاً فوقتاً اسٹیٹ کمٹمنٹس کے علاوہ)۔ اس کا مطلب ہے کہ صارفین کو بلاک ڈیٹا فراہم کرنے کے لیے آپریٹر پر انحصار کرنا چاہیے اگر انہیں غلط ٹرانزیکشنز کو چیلنج کرنے والے فراڈ پروفس بنانے کی ضرورت ہے۔ اگر یہ نظام کام کرتا ہے، تو صارفین فنڈز کو محفوظ بنانے کے لیے ہمیشہ فراڈ پروفس کا استعمال کر سکتے ہیں۔ + +مسئلہ اس وقت شروع ہوتا ہے جب آپریٹر، نہ کہ کوئی صارف، بدنیتی سے کام کرنے والا فریق ہوتا ہے۔ چونکہ آپریٹر بلاک چین کے واحد کنٹرول میں ہے، ان کے پاس بڑے پیمانے پر غلط اسٹیٹ ٹرانزیشنز کو آگے بڑھانے کی زیادہ ترغیب ہوتی ہے، جیسے کہ پلازما چین پر صارفین سے تعلق رکھنے والے فنڈز کو چوری کرنا۔ + +اس معاملے میں، کلاسک فراڈ پروف سسٹم کام نہیں کرتا ہے۔ آپریٹر آسانی سے ایلس اور باب کے فنڈز کو اپنے والیٹ میں منتقل کرنے والی ایک غلط ٹرانزیکشن کر سکتا ہے اور فراڈ پروف بنانے کے لیے ضروری ڈیٹا کو چھپا سکتا ہے۔ یہ ممکن ہے کیونکہ آپریٹر کو صارفین یا Mainnet کو ڈیٹا دستیاب کرانے کی ضرورت نہیں ہے۔ + +لہذا، سب سے زیادہ امید افزا حل پلازما چین سے صارفین کا "بڑے پیمانے پر اخراج" کی کوشش کرنا ہے۔ بڑے پیمانے پر اخراج بدنیتی پر مبنی آپریٹر کے فنڈز چوری کرنے کے منصوبے کو سست کر دیتا ہے اور صارفین کے لیے کچھ حد تک تحفظ فراہم کرتا ہے۔ واپسی کی درخواستوں کو اس بنیاد پر ترتیب دیا جاتا ہے کہ ہر UTXO (یا ٹوکن) کب بنایا گیا تھا، جس سے بدنیتی پر مبنی آپریٹرز کو ایماندار صارفین کو فرنٹ رننگ کرنے سے روکا جا سکتا ہے۔ + +اس کے باوجود، ہمیں اب بھی بڑے پیمانے پر اخراج کے دوران واپسی کی درخواستوں کی درستگی کی تصدیق کرنے کا ایک طریقہ درکار ہے—تاکہ موقع پرست افراد کو غلط اخراج کی کارروائی کے افراتفری سے فائدہ اٹھانے سے روکا جا سکے۔ حل آسان ہے: صارفین سے اپنے پیسے نکالنے کے لیے چین کی آخری **درست حالت** پوسٹ کرنے کی ضرورت ہے۔ + +لیکن اس طریقہ کار میں اب بھی مسائل ہیں۔ مثال کے طور پر، اگر پلازما چین کے تمام صارفین کو باہر نکلنے کی ضرورت ہے (جو ایک بدنیتی پر مبنی آپریٹر کی صورت میں ممکن ہے)، تو پلازما چین کی پوری درست حالت کو Ethereum کی بیس لیئر پر ایک ساتھ ڈمپ کرنا ہوگا۔ پلازما چینز کے من مانے سائز (زیادہ تھرو پٹ = زیادہ ڈیٹا) اور Ethereum کی پروسیسنگ کی رفتار پر پابندیوں کے ساتھ، یہ ایک مثالی حل نہیں ہے۔ + +اگرچہ ایگزٹ گیمز تھیوری میں اچھے لگتے ہیں، لیکن حقیقی زندگی میں بڑے پیمانے پر اخراج سے Ethereum پر ہی نیٹ ورک بھر میں بھیڑ پیدا ہونے کا امکان ہے۔ Ethereum کی فعالیت کو نقصان پہنچانے کے علاوہ، ایک ناقص مربوط بڑے پیمانے پر اخراج کا مطلب یہ ہے کہ آپریٹر پلازما چین پر ہر اکاؤنٹ کو خالی کرنے سے پہلے صارفین فنڈز واپس نہیں لے سکیں گے۔ + +## پلازما کے فائدے اور نقصانات {#pros-and-cons-of-plasma} + +| فوائد | نقصانات | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| اعلیٰ تھرو پٹ اور فی ٹرانزیکشن کم لاگت پیش کرتا ہے۔ | عمومی کمپیوٹیشن کو سپورٹ نہیں کرتا (اسمارٹ کنٹریکٹس نہیں چلا سکتا)۔ صرف بنیادی ٹوکن ٹرانسفر، سویپس، اور چند دیگر ٹرانزیکشن کی اقسام پریڈیکیٹ منطق کے ذریعے سپورٹ کی جاتی ہیں۔ | +| من مانے صارفین کے درمیان ٹرانزیکشنز کے لیے اچھا ہے (اگر دونوں پلازما چین پر قائم ہیں تو فی صارف جوڑی کوئی اوور ہیڈ نہیں) | اپنے فنڈز کی سیکورٹی کو یقینی بنانے کے لیے وقتاً فوقتاً نیٹ ورک (لائیونیس کی ضرورت) کو دیکھنے یا یہ ذمہ داری کسی اور کو سونپنے کی ضرورت ہے۔ | +| پلازما چینز کو مخصوص استعمال کے معاملات کے مطابق ڈھالا جا سکتا ہے جو مرکزی چین سے غیر متعلق ہیں۔ کوئی بھی، بشمول کاروبار، مختلف سیاق و سباق میں کام کرنے والا اسکیل ایبل انفراسٹرکچر فراہم کرنے کے لیے پلازما اسمارٹ کنٹریکٹس کو اپنی مرضی کے مطابق بنا سکتا ہے۔ | ڈیٹا کو ذخیرہ کرنے اور درخواست پر اسے پیش کرنے کے لیے ایک یا زیادہ آپریٹرز پر انحصار کرتا ہے۔ | +| کمپیوٹیشن اور اسٹوریج کو آف چین منتقل کر کے Ethereum Mainnet پر بوجھ کم کرتا ہے۔ | چیلنجوں کی اجازت دینے کے لیے واپسی میں کئی دنوں کی تاخیر ہوتی ہے۔ فنجیبل اثاثوں کے لیے، اسے لیکویڈیٹی فراہم کرنے والوں کے ذریعے کم کیا جا سکتا ہے، لیکن اس سے منسلک سرمائے کی لاگت ہوتی ہے۔ | +| | اگر بہت سارے صارفین بیک وقت باہر نکلنے کی کوشش کرتے ہیں، تو Ethereum Mainnet بھیڑ بھاڑ کا شکار ہو سکتا ہے۔ | + +## پلازما بمقابلہ لیئر 2 اسکیلنگ پروٹوکول {#plasma-vs-layer-2} + +جب کہ پلازما کو کبھی Ethereum کے لیے ایک مفید اسکیلنگ حل سمجھا جاتا تھا، اس کے بعد سے اسے [لیئر 2 (L2) اسکیلنگ پروٹوکول](/layer-2/) کے حق میں چھوڑ دیا گیا ہے۔ L2 اسکیلنگ حل پلازما کے کئی مسائل کا ازالہ کرتے ہیں: + +### کارکردگی {#efficiency} + +[زیرو نالج رول اپس](/developers/docs/scaling/zk-rollups) آف چین پروسیس کیے گئے ٹرانزیکشنز کے ہر بیچ کی درستگی کے کرپٹوگرافک ثبوت تیار کرتے ہیں۔ یہ صارفین (اور آپریٹرز) کو غلط اسٹیٹ ٹرانزیشنز کو آگے بڑھانے سے روکتا ہے، جس سے چیلنج کی مدت اور ایگزٹ گیمز کی ضرورت ختم ہو جاتی ہے۔ اس کا یہ بھی مطلب ہے کہ صارفین کو اپنے فنڈز کو محفوظ بنانے کے لیے وقتاً فوقتاً چین کو دیکھنے کی ضرورت نہیں ہے۔ + +### اسمارٹ کنٹریکٹس کے لیے سپورٹ {#support-for-smart-contracts} + +پلازما فریم ورک کے ساتھ ایک اور مسئلہ [Ethereum اسمارٹ کنٹریکٹس کے نفاذ کی حمایت کرنے میں ناکامی](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4) تھا۔ نتیجے کے طور پر، پلازما کے زیادہ تر نفاذ زیادہ تر سادہ ادائیگیوں یا ERC-20 ٹوکنز کے تبادلے کے لیے بنائے گئے تھے۔ + +اس کے برعکس، آپٹیمسٹک رول اپس، [Ethereum Virtual Machine](/developers/docs/evm/) کے ساتھ مطابقت رکھتے ہیں اور Ethereum-native [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) چلا سکتے ہیں، جو انہیں [ڈی سینٹرلائزڈ ایپلیکیشنز](/developers/docs/dapps/) کو اسکیل کرنے کے لیے ایک مفید اور _محفوظ_ حل بناتے ہیں۔ اسی طرح، [EVM (zkEVM) کا زیرو نالج نفاذ بنانے](https://ethresear.ch/t/a-zk-evm-specification/11549) کے منصوبے جاری ہیں جو ZK-rollups کو من مانی منطق پر کارروائی کرنے اور اسمارٹ کنٹریکٹس کو انجام دینے کی اجازت دے گا۔ + +### ڈیٹا کی عدم دستیابی {#data-unavailability} + +جیسا کہ پہلے بیان کیا گیا ہے، پلازما ڈیٹا کی دستیابی کے مسئلے سے دوچار ہے۔ اگر کوئی بدنیتی پر مبنی آپریٹر پلازما چین پر ایک غلط ٹرانزیشن کو آگے بڑھاتا ہے، تو صارفین اسے چیلنج نہیں کر پائیں گے کیونکہ آپریٹر فراڈ پروف بنانے کے لیے درکار ڈیٹا کو روک سکتا ہے۔ رول اپس اس مسئلے کو آپریٹرز کو Ethereum پر ٹرانزیکشن ڈیٹا پوسٹ کرنے پر مجبور کر کے حل کرتے ہیں، جس سے کوئی بھی چین کی حالت کی تصدیق کر سکتا ہے اور اگر ضروری ہو تو فراڈ پروفس بنا سکتا ہے۔ + +### بڑے پیمانے پر اخراج کا مسئلہ {#mass-exit-problem} + +ZK-rollups اور آپٹیمسٹک رول اپس دونوں پلازما کے بڑے پیمانے پر اخراج کے مسئلے کو مختلف طریقوں سے حل کرتے ہیں۔ مثال کے طور پر، ایک ZK-rollup کرپٹوگرافک میکانزم پر انحصار کرتا ہے جو اس بات کو یقینی بناتا ہے کہ آپریٹرز کسی بھی منظر نامے میں صارف کے فنڈز کو چوری نہیں کر سکتے۔ + +اسی طرح، آپٹیمسٹک رول اپس واپسی پر تاخیر کی مدت عائد کرتے ہیں جس کے دوران کوئی بھی چیلنج شروع کر سکتا ہے اور بدنیتی پر مبنی واپسی کی درخواستوں کو روک سکتا ہے۔ جب کہ یہ پلازما کی طرح ہے، فرق یہ ہے کہ تصدیق کنندگان کو فراڈ پروفس بنانے کے لیے درکار ڈیٹا تک رسائی حاصل ہوتی ہے۔ اس طرح، رول اپ صارفین کو Ethereum Mainnet پر ایک جنونی، "سب سے پہلے باہر نکلنے" کی منتقلی میں مشغول ہونے کی ضرورت نہیں ہے۔ + +## پلازما سائیڈ چینز اور شارڈنگ سے کیسے مختلف ہے؟ {#plasma-sidechains-sharding} + +پلازما، سائیڈ چینز، اور شارڈنگ کافی حد تک ملتے جلتے ہیں کیونکہ یہ سب کسی نہ کسی طرح سے Ethereum Mainnet سے جڑتے ہیں۔ تاہم، ان کنکشنز کی سطح اور طاقت مختلف ہوتی ہے، جو ہر اسکیلنگ حل کی سیکورٹی خصوصیات کو متاثر کرتی ہے۔ + +### پلازما بمقابلہ سائیڈ چینز {#plasma-vs-sidechains} + +ایک [سائیڈ چین](/developers/docs/scaling/sidechains/) ایک آزادانہ طور پر چلنے والا بلاک چین ہے جو دو طرفہ برج کے ذریعے Ethereum Mainnet سے جڑا ہوا ہے۔ [برجز](/bridges/) صارفین کو دو بلاک چینز کے درمیان ٹوکن کا تبادلہ کرنے کی اجازت دیتے ہیں تاکہ سائیڈ چین پر ٹرانزیکشن کیا جا سکے، Ethereum Mainnet پر بھیڑ کو کم کیا جا سکے اور اسکیل ایبلٹی کو بہتر بنایا جا سکے۔ +سائیڈ چینز ایک علیحدہ اتفاق رائے کا میکانزم استعمال کرتے ہیں اور عام طور پر Ethereum Mainnet سے بہت چھوٹے ہوتے ہیں۔ نتیجے کے طور پر، ان چینز پر اثاثوں کو برج کرنے میں زیادہ خطرہ شامل ہوتا ہے۔ سائیڈ چین ماڈل میں Ethereum Mainnet سے وراثت میں ملنے والی سیکورٹی گارنٹی کی کمی کے پیش نظر، صارفین کو سائیڈ چین پر حملے میں فنڈز کے نقصان کا خطرہ ہوتا ہے۔ + +اس کے برعکس، پلازما چینز اپنی سیکورٹی Mainnet سے حاصل کرتی ہیں۔ یہ انہیں سائیڈ چینز سے قابل پیمائش حد تک زیادہ محفوظ بناتا ہے۔ سائیڈ چینز اور پلازما چینز دونوں کے مختلف اتفاق رائے پروٹوکول ہو سکتے ہیں، لیکن فرق یہ ہے کہ پلازما چینز Ethereum Mainnet پر ہر بلاک کے لیے مرکل روٹس شائع کرتی ہیں۔ بلاک روٹس معلومات کے چھوٹے ٹکڑے ہیں جن کا استعمال ہم پلازما چین پر ہونے والے ٹرانزیکشنز کے بارے میں معلومات کی تصدیق کے لیے کر سکتے ہیں۔ اگر پلازما چین پر کوئی حملہ ہوتا ہے، تو صارفین مناسب ثبوتوں کا استعمال کرتے ہوئے اپنے فنڈز کو محفوظ طریقے سے Mainnet میں واپس لے سکتے ہیں۔ + +### پلازما بمقابلہ شارڈنگ {#plasma-vs-sharding} + +پلازما چینز اور شارڈ چینز دونوں وقتاً فوقتاً Ethereum Mainnet پر کرپٹوگرافک ثبوت شائع کرتے ہیں۔ تاہم، دونوں کی سیکورٹی کی خصوصیات مختلف ہیں۔ + +شارڈ چینز "کولیشن ہیڈرز" کو Mainnet پر کمٹ کرتی ہیں جس میں ہر ڈیٹا شارڈ کے بارے میں تفصیلی معلومات ہوتی ہیں۔ Mainnet پر نوڈس ڈیٹا شارڈز کی درستگی کی تصدیق اور نفاذ کرتے ہیں، جس سے غلط شارڈ ٹرانزیشنز کے امکان کو کم کیا جاتا ہے اور نیٹ ورک کو بدنیتی پر مبنی سرگرمیوں سے بچایا جاتا ہے۔ + +پلازما مختلف ہے کیونکہ Mainnet کو صرف چائلڈ چینز کی حالت کے بارے میں کم سے کم معلومات ملتی ہیں۔ اس کا مطلب ہے کہ Mainnet چائلڈ چینز پر کی جانے والی ٹرانزیکشنز کی مؤثر طریقے سے تصدیق نہیں کر سکتا، جس سے وہ کم محفوظ ہو جاتی ہیں۔ + +**نوٹ** کریں کہ Ethereum بلاک چین کی شارڈنگ اب روڈ میپ پر نہیں ہے۔ اسے رول اپس اور [ڈانک شارڈنگ](/roadmap/danksharding) کے ذریعے اسکیلنگ نے پیچھے چھوڑ دیا ہے۔ + +### پلازما استعمال کریں {#use-plasma} + +متعدد پروجیکٹس پلازما کے نفاذ فراہم کرتے ہیں جنہیں آپ اپنے ڈیپس میں ضم کر سکتے ہیں: + +- [Polygon](https://polygon.technology/) (پہلے Matic Network) + +## مزید پڑھیں {#further-reading} + +- [پلازما سیکھیں](https://www.learnplasma.org/en/) +- ["مشترکہ سیکورٹی" کا کیا مطلب ہے اور یہ اتنا اہم کیوں ہے اس کی ایک فوری یاد دہانی](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [سائیڈ چینز بمقابلہ پلازما بمقابلہ شارڈنگ](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) +- [پلازما کو سمجھنا، حصہ 1: بنیادی باتیں](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [پلازما کی زندگی اور موت](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/scaling/sidechains/index.md b/public/content/translations/ur/developers/docs/scaling/sidechains/index.md new file mode 100644 index 00000000000..3afaed9f341 --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/sidechains/index.md @@ -0,0 +1,73 @@ +--- +title: "سائیڈ چینز" +description: "ایتھیریم کمیونٹی کے ذریعہ فی الحال استعمال ہونے والے اسکیلنگ حل کے طور پر سائیڈ چینز کا تعارف۔" +lang: ur-in +sidebarDepth: 3 +--- + +ایک سائیڈ چین ایک الگ بلاک چین ہے جو ایتھیریم سے آزاد چلتی ہے اور دو طرفہ برج کے ذریعے ایتھیریم مین نیٹ سے منسلک ہوتی ہے۔ سائیڈ چینز میں الگ بلاک پیرامیٹرز اور [کنسینسس الگورتھم](/developers/docs/consensus-mechanisms/) ہو سکتے ہیں، جو اکثر ٹرانزیکشنز کی موثر پروسیسنگ کے لیے ڈیزائن کیے جاتے ہیں۔ سائیڈ چین کا استعمال کرنے میں کچھ سمجھوتے شامل ہیں، کیونکہ وہ ایتھیریم کی سیکیورٹی خصوصیات کو وراثت میں نہیں لیتے ہیں۔ [لیئر 2 اسکیلنگ حل](/layer-2/) کے برعکس، سائیڈ چینز اسٹیٹ کی تبدیلیوں اور ٹرانزیکشن ڈیٹا کو ایتھیریم مین نیٹ پر واپس پوسٹ نہیں کرتے ہیں۔ + +سائیڈ چینز اعلی تھروپٹ ([اسکیل ایبلیٹی ٹرائلیما](https://vitalik.eth.limo/general/2021/05/23/scaling.html)) حاصل کرنے کے لیے کچھ حد تک غیر مرکزیت یا سیکیورٹی کی قربانی بھی دیتے ہیں۔ تاہم، ایتھیریم غیر مرکزیت اور سیکیورٹی پر سمجھوتہ کیے بغیر اسکیلنگ کے لیے پرعزم ہے۔ + +## سائیڈ چینز کیسے کام کرتے ہیں؟ {#how-do-sidechains-work} + +سائیڈ چینز آزاد بلاک چینز ہیں، جن کی مختلف تاریخیں، ڈیولپمنٹ روڈ میپس، اور ڈیزائن کے تحفظات ہوتے ہیں۔ اگرچہ ایک سائیڈ چین ایتھیریم کے ساتھ کچھ سطحی مماثلتیں رکھ سکتی ہے، لیکن اس کی کئی منفرد خصوصیات ہیں۔ + +### کنسینسس الگورتھم {#consensus-algorithms} + +سائیڈ چینز کو منفرد (یعنی ایتھیریم سے مختلف) بنانے والی خصوصیات میں سے ایک استعمال شدہ کنسینسس الگورتھم ہے۔ سائیڈ چینز کنسینسس کے لیے ایتھیریم پر انحصار نہیں کرتے اور اپنی ضروریات کے مطابق متبادل کنسینسس پروٹوکولز کا انتخاب کر سکتے ہیں۔ سائیڈ چینز پر استعمال ہونے والے کنسینسس الگورتھم کی کچھ مثالیں شامل ہیں: + +- [ثبوتِ اختیار (Proof-of-authority)](/developers/docs/consensus-mechanisms/poa/) +- [ڈیلیگیٹڈ پروف-آف-اسٹیک](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [بائزنٹائن فالٹ ٹولرنس](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained)۔ + +ایتھیریم کی طرح، سائیڈ چینز میں ویلیڈیٹنگ نوڈز ہوتے ہیں جو ٹرانزیکشنز کی تصدیق اور پروسیسنگ کرتے ہیں، بلاکس بناتے ہیں، اور بلاک چین اسٹیٹ کو اسٹور کرتے ہیں۔ ویلیڈیٹرز پورے نیٹ ورک میں کنسینسس کو برقرار رکھنے اور اسے بدنیتی پر مبنی حملوں سے محفوظ رکھنے کے بھی ذمہ دار ہیں۔ + +#### بلاک پیرامیٹرز {#block-parameters} + +ایتھیریم [بلاک ٹائمز](/developers/docs/blocks/#block-time) (یعنی، نئے بلاکس بنانے میں لگنے والا وقت) اور [بلاک سائزز](/developers/docs/blocks/#block-size) (یعنی، ہر بلاک میں موجود ڈیٹا کی مقدار جسے گیس میں ظاہر کیا جاتا ہے) پر حدود عائد کرتا ہے۔ اس کے برعکس، سائیڈ چینز اکثر اعلی تھروپٹ، تیز ٹرانزیکشنز، اور کم فیس حاصل کرنے کے لیے مختلف پیرامیٹرز، جیسے تیز بلاک ٹائمز اور زیادہ گیس کی حدود، اپناتے ہیں۔ + +جبکہ اس کے کچھ فوائد ہیں، اس کے نیٹ ورک کی غیر مرکزیت اور سیکیورٹی کے لیے اہم مضمرات ہیں۔ بلاک پیرامیٹرز، جیسے تیز بلاک ٹائمز اور بڑے بلاک سائزز، ایک مکمل نوڈ چلانے کی مشکل کو بڑھاتے ہیں—جس سے چند "سپر نوڈز" چین کو محفوظ بنانے کے ذمہ دار رہ جاتے ہیں۔ ایسے منظر نامے میں، ویلیڈیٹر کی ملی بھگت یا چین پر بدنیتی پر مبنی قبضے کا امکان بڑھ جاتا ہے۔ + +بلاک چینز کو غیر مرکزیت کو نقصان پہنچائے بغیر اسکیل کرنے کے لیے، نوڈ چلانا ہر ایک کے لیے کھلا ہونا چاہیے—ضروری نہیں کہ صرف خصوصی ہارڈویئر والی پارٹیاں ہی چلا سکیں۔ یہی وجہ ہے کہ یہ یقینی بنانے کے لیے کوششیں جاری ہیں کہ ہر کوئی ایتھیریم نیٹ ورک پر [ایک مکمل نوڈ چلا سکے](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node)۔ + +### EVM مطابقت {#evm-compatibility} + +کچھ سائیڈ چینز EVM-مطابقت پذیر ہوتی ہیں اور [ایتھیریم ورچوئل مشین (EVM)](/developers/docs/evm/) کے لیے تیار کردہ کنٹریکٹس کو انجام دینے کے قابل ہوتی ہیں۔ EVM-مطابقت پذیر سائیڈ چینز [سولیڈیٹی میں لکھے گئے](/developers/docs/smart-contracts/languages/) اسمارٹ کنٹریکٹس کے ساتھ ساتھ دیگر EVM اسمارٹ کنٹریکٹ زبانوں کو بھی سپورٹ کرتی ہیں، جس کا مطلب ہے کہ ایتھیریم مین نیٹ کے لیے لکھے گئے اسمارٹ کنٹریکٹس EVM-مطابقت پذیر سائیڈ چینز پر بھی کام کریں گے۔ + +اس کا مطلب ہے کہ اگر آپ اپنے [dapp](/developers/docs/dapps/) کو کسی سائیڈ چین پر استعمال کرنا چاہتے ہیں، تو یہ صرف اس سائیڈ چین پر اپنے [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) کو تعینات کرنے کا معاملہ ہے۔ یہ بالکل Mainnet کی طرح دکھتا، محسوس ہوتا، اور کام کرتا ہے—آپ سولیڈیٹی میں کنٹریکٹس لکھتے ہیں، اور سائیڈ چینز RPC کے ذریعے چین کے ساتھ تعامل کرتے ہیں۔ + +چونکہ سائیڈ چینز EVM-مطابقت پذیر ہیں، انہیں ایتھیریم-نیٹیو dapps کے لیے ایک مفید [اسکیلنگ حل](/developers/docs/scaling/) سمجھا جاتا ہے۔ سائیڈ چین پر آپ کے dapp کے ساتھ، صارفین کم گیس فیس اور تیز ٹرانزیکشنز سے لطف اندوز ہو سکتے ہیں، خاص طور پر اگر Mainnet پر بھیڑ ہو۔ + +تاہم، جیسا کہ پہلے بیان کیا گیا ہے، سائیڈ چین کا استعمال کرنے میں اہم سمجھوتے شامل ہیں۔ ہر سائیڈ چین اپنی سیکیورٹی کے لیے ذمہ دار ہے اور ایتھیریم کی سیکیورٹی خصوصیات کو وراثت میں نہیں لیتی۔ اس سے بدنیتی پر مبنی رویے کا امکان بڑھ جاتا ہے جو آپ کے صارفین کو متاثر کر سکتا ہے یا ان کے فنڈز کو خطرے میں ڈال سکتا ہے۔ + +### اثاثوں کی نقل و حرکت {#asset-movement} + +ایک الگ بلاک چین کو ایتھیریم مین نیٹ کے لیے سائیڈ چین بننے کے لیے، اسے ایتھیریم مین نیٹ سے اور اس میں اثاثوں کی منتقلی کو آسان بنانے کی صلاحیت کی ضرورت ہوتی ہے۔ ایتھیریم کے ساتھ یہ باہمی عمل ایک بلاک چین برج کا استعمال کرکے حاصل کیا جاتا ہے۔ [برجز](/bridges/) ایتھیریم مین نیٹ اور ایک سائیڈ چین پر تعینات کردہ اسمارٹ کنٹریکٹس کا استعمال کرتے ہیں تاکہ ان کے درمیان فنڈز کی برجنگ کو کنٹرول کیا جا سکے۔ + +جبکہ برجز صارفین کو ایتھیریم اور سائیڈ چین کے درمیان فنڈز منتقل کرنے میں مدد کرتے ہیں، اثاثے جسمانی طور پر دونوں چینز کے درمیان منتقل نہیں ہوتے ہیں۔ اس کے بجائے، چینز کے درمیان قدر منتقل کرنے کے لیے ایسے میکانزم استعمال کیے جاتے ہیں جن میں عام طور پر منٹنگ اور برننگ شامل ہوتی ہے۔ [برجز کیسے کام کرتے ہیں](/developers/docs/bridges/#how-do-bridges-work) کے بارے میں مزید جانیں۔ + +## سائیڈ چینز کے فوائد اور نقصانات {#pros-and-cons-of-sidechains} + +| فوائد | نقصانات | +| --------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| سائیڈ چینز کی بنیاد بننے والی ٹیکنالوجی اچھی طرح سے قائم ہے اور وسیع تحقیق اور ڈیزائن میں بہتری سے فائدہ اٹھاتی ہے۔ | سائیڈ چینز اسکیل ایبلیٹی کے لیے کچھ حد تک غیر مرکزیت اور بے اعتمادی کا سمجھوتہ کرتے ہیں۔ | +| سائیڈ چینز عمومی کمپیوٹیشن کو سپورٹ کرتے ہیں اور EVM مطابقت پیش کرتے ہیں (وہ ایتھیریم-نیٹیو dapps چلا سکتے ہیں)۔ | ایک سائیڈ چین ایک الگ کنسینسس میکانزم کا استعمال کرتی ہے اور ایتھیریم کی سیکیورٹی گارنٹیوں سے فائدہ نہیں اٹھاتی۔ | +| سائیڈ چینز ٹرانزیکشنز کو موثر طریقے سے پروسیس کرنے اور صارفین کے لیے ٹرانزیکشن فیس کو کم کرنے کے لیے مختلف کنسینسس ماڈلز کا استعمال کرتے ہیں۔ | سائیڈ چینز کو زیادہ اعتماد کے مفروضوں کی ضرورت ہوتی ہے (مثال کے طور پر، بدنیتی پر مبنی سائیڈ چین ویلیڈیٹرز کا ایک کورم دھوکہ دہی کر سکتا ہے)۔ | +| EVM-مطابقت پذیر سائیڈ چینز dapps کو اپنے ایکو سسٹم کو وسعت دینے کی اجازت دیتی ہیں۔ | | + +### سائیڈ چینز کا استعمال کریں {#use-sidechains} + +متعدد پروجیکٹس سائیڈ چینز کے نفاذ فراہم کرتے ہیں جنہیں آپ اپنے dapps میں ضم کر سکتے ہیں: + +- [Polygon PoS](https://polygon.technology/solutions/polygon-pos) +- [Skale](https://skale.network/) +- [Gnosis Chain (formerly xDai)](https://www.gnosischain.com/) +- [Loom Network](https://loomx.io/) +- [Metis Andromeda](https://www.metis.io/) + +## مزید پڑھیں {#further-reading} + +- [سائیڈ چینز کے ذریعے ایتھیریم dapps کو اسکیل کرنا](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _8 فروری، 2018 - Georgios Konstantopoulos_ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/scaling/state-channels/index.md b/public/content/translations/ur/developers/docs/scaling/state-channels/index.md new file mode 100644 index 00000000000..6b68d7853f5 --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/state-channels/index.md @@ -0,0 +1,261 @@ +--- +title: "اسٹیٹ چینلز" +description: "ایتھیریم کمیونٹی کے ذریعہ فی الحال استعمال ہونے والے اسکیلنگ حل کے طور پر اسٹیٹ چینلز اور ادائیگی چینلز کا تعارف۔" +lang: ur-in +sidebarDepth: 3 +--- + +اسٹیٹ چینلز شرکاء کو ایتھیریم مین نیٹ کے ساتھ تعامل کو کم سے کم رکھتے ہوئے محفوظ طریقے سے آف چین لین دین کرنے کی اجازت دیتے ہیں۔ چینل کے پیئرس چینل کو کھولنے اور بند کرنے کے لیے صرف دو آن چین لین دین جمع کرواتے ہوئے آف چین لین دین کی من مانی تعداد کر سکتے ہیں۔ یہ بہت زیادہ لین دین کی تھروپٹ کی اجازت دیتا ہے اور صارفین کے لیے کم لاگت کا نتیجہ ہوتا ہے۔ + +## شرائط {#prerequisites} + +آپ کو [ایتھیریم اسکیلنگ](/developers/docs/scaling/) اور [لیئر 2](/layer-2/) پر ہمارے صفحات کو پڑھنا اور سمجھنا چاہیے تھا۔ + +## چینلز کیا ہیں؟ {#what-are-channels} + +ایتھیریم جیسے عوامی بلاک چینز کو ان کے تقسیم شدہ فن تعمیر کی وجہ سے اسکیل ایبلٹی کے چیلنجز کا سامنا ہے: آن چین لین دین کو تمام نوڈس کے ذریعہ انجام دیا جانا چاہئے۔ نیٹ ورک کو غیر مرکزی رکھنے کے لیے ٹرانزیکشن تھروپٹ پر ایک حد عائد کرتے ہوئے، نوڈس کو معمولی ہارڈویئر کا استعمال کرتے ہوئے ایک بلاک میں لین دین کے حجم کو سنبھالنے کے قابل ہونا چاہیے۔ بلاک چین چینلز اس مسئلے کو صارفین کو آف چین بات چیت کرنے کی اجازت دے کر حل کرتے ہیں جبکہ حتمی تصفیہ کے لیے مرکزی سلسلہ کی حفاظت پر بھروسہ کرتے ہیں۔ + +چینلز سادہ پیر ٹو پیر پروٹوکول ہیں جو دو فریقوں کو اپنے درمیان بہت سے لین دین کرنے کی اجازت دیتے ہیں اور پھر صرف حتمی نتائج کو بلاک چین پر پوسٹ کرتے ہیں۔ چینل کرپٹوگرافی کا استعمال یہ ظاہر کرنے کے لیے کرتا ہے کہ وہ جو خلاصہ ڈیٹا تیار کرتے ہیں وہ واقعی درمیانی لین دین کے ایک درست سیٹ کا نتیجہ ہے۔ ایک ["ملٹی سگ"](/developers/docs/smart-contracts/#multisig) اسمارٹ کنٹریکٹ اس بات کو یقینی بناتا ہے کہ لین دین پر صحیح فریقوں کے دستخط ہیں۔ + +چینلز کے ساتھ، ایتھیریم کی ایگزیکیوشن لیئر پر کمپیوٹیشن کو کم کرتے ہوئے، اسٹیٹ کی تبدیلیاں دلچسپی رکھنے والی جماعتوں کے ذریعے عمل میں لائی جاتی ہیں اور ان کی توثیق کی جاتی ہے۔ اس سے ایتھیریم پر بھیڑ کم ہوتی ہے اور صارفین کے لیے ٹرانزیکشن پروسیسنگ کی رفتار بھی بڑھ جاتی ہے۔ + +ہر چینل کا انتظام ایتھیریم پر چلنے والے [ملٹی سگ اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/#multisig) کے ذریعے کیا جاتا ہے۔ چینل کھولنے کے لیے، شرکاء چینل کنٹریکٹ کو آن چین تعینات کرتے ہیں اور اس میں فنڈز جمع کرتے ہیں۔ دونوں فریق اجتماعی طور پر چینل کی حالت کو شروع کرنے کے لیے اسٹیٹ اپ ڈیٹ پر دستخط کرتے ہیں، جس کے بعد وہ تیزی سے اور آزادانہ طور پر آف چین لین دین کر سکتے ہیں۔ + +چینل کو بند کرنے کے لیے، شرکاء چینل کی آخری متفقہ حالت کو آن چین جمع کراتے ہیں۔ اس کے بعد، اسمارٹ کنٹریکٹ چینل کی حتمی حالت میں ہر شریک کے بیلنس کے مطابق لاک فنڈز تقسیم کرتا ہے۔ + +پیئر ٹو پیئر چینلز ان حالات کے لیے خاص طور پر کارآمد ہیں جہاں کچھ پہلے سے طے شدہ شرکاء بغیر کسی ظاہری اوور ہیڈ کے اعلی تعدد کے ساتھ لین دین کرنا چاہتے ہیں۔ بلاک چین چینلز دو زمروں میں آتے ہیں: **ادائیگی چینلز** اور **اسٹیٹ چینلز**۔ + +## ادائیگی کے چینلز {#payment-channels} + +ادائیگی کے چینل کو بہترین طور پر "دو طرفہ لیجر" کے طور پر بیان کیا گیا ہے جسے اجتماعی طور پر دو صارفین برقرار رکھتے ہیں۔ لیجر کا ابتدائی بیلنس چینل کے افتتاحی مرحلے کے دوران آن چین کنٹریکٹ میں لاک کیے گئے ڈپازٹس کا مجموعہ ہے۔ ادائیگی چینل کی منتقلی فوری طور پر اور اصل بلاک چین کی شمولیت کے بغیر کی جا سکتی ہے، سوائے ابتدائی ایک بار آن چین تخلیق اور چینل کے آخر کار بند ہونے کے۔ + +لیجر کے بیلنس میں اپ ڈیٹس (یعنی، ادائیگی چینل کی حالت) کے لیے چینل میں تمام فریقین کی منظوری درکار ہوتی ہے۔ چینل کے تمام شرکاء کے دستخط شدہ چینل اپ ڈیٹ کو حتمی سمجھا جاتا ہے، بالکل ایتھیریم پر لین دین کی طرح۔ + +ادائیگی کے چینلز سب سے ابتدائی اسکیلنگ حلوں میں سے تھے جو سادہ صارف کے تعاملات (جیسے، ETH کی منتقلی، جوہری تبادلے، مائیکرو پیمنٹس) کی مہنگی آن چین سرگرمی کو کم کرنے کے لیے بنائے گئے تھے۔ چینل کے شرکاء ایک دوسرے کے درمیان لامحدود مقدار میں فوری، فیس کے بغیر لین دین کر سکتے ہیں جب تک کہ ان کی منتقلی کا خالص مجموعہ جمع شدہ ٹوکنز سے زیادہ نہ ہو۔ + +## اسٹیٹ چینلز {#state-channels} + +آف چین ادائیگیوں کی حمایت کرنے کے علاوہ، ادائیگی کے چینلز عام اسٹیٹ ٹرانزیشن منطق کو سنبھالنے کے لیے کارآمد ثابت نہیں ہوئے ہیں۔ اس مسئلے کو حل کرنے اور عام مقصد کے حساب کو اسکیل کرنے کے لیے چینلز کو کارآمد بنانے کے لیے اسٹیٹ چینلز بنائے گئے تھے۔ + +اسٹیٹ چینلز میں اب بھی ادائیگی چینلز کے ساتھ بہت کچھ مشترک ہے۔ مثال کے طور پر، صارفین کرپٹوگرافک طور پر دستخط شدہ پیغامات (ٹرانزیکشنز) کا تبادلہ کرکے تعامل کرتے ہیں، جس پر دوسرے چینل کے شرکاء کو بھی دستخط کرنا ضروری ہے۔ اگر مجوزہ اسٹیٹ اپ ڈیٹ پر تمام شرکاء کے دستخط نہیں ہیں، تو اسے غلط سمجھا جاتا ہے۔ + +تاہم، صارف کے بیلنس کو رکھنے کے علاوہ، چینل کنٹریکٹ کے اسٹوریج کی موجودہ حالت (یعنی، کنٹریکٹ متغیرات کی قدریں) کو بھی ٹریک کرتا ہے۔ + +یہ دو صارفین کے درمیان آف چین اسمارٹ کنٹریکٹ کو انجام دینا ممکن بناتا ہے۔ اس منظر نامے میں، اسمارٹ کنٹریکٹ کی اندرونی حالت میں اپ ڈیٹس کے لیے صرف ان ہم مرتبہ لوگوں کی منظوری درکار ہوتی ہے جنہوں نے چینل بنایا ہے۔ + +اگرچہ یہ پہلے بیان کردہ اسکیل ایبلٹی کے مسئلے کو حل کرتا ہے، لیکن اس کے سیکیورٹی کے لیے مضمرات ہیں۔ ایتھیریم پر، اسٹیٹ ٹرانزیشن کی درستگی نیٹ ورک کے اتفاق رائے پروٹوکول کے ذریعے نافذ کی جاتی ہے۔ یہ اسمارٹ کنٹریکٹ کی حالت میں غلط اپ ڈیٹ کی تجویز کرنا یا اسمارٹ کنٹریکٹ کے نفاذ کو تبدیل کرنا ناممکن بنا دیتا ہے۔ + +اسٹیٹ چینلز میں یکساں حفاظتی ضمانتیں نہیں ہیں۔ ایک حد تک، ایک اسٹیٹ چینل مین نیٹ کا ایک چھوٹا ورژن ہے۔ قواعد کو نافذ کرنے والے شرکاء کے ایک محدود سیٹ کے ساتھ، بدنیتی پر مبنی رویے کا امکان (مثلاً، غلط اسٹیٹ اپ ڈیٹس کی تجویز) بڑھ جاتا ہے۔ اسٹیٹ چینلز اپنی سیکیورٹی [فراڈ پروفس](/glossary/#fraud-proof) پر مبنی تنازعہ ثالثی کے نظام سے حاصل کرتے ہیں۔ + +## اسٹیٹ چینلز کیسے کام کرتے ہیں {#how-state-channels-work} + +بنیادی طور پر، اسٹیٹ چینل میں سرگرمی صارفین اور بلاک چین سسٹم پر مشتمل تعاملات کا ایک سیشن ہے۔ صارفین زیادہ تر ایک دوسرے کے ساتھ آف چین بات چیت کرتے ہیں اور چینل کو کھولنے، چینل کو بند کرنے، یا شرکاء کے درمیان ممکنہ تنازعات کو طے کرنے کے لیے صرف بنیادی بلاک چین کے ساتھ تعامل کرتے ہیں۔ + +مندرجہ ذیل سیکشن اسٹیٹ چینل کے بنیادی ورک فلو کا خاکہ پیش کرتا ہے: + +### چینل کھولنا {#opening-the-channel} + +چینل کھولنے کے لیے شرکاء کو مین نیٹ پر ایک اسمارٹ کنٹریکٹ کے لیے فنڈز کا عہد کرنا پڑتا ہے۔ ڈپازٹ ایک ورچوئل ٹیب کے طور پر بھی کام کرتا ہے، لہذا حصہ لینے والے اداکار فوری طور پر ادائیگیوں کو طے کرنے کی ضرورت کے بغیر آزادانہ طور پر لین دین کر سکتے ہیں۔ جب چینل آن چین کو حتمی شکل دے دی جاتی ہے تب ہی فریقین ایک دوسرے کو طے کرتے ہیں اور اپنے ٹیب میں جو کچھ بچا ہے اسے واپس لے لیتے ہیں۔ + +یہ ڈپازٹ ہر شریک سے ایماندارانہ رویے کی ضمانت کے لیے ایک بانڈ کے طور پر بھی کام کرتا ہے۔ اگر تنازعہ کے حل کے مرحلے کے دوران جمع کرنے والے بدنیتی پر مبنی کارروائیوں کے مرتکب پائے جاتے ہیں، تو معاہدہ ان کے جمع کو کم کر دیتا ہے۔ + +چینل کے پیئرس کو ابتدائی اسٹیٹ پر دستخط کرنا ہوں گے، جس پر وہ سب متفق ہیں۔ یہ اسٹیٹ چینل کی ابتداء کے طور پر کام کرتا ہے، جس کے بعد صارفین لین دین شروع کر سکتے ہیں۔ + +### چینل کا استعمال {#using-the-channel} + +چینل کی حالت کو شروع کرنے کے بعد، ساتھی لین دین پر دستخط کرکے اور منظوری کے لیے ایک دوسرے کو بھیج کر بات چیت کرتے ہیں۔ شرکاء ان لین دین کے ساتھ اسٹیٹ اپ ڈیٹس شروع کرتے ہیں اور دوسروں سے اسٹیٹ اپ ڈیٹس پر دستخط کرتے ہیں۔ ہر لین دین مندرجہ ذیل پر مشتمل ہے: + +- ایک **نونسی**، جو لین دین کے لیے ایک منفرد ID کے طور پر کام کرتا ہے اور ری پلے حملوں کو روکتا ہے۔ یہ اس ترتیب کی بھی نشاندہی کرتا ہے جس میں اسٹیٹ اپ ڈیٹس ہوئے ہیں (جو تنازعات کے حل کے لیے اہم ہے) + +- چینل کی پرانی حالت + +- چینل کی نئی حالت + +- وہ لین دین جو اسٹیٹ ٹرانزیشن کو متحرک کرتا ہے (جیسے، ایلس باب کو 5 ETH بھیجتی ہے) + +چینل میں اسٹیٹ اپ ڈیٹس کو آن چین نشر نہیں کیا جاتا ہے جیسا کہ عام طور پر اس وقت ہوتا ہے جب صارف مین نیٹ پر بات چیت کرتے ہیں، جو آن چین کے نقوش کو کم کرنے کے اسٹیٹ چینلز کے مقصد سے ہم آہنگ ہوتا ہے۔ جب تک شرکاء اسٹیٹ اپ ڈیٹس پر متفق ہیں، وہ ایتھیریم ٹرانزیکشن کی طرح حتمی ہیں۔ تنازعہ پیدا ہونے کی صورت میں شرکاء کو صرف مین نیٹ کے اتفاق رائے پر انحصار کرنے کی ضرورت ہے۔ + +### چینل کو بند کرنا {#closing-the-channel} + +اسٹیٹ چینل کو بند کرنے کے لیے چینل کی حتمی، متفقہ حالت آن چین اسمارٹ کنٹریکٹ میں جمع کروانے کی ضرورت ہوتی ہے۔ اسٹیٹ اپ ڈیٹ میں حوالہ کردہ تفصیلات میں ہر شریک کی چالوں کی تعداد اور منظور شدہ لین دین کی فہرست شامل ہے۔ + +یہ تصدیق کرنے کے بعد کہ اسٹیٹ اپ ڈیٹ درست ہے (یعنی، اس پر تمام فریقوں کے دستخط ہیں) اسمارٹ کنٹریکٹ چینل کو حتمی شکل دیتا ہے اور چینل کے نتائج کے مطابق لاک کیے گئے فنڈز تقسیم کرتا ہے۔ آف چین کی گئی ادائیگیوں کا اطلاق ایتھیریم کی حالت پر ہوتا ہے اور ہر شریک کو لاک فنڈز کا اپنا بقیہ حصہ ملتا ہے۔ + +اوپر بیان کیا گیا منظر نامہ اس بات کی نمائندگی کرتا ہے کہ خوش کن معاملے میں کیا ہوتا ہے۔ کبھی کبھی، صارفین کسی معاہدے تک پہنچنے اور چینل کو حتمی شکل دینے سے قاصر ہو سکتے ہیں (افسوسناک معاملہ)۔ صورتحال کے بارے میں مندرجہ ذیل میں سے کوئی بھی سچ ہو سکتا ہے: + +- شرکاء آف لائن ہو جاتے ہیں اور اسٹیٹ ٹرانزیشن تجویز کرنے میں ناکام رہتے ہیں۔ + +- شرکاء درست اسٹیٹ اپ ڈیٹس پر مشترکہ دستخط کرنے سے انکار کرتے ہیں۔ + +- شرکاء آن چین کنٹریکٹ میں پرانی اسٹیٹ اپ ڈیٹ کی تجویز دے کر چینل کو حتمی شکل دینے کی کوشش کرتے ہیں۔ + +- شرکاء دوسروں کو دستخط کرنے کے لیے غلط اسٹیٹ ٹرانزیشن تجویز کرتے ہیں۔ + +جب بھی کسی چینل میں حصہ لینے والے اداکاروں کے درمیان اتفاق رائے ٹوٹ جاتا ہے، تو آخری آپشن مین نیٹ کے اتفاق رائے پر انحصار کرنا ہوتا ہے تاکہ چینل کی حتمی، درست حالت کو نافذ کیا جا سکے۔ اس معاملے میں، اسٹیٹ چینل کو بند کرنے کے لیے آن چین تنازعات کو طے کرنے کی ضرورت ہے۔ + +### تنازعات کا تصفیہ {#settling-disputes} + +عام طور پر، ایک چینل میں فریقین پہلے سے چینل کو بند کرنے پر متفق ہوتے ہیں اور آخری اسٹیٹ ٹرانزیشن پر مشترکہ دستخط کرتے ہیں، جسے وہ اسمارٹ کنٹریکٹ میں جمع کراتے ہیں۔ ایک بار آن چین اپ ڈیٹ کی منظوری مل جانے کے بعد، آف چین اسمارٹ کنٹریکٹ کا عمل ختم ہو جاتا ہے اور شرکاء اپنے پیسے کے ساتھ چینل سے باہر نکل جاتے ہیں۔ + +تاہم، ایک فریق اسمارٹ کنٹریکٹ کے نفاذ کو ختم کرنے اور چینل کو حتمی شکل دینے کے لیے آن چین درخواست جمع کر سکتا ہے—اپنے ہم منصب کی منظوری کا انتظار کیے بغیر۔ اگر پہلے بیان کردہ اتفاق رائے کو توڑنے والی کوئی صورت حال پیش آتی ہے، تو کوئی بھی فریق چینل کو بند کرنے اور فنڈز کی تقسیم کے لیے آن چین کنٹریکٹ کو متحرک کر سکتا ہے۔ یہ **بے اعتمادی** فراہم کرتا ہے، اس بات کو یقینی بناتا ہے کہ ایماندار فریق کسی بھی وقت اپنے ڈپازٹس سے باہر نکل سکتے ہیں، چاہے دوسرے فریق کی کارروائیاں کچھ بھی ہوں۔ + +چینل سے باہر نکلنے پر کارروائی کرنے کے لیے، صارف کو درخواست کی آخری درست اسٹیٹ اپ ڈیٹ آن چین کنٹریکٹ میں جمع کرانی ہوگی۔ اگر یہ چیک آؤٹ ہو جاتا ہے (یعنی اس پر تمام فریقوں کے دستخط ہوتے ہیں)، تو فنڈز ان کے حق میں دوبارہ تقسیم کیے جاتے ہیں۔ + +تاہم، واحد صارف سے باہر نکلنے کی درخواستوں پر عمل درآمد میں تاخیر ہوتی ہے۔ اگر چینل کو ختم کرنے کی درخواست کو متفقہ طور پر منظور کر لیا گیا تھا، تو آن چین سے باہر نکلنے کا لین دین فوری طور پر انجام دیا جاتا ہے۔ + +دھوکہ دہی کی کارروائیوں کے امکان کی وجہ سے واحد صارف سے باہر نکلنے میں تاخیر ہوتی ہے۔ مثال کے طور پر، ایک چینل کا شریک ایتھیریم پر چینل کو حتمی شکل دینے کی کوشش کر سکتا ہے اور آن چین پرانی اسٹیٹ اپ ڈیٹ جمع کروا سکتا ہے۔ + +ایک جوابی اقدام کے طور پر، اسٹیٹ چینلز ایماندار صارفین کو چینل کی تازہ ترین، درست حالت کو آن چین جمع کر کے غلط اسٹیٹ اپ ڈیٹس کو چیلنج کرنے کی اجازت دیتے ہیں۔ اسٹیٹ چینلز کو اس طرح ڈیزائن کیا گیا ہے کہ نئے، متفقہ اسٹیٹ اپ ڈیٹس پرانے اسٹیٹ اپ ڈیٹس کو مات دیتے ہیں۔ + +ایک بار جب ایک ہم مرتبہ آن چین تنازعہ کے حل کے نظام کو متحرک کرتا ہے، تو دوسرے فریق کو ایک وقت کی حد کے اندر جواب دینا ہوتا ہے (جسے چیلنج ونڈو کہا جاتا ہے)۔ یہ صارفین کو ایگزٹ ٹرانزیکشن کو چیلنج کرنے کی اجازت دیتا ہے، خاص طور پر اگر دوسرا فریق باسی اپ ڈیٹ کا اطلاق کر رہا ہو۔ + +کچھ بھی ہو، چینل کے صارفین کے پاس ہمیشہ مضبوط حتمی ضمانتیں ہوتی ہیں: اگر ان کے قبضے میں اسٹیٹ ٹرانزیشن پر تمام اراکین کے دستخط ہوتے ہیں اور یہ سب سے حالیہ اپ ڈیٹ ہے، تو یہ ایک باقاعدہ آن چین ٹرانزیکشن کے ساتھ مساوی حتمیت کا ہے۔ انہیں اب بھی دوسرے فریق کو آن چین چیلنج کرنا ہے، لیکن صرف ممکنہ نتیجہ آخری درست حالت کو حتمی شکل دے رہا ہے، جسے وہ رکھتے ہیں۔ + +### اسٹیٹ چینلز ایتھیریم کے ساتھ کیسے تعامل کرتے ہیں؟ {#how-do-state-channels-interact-with-ethereum} + +اگرچہ وہ آف چین پروٹوکول کے طور پر موجود ہیں، اسٹیٹ چینلز کا ایک آن چین جزو ہے: چینل کھولتے وقت ایتھیریم پر تعینات اسمارٹ کنٹریکٹ۔ یہ معاہدہ چینل میں جمع کیے گئے اثاثوں کو کنٹرول کرتا ہے، اسٹیٹ اپ ڈیٹس کی تصدیق کرتا ہے، اور شرکاء کے درمیان تنازعات میں ثالثی کرتا ہے۔ + +اسٹیٹ چینلز [لیئر 2](/layer-2/) اسکیلنگ سلوشنز کے برعکس، مین نیٹ پر ٹرانزیکشن ڈیٹا یا اسٹیٹ کمٹمنٹس شائع نہیں کرتے ہیں۔ تاہم، وہ مین نیٹ سے زیادہ جڑے ہوئے ہیں، کہتے ہیں، [سائیڈ چینز](/developers/docs/scaling/sidechains/)، انہیں کسی حد تک محفوظ بناتے ہیں۔ + +اسٹیٹ چینلز مندرجہ ذیل کے لیے مرکزی ایتھیریم پروٹوکول پر انحصار کرتے ہیں: + +#### 1۔ زندگی {#liveness} + +چینل کھولتے وقت تعینات آن چین کنٹریکٹ چینل کی فعالیت کے لیے ذمہ دار ہے۔ اگر معاہدہ ایتھیریم پر چل رہا ہے، تو چینل ہمیشہ استعمال کے لیے دستیاب ہے۔ اس کے برعکس، ایک سائیڈ چین ہمیشہ ناکام ہو سکتا ہے، چاہے مین نیٹ کام کر رہا ہو، جس سے صارف کے فنڈز کو خطرہ لاحق ہو جاتا ہے۔ + +#### 2۔ سیکیورٹی {#security} + +ایک حد تک، اسٹیٹ چینلز سیکیورٹی فراہم کرنے اور صارفین کو بدنیتی پر مبنی ہم مرتبہ لوگوں سے بچانے کے لیے ایتھیریم پر انحصار کرتے ہیں۔ جیسا کہ بعد کے حصوں میں زیر بحث آیا، چینلز ایک فراڈ پروف میکانزم کا استعمال کرتے ہیں جو صارفین کو غلط یا باسی اپ ڈیٹ کے ساتھ چینل کو حتمی شکل دینے کی کوششوں کو چیلنج کرنے دیتا ہے۔ + +اس معاملے میں، ایماندار فریق چینل کی تازہ ترین درست حالت کو تصدیق کے لیے آن چین کنٹریکٹ کو فراڈ پروف کے طور پر فراہم کرتا ہے۔ فراڈ پروفس باہمی طور پر غیر اعتمادی فریقوں کو اس عمل میں اپنے فنڈز کو خطرے میں ڈالے بغیر آف چین لین دین کرنے کے قابل بناتے ہیں۔ + +#### 3۔ حتمیت {#finality} + +چینل کے صارفین کے ذریعے اجتماعی طور پر دستخط کیے گئے اسٹیٹ اپ ڈیٹس کو آن چین ٹرانزیکشنز کی طرح اچھا سمجھا جاتا ہے۔ پھر بھی، تمام ان چینل سرگرمی صرف اس وقت حقیقی حتمیت حاصل کرتی ہے جب چینل ایتھیریم پر بند ہو جاتا ہے۔ + +پرامید معاملے میں، دونوں فریق تعاون کر سکتے ہیں اور حتمی اسٹیٹ اپ ڈیٹ پر دستخط کر سکتے ہیں اور چینل کو بند کرنے کے لیے آن چین جمع کر سکتے ہیں، جس کے بعد فنڈز چینل کی حتمی حالت کے مطابق تقسیم کیے جاتے ہیں۔ مایوسی کے معاملے میں، جہاں کوئی آن چین پر غلط اسٹیٹ اپ ڈیٹ پوسٹ کرکے دھوکہ دینے کی کوشش کرتا ہے، ان کا لین دین اس وقت تک حتمی نہیں ہوتا جب تک کہ چیلنج ونڈو ختم نہ ہوجائے۔ + +## ورچوئل اسٹیٹ چینلز {#virtual-state-channels} + +اسٹیٹ چینل کا ایک سادہ نفاذ ایک نیا معاہدہ تعینات کرنا ہوگا جب دو صارف آف چین کسی ایپلیکیشن کو انجام دینا چاہتے ہیں۔ یہ نہ صرف ناقابل عمل ہے، بلکہ یہ اسٹیٹ چینلز کی لاگت کی تاثیر کو بھی رد کرتا ہے (آن چین ٹرانزیکشن کے اخراجات میں تیزی سے اضافہ ہو سکتا ہے)۔ + +اس مسئلے کو حل کرنے کے لیے، "ورچوئل چینلز" بنائے گئے۔ باقاعدہ چینلز کے برعکس جن کو کھولنے اور ختم کرنے کے لیے آن چین ٹرانزیکشنز کی ضرورت ہوتی ہے، ایک ورچوئل چینل کو مرکزی چین سے بات چیت کیے بغیر کھولا، عمل میں لایا اور حتمی شکل دی جا سکتی ہے۔ اس طریقہ کا استعمال کرتے ہوئے آف چین تنازعات کو طے کرنا بھی ممکن ہے۔ + +یہ نظام نام نہاد "لیجر چینلز" کے وجود پر انحصار کرتا ہے، جنہیں آن چین فنڈ کیا گیا ہے۔ دو فریقوں کے درمیان ورچوئل چینلز کو ایک موجودہ لیجر چینل کے اوپر بنایا جا سکتا ہے، جس میں لیجر چینل کا مالک (مالک) ایک ثالث کے طور پر کام کرتا ہے۔ + +ہر ورچوئل چینل میں صارفین ایک نئے کنٹریکٹ مثال کے ذریعے تعامل کرتے ہیں، جس میں لیجر چینل متعدد کنٹریکٹ مثالوں کو سپورٹ کرنے کے قابل ہوتا ہے۔ لیجر چینل کی حالت میں ایک سے زیادہ کنٹریکٹ اسٹوریج اسٹیٹ بھی ہوتا ہے، جو مختلف صارفین کے درمیان آف چین ایپلیکیشنز کے متوازی عمل درآمد کی اجازت دیتا ہے۔ + +باقاعدہ چینلز کی طرح، صارفین اسٹیٹ مشین کو آگے بڑھانے کے لیے اسٹیٹ اپ ڈیٹس کا تبادلہ کرتے ہیں۔ جب تک کہ کوئی تنازعہ پیدا نہ ہو، ثالث سے صرف چینل کو کھولتے یا ختم کرتے وقت رابطہ کیا جانا چاہیے۔ + +### ورچوئل ادائیگی کے چینلز {#virtual-payment-channels} + +ورچوئل ادائیگی کے چینلز ورچوئل اسٹیٹ چینلز کی طرح ہی کام کرتے ہیں: ایک ہی نیٹ ورک سے جڑے شرکاء آن چین پر نیا چینل کھولنے کی ضرورت کے بغیر پیغامات بھیج سکتے ہیں۔ ورچوئل ادائیگی کے چینلز میں، قدر کی منتقلی کو ایک یا زیادہ بیچوانوں کے ذریعے روٹ کیا جاتا ہے، اس ضمانت کے ساتھ کہ صرف مطلوبہ وصول کنندہ ہی منتقل شدہ فنڈز حاصل کر سکتا ہے۔ + +## اسٹیٹ چینلز کی ایپلی کیشنز {#applications-of-state-channels} + +### ادائیگیاں {#payments} + +ابتدائی بلاک چین چینلز سادہ پروٹوکول تھے جو دو شرکاء کو مین نیٹ پر زیادہ ٹرانزیکشن فیس ادا کیے بغیر آف چین تیز، کم فیس کی منتقلی کرنے کی اجازت دیتے تھے۔ آج، ادائیگی کے چینلز اب بھی ایتھر اور ٹوکن کے تبادلے اور جمع کے لیے ڈیزائن کردہ ایپلی کیشنز کے لیے کارآمد ہیں۔ + +چینل پر مبنی ادائیگیوں کے درج ذیل فوائد ہیں: + +1. **تھروپٹ**: فی چینل آف چین ٹرانزیکشنز کی مقدار ایتھیریم کے تھروپٹ سے غیر منسلک ہے، جو مختلف عوامل سے متاثر ہوتی ہے، خاص طور پر بلاک سائز اور بلاک ٹائم۔ آف چین ٹرانزیکشنز کو انجام دے کر، بلاک چین چینلز زیادہ تھروپٹ حاصل کر سکتے ہیں۔ + +2. **رازداری**: چونکہ چینلز آف چین موجود ہیں، شرکاء کے درمیان تعامل کی تفصیلات ایتھیریم کے عوامی بلاک چین پر درج نہیں ہیں۔ چینل کے صارفین کو صرف چینلز کو فنڈ دینے اور بند کرنے یا تنازعات کو طے کرنے کے وقت آن چین پر بات چیت کرنی پڑتی ہے۔ اس طرح، چینلز ان افراد کے لیے مفید ہیں جو زیادہ نجی لین دین چاہتے ہیں۔ + +3. **لیٹنسی**: چینل کے شرکاء کے درمیان کیے جانے والے آف چین لین دین کو فوری طور پر طے کیا جا سکتا ہے، اگر دونوں فریق تعاون کریں، تاخیر کو کم کریں۔ اس کے برعکس، مین نیٹ پر لین دین بھیجنے کے لیے نوڈس کے لین دین پر کارروائی کرنے، لین دین کے ساتھ ایک نیا بلاک تیار کرنے، اور اتفاق رائے تک پہنچنے کا انتظار کرنا پڑتا ہے۔ صارفین کو لین دین کو حتمی شکل دینے سے پہلے مزید بلاک تصدیق کا انتظار کرنے کی بھی ضرورت پڑسکتی ہے۔ + +4. **لاگت**: اسٹیٹ چینلز ان حالات میں خاص طور پر کارآمد ہیں جہاں شرکاء کا ایک مجموعہ طویل عرصے تک بہت سے اسٹیٹ اپ ڈیٹس کا تبادلہ کرے گا۔ صرف اسٹیٹ چینل اسمارٹ کنٹریکٹ کو کھولنے اور بند کرنے کے اخراجات ہیں؛ چینل کو کھولنے اور بند کرنے کے درمیان ہر اسٹیٹ کی تبدیلی آخری سے سستی ہوگی کیونکہ تصفیہ کی لاگت اسی کے مطابق تقسیم کی جاتی ہے۔ + +[رول اپس](/developers/docs/scaling/#rollups) جیسے لیئر 2 حل پر اسٹیٹ چینلز کو نافذ کرنا، انہیں ادائیگیوں کے لیے اور بھی زیادہ پرکشش بنا سکتا ہے۔ جبکہ چینلز سستی ادائیگیاں پیش کرتے ہیں، افتتاحی مرحلے کے دوران مین نیٹ پر آن چین کنٹریکٹ قائم کرنے کے اخراجات مہنگے ہو سکتے ہیں—خاص طور پر جب گیس کی فیسیں بڑھ جاتی ہیں۔ ایتھیریم پر مبنی رول اپس [کم ٹرانزیکشن فیس](https://l2fees.info/) پیش کرتے ہیں اور سیٹ اپ فیس کو کم کرکے چینل کے شرکاء کے لیے اوور ہیڈ کو کم کرسکتے ہیں۔ + +### مائیکرو ٹرانزیکشنز {#microtransactions} + +مائیکرو ٹرانزیکشنز کم قیمت والی ادائیگیاں ہیں (مثلاً، ڈالر کے ایک حصے سے کم) جن پر کاروبار بغیر نقصان اٹھائے کارروائی نہیں کر سکتے۔ ان اداروں کو ادائیگی کی خدمات فراہم کرنے والوں کو ادائیگی کرنی ہوگی، جو وہ نہیں کر سکتے اگر کسٹمر کی ادائیگیوں پر مارجن منافع کمانے کے لیے بہت کم ہو۔ + +ادائیگی کے چینلز مائیکرو ٹرانزیکشنز سے وابستہ اوور ہیڈ کو کم کرکے اس مسئلے کو حل کرتے ہیں۔ مثال کے طور پر، ایک انٹرنیٹ سروس فراہم کنندہ (ISP) ایک صارف کے ساتھ ادائیگی کا چینل کھول سکتا ہے، جس سے وہ ہر بار سروس استعمال کرنے پر چھوٹی چھوٹی ادائیگیاں کر سکتے ہیں۔ + +چینل کو کھولنے اور بند کرنے کی لاگت سے ہٹ کر، شرکاء مائیکرو ٹرانزیکشنز پر مزید اخراجات برداشت نہیں کرتے (کوئی گیس فیس نہیں)۔ یہ ایک جیت کی صورت حال ہے کیونکہ صارفین کو خدمات کے لیے کتنا ادائیگی کرنا ہے اس میں زیادہ لچک ہوتی ہے اور کاروبار منافع بخش مائیکرو ٹرانزیکشنز سے محروم نہیں ہوتے ہیں۔ + +### غیر مرکزی ایپلی کیشنز {#decentralized-applications} + +ادائیگی چینلز کی طرح، اسٹیٹ چینلز اسٹیٹ مشین کی حتمی حالتوں کے مطابق مشروط ادائیگیاں کر سکتے ہیں۔ اسٹیٹ چینلز من مانی اسٹیٹ ٹرانزیشن منطق کی بھی حمایت کر سکتے ہیں، جو انہیں عام ایپس کو آف چین پر عمل درآمد کے لیے مفید بناتا ہے۔ + +اسٹیٹ چینلز اکثر سادہ باری پر مبنی ایپلی کیشنز تک محدود ہوتے ہیں، کیونکہ اس سے آن چین کنٹریکٹ کے لیے প্রতিশ্রুতিবদ্ধ فنڈز کا انتظام کرنا آسان ہو جاتا ہے۔ اس کے علاوہ، وقفوں پر آف چین ایپلیکیشن کی حالت کو اپ ڈیٹ کرنے والی فریقوں کی ایک محدود تعداد کے ساتھ، بے ایمان رویے کی سزا دینا نسبتاً سیدھا ہے۔ + +اسٹیٹ چینل ایپلیکیشن کی کارکردگی بھی اس کے ڈیزائن پر منحصر ہے۔ مثال کے طور پر، ایک ڈیولپر ایپ چینل کنٹریکٹ کو ایک بار آن چین پر تعینات کر سکتا ہے اور دوسرے کھلاڑیوں کو آن چین جانے کی ضرورت کے بغیر ایپ کو دوبارہ استعمال کرنے کی اجازت دے سکتا ہے۔ اس معاملے میں، ابتدائی ایپ چینل ایک لیجر چینل کے طور پر کام کرتا ہے جو متعدد ورچوئل چینلز کو سپورٹ کرتا ہے، ہر ایک ایپ کے اسمارٹ کنٹریکٹ کا ایک نیا مثال آف چین چلاتا ہے۔ + +اسٹیٹ چینل ایپلی کیشنز کے لیے ایک ممکنہ استعمال کا معاملہ سادہ دو کھلاڑیوں کے کھیل ہیں، جہاں فنڈز کھیل کے نتائج کی بنیاد پر تقسیم کیے جاتے ہیں۔ یہاں فائدہ یہ ہے کہ کھلاڑیوں کو ایک دوسرے پر بھروسہ کرنے کی ضرورت نہیں ہے (بے اعتمادی) اور آن چین کنٹریکٹ، کھلاڑی نہیں، فنڈز کی تقسیم اور تنازعات کے تصفیے کو کنٹرول کرتا ہے (غیر مرکزیت)۔ + +اسٹیٹ چینل ایپس کے لیے دیگر ممکنہ استعمال کے معاملات میں ENS نام کی ملکیت، NFT لیجرز، اور بہت کچھ شامل ہے۔ + +### جوہری منتقلی {#atomic-transfers} + +ابتدائی ادائیگی کے چینلز دو فریقوں کے درمیان منتقلی تک محدود تھے، جس سے ان کے استعمال میں محدودیت تھی۔ تاہم، ورچوئل چینلز کے تعارف نے افراد کو بیچوانوں (یعنی، متعدد p2p چینلز) کے ذریعے منتقلی کو روٹ کرنے کی اجازت دی بغیر آن چین پر نیا چینل کھولنے کی ضرورت کے۔ + +عام طور پر "ملٹی ہاپ ٹرانسفر" کے طور پر بیان کیا جاتا ہے، روٹ کی گئی ادائیگیاں جوہری ہیں (یعنی، یا تو لین دین کے تمام حصے کامیاب ہوتے ہیں یا یہ مکمل طور پر ناکام ہو جاتا ہے)۔ اٹامک ٹرانسفرز [ہیشڈ ٹائم لاک کنٹریکٹس (HTLCs)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) کا استعمال کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ ادائیگی صرف اس صورت میں جاری کی جائے جب کچھ شرائط پوری ہوں، اس طرح فریق مخالف کا خطرہ کم ہو جاتا ہے۔ + +## اسٹیٹ چینلز کے استعمال کے نقصانات {#drawbacks-of-state-channels} + +### زندگی کے مفروضے {#liveness-assumptions} + +کارکردگی کو یقینی بنانے کے لیے، اسٹیٹ چینلز چینل کے شرکاء کی تنازعات کا جواب دینے کی صلاحیت پر وقت کی حدیں لگاتے ہیں۔ یہ اصول فرض کرتا ہے کہ ساتھی چینل کی سرگرمی کی نگرانی کرنے اور ضرورت پڑنے پر چیلنجوں کا مقابلہ کرنے کے لیے ہمیشہ آن لائن رہیں گے۔ + +حقیقت میں، صارفین اپنے کنٹرول سے باہر وجوہات کی بناء پر آف لائن ہو سکتے ہیں (مثلاً، خراب انٹرنیٹ کنکشن، مکینیکل ناکامی، وغیرہ)۔ اگر کوئی ایماندار صارف آف لائن ہو جاتا ہے، تو ایک بدنیتی پر مبنی ہم مرتبہ فیصلہ کرنے والے معاہدے میں پرانی درمیانی حالتیں پیش کرکے اور প্রতিশ্রুতিবদ্ধ فنڈز چوری کرکے صورتحال کا فائدہ اٹھا سکتا ہے۔ + +کچھ چینلز "واچ ٹاورز" کا استعمال کرتے ہیں— جو دوسروں کی جانب سے آن چین تنازعہ کے واقعات کو دیکھنے اور ضروری کارروائیاں کرنے کے لیے ذمہ دار ہیں، جیسے متعلقہ فریقوں کو آگاہ کرنا۔ تاہم، یہ اسٹیٹ چینل کے استعمال کی لاگت میں اضافہ کر سکتا ہے۔ + +### ڈیٹا کی عدم دستیابی {#data-unavailability} + +جیسا کہ پہلے وضاحت کی گئی ہے، ایک غلط تنازعہ کو چیلنج کرنے کے لیے اسٹیٹ چینل کی تازہ ترین، درست حالت پیش کرنے کی ضرورت ہے۔ یہ ایک مفروضے پر مبنی ایک اور اصول ہے—کہ صارفین کو چینل کی تازہ ترین حالت تک رسائی حاصل ہے۔ + +اگرچہ چینل کے صارفین سے آف چین ایپلیکیشن اسٹیٹ کی کاپیاں ذخیرہ کرنے کی توقع کرنا معقول ہے، لیکن یہ ڈیٹا غلطی یا مکینیکل ناکامی کی وجہ سے ضائع ہو سکتا ہے۔ اگر صارف کے پاس ڈیٹا کا بیک اپ نہیں ہے، تو وہ صرف یہ امید کر سکتے ہیں کہ دوسرا فریق اپنے قبضے میں پرانی اسٹیٹ ٹرانزیشن کا استعمال کرتے ہوئے غلط ایگزٹ کی درخواست کو حتمی شکل نہ دے۔ + +ایتھیریم صارفین کو اس مسئلے سے نمٹنے کی ضرورت نہیں ہے کیونکہ نیٹ ورک ڈیٹا کی دستیابی پر قواعد نافذ کرتا ہے۔ ٹرانزیکشن ڈیٹا تمام نوڈس کے ذریعہ ذخیرہ اور پھیلایا جاتا ہے اور ضرورت پڑنے پر صارفین کو ڈاؤن لوڈ کرنے کے لیے دستیاب ہوتا ہے۔ + +### لیکویڈیٹی کے مسائل {#liquidity-issues} + +بلاک چین چینل قائم کرنے کے لیے، شرکاء کو چینل کی زندگی کے لیے آن چین اسمارٹ کنٹریکٹ میں فنڈز لاک کرنے کی ضرورت ہے۔ یہ چینل کے صارفین کی لیکویڈیٹی کو کم کرتا ہے اور چینلز کو ان لوگوں تک محدود کرتا ہے جو مین نیٹ پر فنڈز کو لاک رکھنے کے متحمل ہو سکتے ہیں۔ + +تاہم، لیجر چینلز—جو آف چین سروس فراہم کنندہ (OSP) کے ذریعے چلائے جاتے ہیں—صارفین کے لیے لیکویڈیٹی کے مسائل کو کم کر سکتے ہیں۔ لیجر چینل سے جڑے دو ساتھی ایک ورچوئل چینل بنا سکتے ہیں، جسے وہ جب چاہیں مکمل طور پر آف چین کھول سکتے ہیں اور حتمی شکل دے سکتے ہیں۔ + +آف چین سروس فراہم کنندگان متعدد ہم مرتبہ لوگوں کے ساتھ چینلز بھی کھول سکتے ہیں، جو انہیں ادائیگیوں کی روٹنگ کے لیے مفید بناتا ہے۔ یقیناً، صارفین کو OSPs کو ان کی خدمات کے لیے فیس ادا کرنی ہوگی، جو کچھ کے لیے ناپسندیدہ ہو سکتی ہے۔ + +### غمناک حملے {#griefing-attacks} + +غمناک حملے فراڈ پروف پر مبنی نظاموں کی ایک عام خصوصیت ہیں۔ غمناک حملہ براہ راست حملہ آور کو فائدہ نہیں پہنچاتا بلکہ متاثرہ کو غم (یعنی نقصان) پہنچاتا ہے، اس لیے یہ نام ہے۔ + +دھوکہ دہی کا ثبوت غمگین حملوں کا شکار ہے کیونکہ ایماندار فریق کو ہر تنازعہ کا جواب دینا چاہیے، یہاں تک کہ غلط بھی، ورنہ ان کے فنڈز کھونے کا خطرہ ہے۔ ایک بدنیتی پر مبنی شریک بار بار آن چین پر باسی اسٹیٹ ٹرانزیشن پوسٹ کرنے کا فیصلہ کر سکتا ہے، جس سے ایماندار فریق کو درست حالت کے ساتھ جواب دینے پر مجبور کیا جا سکتا ہے۔ ان آن چین ٹرانزیکشنز کی لاگت تیزی سے بڑھ سکتی ہے، جس سے ایماندار فریقوں کو اس عمل میں نقصان اٹھانا پڑتا ہے۔ + +### پہلے سے طے شدہ شریک سیٹ {#predefined-participant-sets} + +ڈیزائن کے لحاظ سے، ایک اسٹیٹ چینل پر مشتمل شرکاء کی تعداد اس کی پوری زندگی میں مقرر رہتی ہے۔ اس کی وجہ یہ ہے کہ شریک سیٹ کو اپ ڈیٹ کرنے سے چینل کا آپریشن پیچیدہ ہو جائے گا، خاص طور پر چینل کو فنڈ دیتے وقت، یا تنازعات کو طے کرتے وقت۔ شرکاء کو شامل کرنے یا ہٹانے کے لیے اضافی آن چین سرگرمی کی بھی ضرورت ہوگی، جس سے صارفین کے لیے اوور ہیڈ بڑھ جاتا ہے۔ + +جبکہ یہ اسٹیٹ چینلز کے بارے میں استدلال کرنا آسان بناتا ہے، یہ ایپلیکیشن ڈویلپرز کے لیے چینل ڈیزائن کی افادیت کو محدود کرتا ہے۔ یہ جزوی طور پر وضاحت کرتا ہے کہ رول اپس جیسے دیگر اسکیلنگ حلوں کے حق میں اسٹیٹ چینلز کو کیوں چھوڑ دیا گیا ہے۔ + +### متوازی ٹرانزیکشن پروسیسنگ {#parallel-transaction-processing} + +اسٹیٹ چینل میں شرکاء باری باری اسٹیٹ اپ ڈیٹس بھیجتے ہیں، یہی وجہ ہے کہ وہ "باری پر مبنی ایپلی کیشنز" (جیسے، دو کھلاڑیوں کا شطرنج کا کھیل) کے لیے بہترین کام کرتے ہیں۔ یہ بیک وقت اسٹیٹ اپ ڈیٹس کو ہینڈل کرنے کی ضرورت کو ختم کرتا ہے اور اس کام کو کم کرتا ہے جو آن چین کنٹریکٹ کو باسی اپ ڈیٹ پوسٹروں کو سزا دینے کے لیے کرنا چاہیے۔ تاہم، اس ڈیزائن کا ایک ضمنی اثر یہ ہے کہ لین دین ایک دوسرے پر منحصر ہیں، جس سے تاخیر میں اضافہ ہوتا ہے اور صارف کے مجموعی تجربے کو کم کیا جاتا ہے۔ + +کچھ اسٹیٹ چینلز اس مسئلے کو "فل ڈوپلیکس" ڈیزائن کا استعمال کرکے حل کرتے ہیں جو آف چین اسٹیٹ کو دو یک طرفہ "سمپلیکس" حالتوں میں الگ کرتا ہے، جس سے ہم آہنگ اسٹیٹ اپ ڈیٹس کی اجازت ملتی ہے۔ ایسے ڈیزائن آف چین تھروپٹ کو بہتر بناتے ہیں اور لین دین میں تاخیر کو کم کرتے ہیں۔ + +## اسٹیٹ چینلز کا استعمال کریں {#use-state-channels} + +متعدد پروجیکٹس اسٹیٹ چینلز کے نفاذ فراہم کرتے ہیں جنہیں آپ اپنے ڈیپس میں ضم کر سکتے ہیں: + +- [Connext](https://connext.network/) +- [Kchannels](https://www.kchannels.io/) +- [Perun](https://perun.network/) +- [Raiden](https://raiden.network/) +- [Statechannels.org](https://statechannels.org/) + +## مزید پڑھیں {#further-reading} + +**اسٹیٹ چینلز** + +- [ایتھیریم کے لیئر 2 اسکیلنگ سلوشنز کو سمجھنا: اسٹیٹ چینلز، پلازما، اور ٹروبٹ](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark, Feb 12 2018_ +- [اسٹیٹ چینلز - ایک وضاحت](https://www.jeffcoleman.ca/state-channels/) _Nov 6, 2015 - Jeff Coleman_ +- [اسٹیٹ چینلز کی بنیادی باتیں](https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/) _District0x_ +- [بلاک چین اسٹیٹ چینلز: ایک اسٹیٹ آف دی آرٹ](https://ieeexplore.ieee.org/document/9627997) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/scaling/validium/index.md b/public/content/translations/ur/developers/docs/scaling/validium/index.md new file mode 100644 index 00000000000..e3a7b78bd37 --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/validium/index.md @@ -0,0 +1,166 @@ +--- +title: "ویلیڈیم" +description: "ایتھریم کمیونٹی کے ذریعے فی الحال استعمال کیے جانے والے اسکیلنگ سلوشن کے طور پر ویلیڈیم کا تعارف۔" +lang: ur-in +sidebarDepth: 3 +--- + +ویلیڈیم ایک [اسکیلنگ سلوشن](/developers/docs/scaling/) ہے جو [ZK-رول اپس](/developers/docs/scaling/zk-rollups/) کی طرح توثیقی ثبوتوں کا استعمال کرتے ہوئے ٹرانزیکشنز کی سالمیت کو نافذ کرتا ہے، لیکن ٹرانزیکشن ڈیٹا کو ایتھریم مین نیٹ پر اسٹور نہیں کرتا ہے۔ جبکہ آف چین ڈیٹا کی دستیابی کچھ سمجھوتے متعارف کراتی ہے، یہ اسکیل ایبلیٹی میں بڑی بہتری کا باعث بن سکتی ہے (ویلیڈیمز [~9,000 ٹرانزیکشنز، یا اس سے زیادہ، فی سیکنڈ](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) پروسیس کر سکتے ہیں)۔ + +## شرائط {#prerequisites} + +آپ کو [ایتھریم اسکیلنگ](/developers/docs/scaling/) اور [لئیر 2](/layer-2) پر ہمارا صفحہ پڑھا اور سمجھا ہوا ہونا چاہیے۔ + +## ویلیڈیم کیا ہے؟ {#what-is-validium} + +ویلیڈیمز اسکیلنگ سلوشنز ہیں جو آف چین ڈیٹا کی دستیابی اور کمپیوٹیشن کا استعمال کرتے ہیں جو ایتھریم مین نیٹ سے باہر ٹرانزیکشنز پروسیس کرکے تھرو پٹ کو بہتر بنانے کے لیے ڈیزائن کیے گئے ہیں۔ زیرو نالج رول اپس (ZK-رول اپس) کی طرح، ویلیڈیمز ایتھریم پر آف چین ٹرانزیکشنز کی تصدیق کے لیے [زیرو نالج پروفس](/glossary/#zk-proof) شائع کرتے ہیں۔ یہ غلط اسٹیٹ ٹرانزیشنز کو روکتا ہے اور ویلیڈیم چین کی سیکیورٹی گارنٹی کو بڑھاتا ہے۔ + +یہ "توثیقی ثبوت" ZK-SNARKs (زیرو-نالج سکسنکٹ نان-انٹرایکٹو آرگومنٹ آف نالج) یا ZK-STARKs (زیرو-نالج اسکیل ایبل ٹرانسپیرنٹ آرگومنٹ آف نالج) کی شکل میں آ سکتے ہیں۔ [زیرو نالج پروفس](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) پر مزید۔ + +ویلیڈیم صارفین کے فنڈز ایتھریم پر ایک اسمارٹ کنٹریکٹ کے ذریعے کنٹرول کیے جاتے ہیں۔ ویلیڈیمز تقریباً فوری طور پر فنڈز نکالنے کی سہولت فراہم کرتے ہیں، بالکل اسی طرح جیسے ZK-رول اپس کرتے ہیں؛ ایک بار جب مین نیٹ پر فنڈز نکالنے کی درخواست کے لیے توثیقی ثبوت کی تصدیق ہو جاتی ہے، تو صارفین [مرکل پروفس](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) فراہم کرکے فنڈز نکال سکتے ہیں۔ مرکل پروف ایک تصدیق شدہ ٹرانزیکشن بیچ میں صارف کے فنڈز نکالنے کے ٹرانزیکشن کی شمولیت کی توثیق کرتا ہے، جس سے آن چین کنٹریکٹ کو فنڈز نکالنے کی کارروائی کرنے کی اجازت ملتی ہے۔ + +تاہم، ویلیڈیم صارفین کے فنڈز منجمد کیے جا سکتے ہیں اور فنڈز نکالنے پر پابندی لگائی جا سکتی ہے۔ ایسا ہو سکتا ہے اگر ویلیڈیم چین پر ڈیٹا کی دستیابی کے مینیجرز صارفین سے آف چین اسٹیٹ ڈیٹا روک لیں۔ ٹرانزیکشن ڈیٹا تک رسائی کے بغیر، صارفین فنڈز کی ملکیت ثابت کرنے اور فنڈز نکالنے کے لیے درکار مرکل پروف کا حساب نہیں لگا سکتے۔ + +یہ ویلیڈیمز اور ZK-رول اپس کے درمیان بڑا فرق ہے—ڈیٹا کی دستیابی کے اسپیکٹرم پر ان کی پوزیشن۔ دونوں سلوشنز ڈیٹا اسٹوریج کو مختلف طریقے سے دیکھتے ہیں، جس کے سیکیورٹی اور ٹرسلیس نیس پر اثرات مرتب ہوتے ہیں۔ + +## ویلیڈیمز ایتھریم کے ساتھ کیسے تعامل کرتے ہیں؟ {#how-do-validiums-interact-with-ethereum} + +ویلیڈیمز موجودہ ایتھریم چین کے اوپر بنائے گئے اسکیلنگ پروٹوکولز ہیں۔ اگرچہ یہ آف چین ٹرانزیکشنز کو انجام دیتا ہے، ایک ویلیڈیم چین کو مین نیٹ پر تعینات اسمارٹ کنٹریکٹس کے ایک مجموعے کے ذریعے منظم کیا جاتا ہے جس میں شامل ہیں: + +1. **تصدیق کنندہ کنٹریکٹ**: تصدیق کنندہ کنٹریکٹ اسٹیٹ اپ ڈیٹس کرتے وقت ویلیڈیم آپریٹر کے ذریعے جمع کرائے گئے ثبوتوں کی توثیق کرتا ہے۔ اس میں آف چین ٹرانزیکشنز کی درستگی کی تصدیق کرنے والے توثیقی ثبوت اور آف چین ٹرانزیکشن ڈیٹا کے وجود کی تصدیق کرنے والے ڈیٹا کی دستیابی کے ثبوت شامل ہیں۔ + +2. **مرکزی کنٹریکٹ**: مرکزی کنٹریکٹ بلاک پروڈیوسرز کے ذریعے جمع کرائے گئے اسٹیٹ کمٹمنٹس (مرکل روٹس) کو اسٹور کرتا ہے اور ایک بار جب آن چین توثیقی ثبوت کی تصدیق ہو جاتی ہے تو ویلیڈیم کے اسٹیٹ کو اپ ڈیٹ کرتا ہے۔ یہ کنٹریکٹ ویلیڈیم چین میں ڈپازٹس اور نکاسی کی کارروائی بھی کرتا ہے۔ + +ویلیڈیمز مندرجہ ذیل کے لیے مرکزی ایتھریم چین پر بھی انحصار کرتے ہیں: + +### سیٹلمنٹ {#settlement} + +ویلیڈیم پر کیے گئے ٹرانزیکشنز کی مکمل طور پر تصدیق اس وقت تک نہیں کی جا سکتی جب تک کہ پیرنٹ چین ان کی توثیق نہ کر لے۔ ویلیڈیم پر کیے گئے تمام کاروبار کو بالآخر مین نیٹ پر سیٹل کرنا ضروری ہے۔ ایتھریم بلاک چین ویلیڈیم صارفین کے لیے "سیٹلمنٹ گارنٹی" بھی فراہم کرتا ہے، جس کا مطلب ہے کہ ایک بار آن چین کمٹ ہوجانے کے بعد آف چین ٹرانزیکشنز کو ریورس یا تبدیل نہیں کیا جاسکتا۔ + +### سیکیورٹی {#security} + +ایتھریم، ایک سیٹلمنٹ لئیر کے طور پر کام کرتے ہوئے، ویلیڈیم پر اسٹیٹ ٹرانزیشنز کی توثیق کی بھی ضمانت دیتا ہے۔ ویلیڈیم چین پر انجام دیئے گئے آف چین ٹرانزیکشنز کی تصدیق بیس ایتھریم لئیر پر ایک اسمارٹ کنٹریکٹ کے ذریعے کی جاتی ہے۔ + +اگر آن چین تصدیق کنندہ کنٹریکٹ ثبوت کو غلط سمجھتا ہے، تو ٹرانزیکشنز کو مسترد کر دیا جاتا ہے۔ اس کا مطلب ہے کہ آپریٹرز کو ویلیڈیم کے اسٹیٹ کو اپ ڈیٹ کرنے سے پہلے ایتھریم پروٹوکول کے ذریعے نافذ کردہ توثیقی شرائط کو پورا کرنا ہوگا۔ + +## ویلیڈیم کیسے کام کرتا ہے؟ {#how-does-validium-work} + +### ٹرانزیکشنز {#transactions} + +صارفین آپریٹر کو ٹرانزیکشنز جمع کراتے ہیں، جو ویلیڈیم چین پر ٹرانزیکشنز کو انجام دینے کے لیے ذمہ دار ایک نوڈ ہے۔ کچھ ویلیڈیمز چین کو چلانے کے لیے ایک واحد آپریٹر کا استعمال کر سکتے ہیں یا آپریٹرز کو گھمانے کے لیے [پروف آف اسٹیک (PoS)](/developers/docs/consensus-mechanisms/pos/) میکانزم پر انحصار کر سکتے ہیں۔ + +آپریٹر ٹرانزیکشنز کو ایک بیچ میں جمع کرتا ہے اور اسے ثابت کرنے کے لیے ایک پروونگ سرکٹ میں بھیجتا ہے۔ پروونگ سرکٹ ٹرانزیکشن بیچ (اور دیگر متعلقہ ڈیٹا) کو ان پٹ کے طور پر قبول کرتا ہے اور ایک توثیقی ثبوت آؤٹ پٹ کرتا ہے جو اس بات کی تصدیق کرتا ہے کہ آپریشنز صحیح طریقے سے انجام دیے گئے تھے۔ + +### اسٹیٹ کمٹمنٹس {#state-commitments} + +ویلیڈیم کے اسٹیٹ کو مرکل ٹری کے طور پر ہیش کیا جاتا ہے جس کا روٹ ایتھریم پر مرکزی کنٹریکٹ میں اسٹور ہوتا ہے۔ مرکل روٹ، جسے اسٹیٹ روٹ بھی کہا جاتا ہے، ویلیڈیم پر اکاؤنٹس اور بیلنس کے موجودہ اسٹیٹ کے لیے ایک کرپٹوگرافک کمٹمنٹ کے طور پر کام کرتا ہے۔ + +اسٹیٹ اپ ڈیٹ کرنے کے لیے، آپریٹر کو ایک نیا اسٹیٹ روٹ (ٹرانزیکشنز انجام دینے کے بعد) کا حساب لگانا ہوگا اور اسے آن چین کنٹریکٹ میں جمع کرنا ہوگا۔ اگر توثیقی ثبوت درست پایا جاتا ہے، تو مجوزہ اسٹیٹ قبول کر لیا جاتا ہے اور ویلیڈیم نئے اسٹیٹ روٹ پر سوئچ ہو جاتا ہے۔ + +### ڈپازٹس اور نکاسی {#deposits-and-withdrawals} + +صارفین آن چین کنٹریکٹ میں ETH (یا کوئی بھی ERC-کمپیٹیبل ٹوکن) جمع کرکے ایتھریم سے ویلیڈیم میں فنڈز منتقل کرتے ہیں۔ کنٹریکٹ ڈپازٹ ایونٹ کو ویلیڈیم آف چین میں ریلے کرتا ہے، جہاں صارف کے ایڈریس میں ان کے ڈپازٹ کے برابر رقم کریڈٹ کی جاتی ہے۔ آپریٹر اس ڈپازٹ ٹرانزیکشن کو ایک نئے بیچ میں بھی شامل کرتا ہے۔ + +فنڈز کو واپس مین نیٹ میں منتقل کرنے کے لیے، ایک ویلیڈیم صارف نکاسی کا ٹرانزیکشن شروع کرتا ہے اور اسے آپریٹر کو جمع کرتا ہے جو نکاسی کی درخواست کی توثیق کرتا ہے اور اسے ایک بیچ میں شامل کرتا ہے۔ صارف کے اثاثے ویلیڈیم چین پر بھی تباہ کر دیے جاتے ہیں اس سے پہلے کہ وہ سسٹم سے باہر نکل سکیں۔ ایک بار جب بیچ سے وابستہ توثیقی ثبوت کی تصدیق ہو جاتی ہے، تو صارف اپنے ابتدائی ڈپازٹ کی بقیہ رقم نکالنے کے لیے مرکزی کنٹریکٹ کو کال کر سکتا ہے۔ + +ایک اینٹی سینسرشپ میکانزم کے طور پر، ویلیڈیم پروٹوکول صارفین کو آپریٹر کے ذریعے جائے بغیر براہ راست ویلیڈیم کنٹریکٹ سے فنڈز نکالنے کی اجازت دیتا ہے۔ اس معاملے میں، صارفین کو اسٹیٹ روٹ میں اکاؤنٹ کی شمولیت دکھانے کے لیے تصدیق کنندہ کنٹریکٹ کو ایک مرکل پروف فراہم کرنے کی ضرورت ہے۔ اگر ثبوت قبول کر لیا جاتا ہے، تو صارف ویلیڈیم سے اپنے فنڈز نکالنے کے لیے مرکزی کنٹریکٹ کے نکاسی فنکشن کو کال کر سکتا ہے۔ + +### بیچ کی جمع آوری {#batch-submission} + +ٹرانزیکشنز کے ایک بیچ کو انجام دینے کے بعد، آپریٹر متعلقہ توثیقی ثبوت کو تصدیق کنندہ کنٹریکٹ میں جمع کرتا ہے اور مرکزی کنٹریکٹ کو ایک نیا اسٹیٹ روٹ تجویز کرتا ہے۔ اگر ثبوت درست ہے، تو مرکزی کنٹریکٹ ویلیڈیم کے اسٹیٹ کو اپ ڈیٹ کرتا ہے اور بیچ میں ٹرانزیکشنز کے نتائج کو حتمی شکل دیتا ہے۔ + +ZK-رول اپ کے برعکس، ویلیڈیم پر بلاک پروڈیوسرز کو ٹرانزیکشن بیچز کے لیے ٹرانزیکشن ڈیٹا شائع کرنے کی ضرورت نہیں ہے (صرف بلاک ہیڈرز)۔ یہ ویلیڈیم کو خالصتاً آف چین اسکیلنگ پروٹوکول بناتا ہے، "ہائبرڈ" اسکیلنگ پروٹوکولز (یعنی، [لئیر 2](/layer-2/)) کے برعکس جو بلاب ڈیٹا، `calldata`، یا دونوں کے امتزاج کا استعمال کرتے ہوئے مرکزی ایتھریم چین پر اسٹیٹ ڈیٹا شائع کرتے ہیں۔ + +### ڈیٹا کی دستیابی {#data-availability} + +جیسا کہ ذکر کیا گیا ہے، ویلیڈیمز ایک آف چین ڈیٹا دستیابی ماڈل کا استعمال کرتے ہیں، جہاں آپریٹرز تمام ٹرانزیکشن ڈیٹا کو ایتھریم مین نیٹ سے باہر اسٹور کرتے ہیں۔ ویلیڈیم کا کم آن چین ڈیٹا فوٹ پرنٹ اسکیل ایبلیٹی کو بہتر بناتا ہے (تھرو پٹ ایتھریم کی ڈیٹا پروسیسنگ کی صلاحیت سے محدود نہیں ہے) اور صارف کی فیس کو کم کرتا ہے (آن چین ڈیٹا شائع کرنے کی لاگت کم ہے)۔ + +تاہم، آف چین ڈیٹا کی دستیابی ایک مسئلہ پیش کرتی ہے: مرکل پروفس بنانے یا تصدیق کرنے کے لیے ضروری ڈیٹا دستیاب نہیں ہو سکتا ہے۔ اس کا مطلب ہے کہ اگر آپریٹرز بدنیتی سے کام کریں تو صارفین آن چین کنٹریکٹ سے فنڈز نکالنے سے قاصر ہو سکتے ہیں۔ + +مختلف ویلیڈیم سلوشنز اسٹیٹ ڈیٹا کے اسٹوریج کو غیر مرکزی بنا کر اس مسئلے کو حل کرنے کی کوشش کرتے ہیں۔ اس میں بلاک پروڈیوسرز کو بنیادی ڈیٹا "ڈیٹا دستیابی مینیجرز" کو بھیجنے پر مجبور کرنا شامل ہے جو آف چین ڈیٹا کو اسٹور کرنے اور درخواست پر صارفین کو دستیاب کرانے کے ذمہ دار ہیں۔ + +ویلیڈیم میں ڈیٹا دستیابی مینیجرز ہر ویلیڈیم بیچ پر دستخط کرکے آف چین ٹرانزیکشنز کے لیے ڈیٹا کی دستیابی کی تصدیق کرتے ہیں۔ یہ دستخط "دستیابی کے ثبوت" کی ایک شکل تشکیل دیتے ہیں جسے آن چین تصدیق کنندہ کنٹریکٹ اسٹیٹ اپ ڈیٹس کو منظور کرنے سے پہلے چیک کرتا ہے۔ + +ویلیڈیمز ڈیٹا دستیابی کے انتظام کے اپنے نقطہ نظر میں مختلف ہیں۔ کچھ اسٹیٹ ڈیٹا کو اسٹور کرنے کے لیے قابل اعتماد پارٹیوں پر انحصار کرتے ہیں، جبکہ دیگر اس کام کے لیے تصادفی طور پر تفویض کردہ توثیق کاروں کا استعمال کرتے ہیں۔ + +#### ڈیٹا دستیابی کمیٹی (DAC) {#data-availability-committee} + +آف چین ڈیٹا کی دستیابی کی ضمانت دینے کے لیے، کچھ ویلیڈیم سلوشنز قابل اعتماد اداروں کے ایک گروپ کو مقرر کرتے ہیں، جسے اجتماعی طور پر ڈیٹا دستیابی کمیٹی (DAC) کہا جاتا ہے، تاکہ اسٹیٹ کی کاپیاں اسٹور کی جا سکیں اور ڈیٹا کی دستیابی کا ثبوت فراہم کیا جا سکے۔ DACs کو نافذ کرنا آسان ہے اور کم کوآرڈینیشن کی ضرورت ہوتی ہے کیونکہ رکنیت کم ہوتی ہے۔ + +تاہم، صارفین کو ضرورت پڑنے پر ڈیٹا دستیاب کرانے کے لیے DAC پر بھروسہ کرنا چاہیے (مثلاً، مرکل پروفس بنانے کے لیے)۔ اس بات کا امکان ہے کہ ڈیٹا دستیابی کمیٹیوں کے اراکین [ایک بدنیتی پر مبنی اداکار کے ذریعے سمجھوتہ کر لیں](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view) جو پھر آف چین ڈیٹا روک سکتا ہے۔ + +[ویلیڈیمز میں ڈیٹا دستیابی کمیٹیوں پر مزید](https://medium.com/starkware/data-availability-e5564c416424)۔ + +#### بانڈڈ ڈیٹا کی دستیابی {#bonded-data-availability} + +دیگر ویلیڈیمز آف لائن ڈیٹا کو اسٹور کرنے کے ذمہ دار شرکاء سے مطالبہ کرتے ہیں کہ وہ اپنے کردار سنبھالنے سے پہلے ایک اسمارٹ کنٹریکٹ میں ٹوکنز کو اسٹیک (یعنی، لاک اپ) کریں۔ یہ اسٹیک ڈیٹا دستیابی مینیجرز کے درمیان ایماندارانہ رویے کی ضمانت دینے کے لیے ایک "بانڈ" کے طور پر کام کرتا ہے اور اعتماد کے مفروضوں کو کم کرتا ہے۔ اگر یہ شرکاء ڈیٹا کی دستیابی کو ثابت کرنے میں ناکام رہتے ہیں، تو بانڈ کو سلیش کر دیا جاتا ہے۔ + +بانڈڈ ڈیٹا دستیابی اسکیم میں، کوئی بھی شخص مطلوبہ اسٹیک فراہم کرنے کے بعد آف چین ڈیٹا رکھنے کے لیے تفویض کیا جا سکتا ہے۔ یہ اہل ڈیٹا دستیابی مینیجرز کے پول کو وسیع کرتا ہے، اس مرکزیت کو کم کرتا ہے جو ڈیٹا دستیابی کمیٹیوں (DACs) کو متاثر کرتی ہے۔ مزید اہم بات یہ ہے کہ یہ نقطہ نظر بدنیتی پر مبنی سرگرمی کو روکنے کے لیے کرپٹو اکنامک ترغیبات پر انحصار کرتا ہے، جو ویلیڈیم میں آف لائن ڈیٹا کو محفوظ بنانے کے لیے قابل اعتماد پارٹیوں کو مقرر کرنے سے کہیں زیادہ محفوظ ہے۔ + +[ویلیڈیمز میں بانڈڈ ڈیٹا کی دستیابی پر مزید](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)۔ + +## وولیشنز اور ویلیڈیم {#volitions-and-validium} + +ویلیڈیمز بہت سے فوائد پیش کرتے ہیں لیکن کچھ سمجھوتوں کے ساتھ آتے ہیں (سب سے خاص طور پر، ڈیٹا کی دستیابی)۔ لیکن، بہت سے اسکیلنگ سلوشنز کی طرح، ویلیڈیمز مخصوص استعمال کے معاملات کے لیے موزوں ہیں—یہی وجہ ہے کہ وولیشنز بنائے گئے تھے۔ + +وولیشنز ایک ZK-رول اپ اور ویلیڈیم چین کو یکجا کرتے ہیں اور صارفین کو دو اسکیلنگ سلوشنز کے درمیان سوئچ کرنے کی اجازت دیتے ہیں۔ وولیشنز کے ساتھ، صارفین کچھ ٹرانزیکشنز کے لیے ویلیڈیم کی آف چین ڈیٹا کی دستیابی سے فائدہ اٹھا سکتے ہیں، جبکہ ضرورت پڑنے پر آن چین ڈیٹا دستیابی سلوشن (ZK-رول اپ) پر سوئچ کرنے کی آزادی برقرار رکھتے ہیں۔ یہ بنیادی طور پر صارفین کو ان کے منفرد حالات کے مطابق سمجھوتوں کا انتخاب کرنے کی آزادی دیتا ہے۔ + +ایک غیر مرکزی ایکسچینج (DEX) اعلیٰ قدر کی ٹریڈز کے لیے ویلیڈیم کے اسکیل ایبل اور نجی انفراسٹرکچر کا استعمال کرنے کو ترجیح دے سکتا ہے۔ یہ ان صارفین کے لیے ZK-رول اپ کا بھی استعمال کر سکتا ہے جو ZK-رول اپ کی اعلیٰ سیکیورٹی گارنٹی اور ٹرسلیس نیس چاہتے ہیں۔ + +## ویلیڈیمز اور EVM کمپیٹیبلٹی {#validiums-and-evm-compatibility} + +ZK-رول اپس کی طرح، ویلیڈیمز زیادہ تر سادہ ایپلیکیشنز کے لیے موزوں ہیں، جیسے ٹوکن سویپس اور ادائیگی۔ ویلیڈیمز کے درمیان عمومی کمپیوٹیشن اور اسمارٹ کنٹریکٹ ایگزیکیوشن کو سپورٹ کرنا نافذ کرنا مشکل ہے، کیونکہ زیرو نالج پروف سرکٹ میں [EVM](/developers/docs/evm/) ہدایات کو ثابت کرنے کا کافی اوور ہیڈ ہوتا ہے۔ + +کچھ ویلیڈیم پروجیکٹس EVM-کمپیٹیبل زبانوں (مثلاً، Solidity، Vyper) کو کمپائل کرکے اس مسئلے سے بچنے کی کوشش کرتے ہیں تاکہ موثر پروونگ کے لیے آپٹمائزڈ کسٹم بائٹ کوڈ بنایا جا سکے۔ اس نقطہ نظر کا ایک نقصان یہ ہے کہ نئے زیرو نالج پروف-فرینڈلی VMs اہم EVM اوپ کوڈز کو سپورٹ نہیں کرسکتے ہیں، اور ڈیولپرز کو ایک بہترین تجربے کے لیے براہ راست اعلیٰ سطحی زبان میں لکھنا پڑتا ہے۔ یہ مزید مسائل پیدا کرتا ہے: یہ ڈیولپرز کو مکمل طور پر نئے ڈیولپمنٹ اسٹیک کے ساتھ dapps بنانے پر مجبور کرتا ہے اور موجودہ ایتھریم انفراسٹرکچر کے ساتھ کمپیٹیبلٹی کو توڑتا ہے۔ + +تاہم، کچھ ٹیمیں موجودہ EVM اوپ کوڈز کو ZK-پروونگ سرکٹس کے لیے آپٹمائز کرنے کی کوشش کر رہی ہیں۔ اس کے نتیجے میں ایک زیرو نالج ایتھریم ورچوئل مشین (zkEVM) کی ترقی ہوگی، جو ایک EVM-کمپیٹیبل VM ہے جو پروگرام ایگزیکیوشن کی درستگی کی تصدیق کے لیے پروفس تیار کرتا ہے۔ ایک zkEVM کے ساتھ، ویلیڈیم چینز آف چین اسمارٹ کنٹریکٹس کو انجام دے سکتی ہیں اور ایتھریم پر آف چین کمپیوٹیشن کی تصدیق کے لیے توثیقی ثبوت جمع کرا سکتی ہیں (بغیر اسے دوبارہ انجام دینے کے)۔ + +[zkEVMs پر مزید](https://www.alchemy.com/overviews/zkevm)۔ + +## ویلیڈیمز ایتھریم کو کیسے اسکیل کرتے ہیں؟ {#scaling-ethereum-with-validiums} + +### 1۔ آف چین ڈیٹا اسٹوریج {#offchain-data-storage} + +لئیر 2 اسکیلنگ پروجیکٹس، جیسے آپٹیمسٹک رول اپس اور ZK-رول اپس، L1 پر کچھ ٹرانزیکشن ڈیٹا شائع کرکے سیکیورٹی کے لیے خالص آف چین اسکیلنگ پروٹوکولز (مثلاً، [پلازما](/developers/docs/scaling/plasma/)) کی لامحدود اسکیل ایبلیٹی کی ٹریڈ کرتے ہیں۔ لیکن اس کا مطلب ہے کہ رول اپس کی اسکیل ایبلیٹی خصوصیات ایتھریم مین نیٹ پر ڈیٹا بینڈوتھ سے محدود ہیں ([ڈیٹا شارڈنگ](/roadmap/danksharding/) اسی وجہ سے ایتھریم کی ڈیٹا اسٹوریج کی صلاحیت کو بہتر بنانے کی تجویز کرتا ہے)۔ + +ویلیڈیمز تمام ٹرانزیکشن ڈیٹا کو آف چین رکھ کر اور مرکزی ایتھریم چین پر اسٹیٹ اپ ڈیٹس کو ریلے کرتے وقت صرف اسٹیٹ کمٹمنٹس (اور توثیقی ثبوت) پوسٹ کرکے اسکیل ایبلیٹی حاصل کرتے ہیں۔ تاہم، توثیقی ثبوتوں کا وجود ویلیڈیمز کو دیگر خالص آف چین اسکیلنگ سلوشنز، بشمول پلازما اور [سائیڈ چینز](/developers/docs/scaling/sidechains/) سے زیادہ سیکیورٹی گارنٹی دیتا ہے۔ ایتھریم کو آف چین ٹرانزیکشنز کی توثیق کرنے سے پہلے پروسیس کرنے والے ڈیٹا کی مقدار کو کم کرکے، ویلیڈیم ڈیزائنز مین نیٹ پر تھرو پٹ کو بہت زیادہ بڑھاتے ہیں۔ + +### 2۔ ریکرسیو پروفس {#recursive-proofs} + +ایک ریکرسیو پروف ایک توثیقی ثبوت ہے جو دوسرے ثبوتوں کی توثیق کرتا ہے۔ یہ "پروف آف پروفس" متعدد ثبوتوں کو ریکرسیو طور پر جمع کرکے تیار کیے جاتے ہیں جب تک کہ ایک حتمی ثبوت جو تمام پچھلے ثبوتوں کی تصدیق کرتا ہے، بن نہ جائے۔ ریکرسیو پروفس فی توثیقی ثبوت کی تصدیق کیے جانے والے ٹرانزیکشنز کی تعداد میں اضافہ کرکے بلاک چین پروسیسنگ کی رفتار کو اسکیل کرتے ہیں۔ + +عام طور پر، ہر توثیقی ثبوت جو ویلیڈیم آپریٹر ایتھریم کو تصدیق کے لیے جمع کرتا ہے، ایک ہی بلاک کی سالمیت کی توثیق کرتا ہے۔ جبکہ ایک ہی ریکرسیو پروف کا استعمال ایک ہی وقت میں کئی ویلیڈیم بلاکس کی توثیق کی تصدیق کے لیے کیا جا سکتا ہے—یہ ممکن ہے کیونکہ پروونگ سرکٹ کئی بلاک پروفس کو ریکرسیو طور پر ایک حتمی پروف میں جمع کر سکتا ہے۔ اگر آن چین تصدیق کنندہ کنٹریکٹ ریکرسیو پروف کو قبول کرتا ہے، تو تمام بنیادی بلاکس فوری طور پر حتمی ہو جاتے ہیں۔ + +## ویلیڈیم کے فوائد اور نقصانات {#pros-and-cons-of-validium} + +| فوائد | نقصانات | +| --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| توثیقی ثبوت آف چین ٹرانزیکشنز کی سالمیت کو نافذ کرتے ہیں اور آپریٹرز کو غلط اسٹیٹ اپ ڈیٹس کو حتمی شکل دینے سے روکتے ہیں۔ | توثیقی ثبوت تیار کرنے کے لیے خصوصی ہارڈویئر کی ضرورت ہوتی ہے، جو مرکزیت کا خطرہ پیدا کرتا ہے۔ | +| صارفین کے لیے سرمائے کی کارکردگی کو بڑھاتا ہے (ایتھریم میں فنڈز واپس نکالنے میں کوئی تاخیر نہیں) | عمومی کمپیوٹیشن/اسمارٹ کنٹریکٹس کے لیے محدود سپورٹ؛ ڈیولپمنٹ کے لیے خصوصی زبانوں کی ضرورت ہے۔ | +| اعلیٰ قدر والی ایپلیکیشنز میں فراڈ-پروف پر مبنی سسٹمز کو درپیش بعض اقتصادی حملوں کے لیے غیر محفوظ نہیں۔ | ZK پروفس بنانے کے لیے اعلیٰ کمپیوٹیشنل پاور کی ضرورت؛ کم تھرو پٹ والی ایپلیکیشنز کے لیے لاگت-مؤثر نہیں۔ | +| ایتھریم مین نیٹ پر calldata پوسٹ نہ کرکے صارفین کے لیے گیس کی فیس کو کم کرتا ہے۔ | سست موضوعی فائنلٹی وقت (ایک ZK پروف بنانے میں 10-30 منٹ) لیکن مکمل فائنلٹی تک تیز کیونکہ کوئی تنازعہ وقت کی تاخیر نہیں ہے۔ | +| مخصوص استعمال کے معاملات کے لیے موزوں، جیسے ٹریڈنگ یا بلاک چین گیمنگ جو ٹرانزیکشن کی رازداری اور اسکیل ایبلیٹی کو ترجیح دیتے ہیں۔ | صارفین کو فنڈز نکالنے سے روکا جا سکتا ہے کیونکہ ملکیت کے مرکل پروفس بنانے کے لیے آف چین ڈیٹا کا ہر وقت دستیاب ہونا ضروری ہے۔ | +| آف چین ڈیٹا کی دستیابی اعلیٰ سطح کا تھرو پٹ فراہم کرتی ہے اور اسکیل ایبلیٹی کو بڑھاتی ہے۔ | سیکیورٹی ماڈل اعتماد کے مفروضوں اور کرپٹو اکنامک ترغیبات پر انحصار کرتا ہے، ZK-رول اپس کے برعکس، جو خالصتاً کرپٹو گرافک سیکیورٹی میکانزم پر انحصار کرتے ہیں۔ | + +### ویلیڈیم/وولیشنز کا استعمال کریں {#use-validium-and-volitions} + +متعدد پروجیکٹس ویلیڈیم اور وولیشنز کے نفاذ فراہم کرتے ہیں جنہیں آپ اپنے dapps میں ضم کر سکتے ہیں: + +**StarkWare StarkEx** - _StarkEx ایک ایتھریم لئیر 2 (L2) اسکیل ایبلیٹی سلوشن ہے جو توثیقی ثبوتوں پر مبنی ہے۔ یہ ZK-رول اپ یا ویلیڈیم ڈیٹا-دستیابی موڈز میں کام کر سکتا ہے۔_ + +- [ڈاکومنٹیشن](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) +- [ویب سائٹ](https://starkware.co/starkex/) + +**Matter Labs zkPorter**- _zkPorter ایک لئیر 2 اسکیلنگ پروٹوکول ہے جو zkRollup اور شارڈنگ کے آئیڈیاز کو ملا کر ایک ہائبرڈ اپروچ کے ساتھ ڈیٹا دستیابی سے نمٹتا ہے۔ یہ من مانی طور پر بہت سے شارڈز کو سپورٹ کر سکتا ہے، ہر ایک اپنی ڈیٹا دستیابی کی پالیسی کے ساتھ۔_ + +- [بلاگ](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [ڈاکومنٹیشن](https://docs.zksync.io/zksync-protocol/rollup/data-availability) +- [ویب سائٹ](https://zksync.io/) + +## مزید پڑھیں {#further-reading} + +- [ویلیڈیم اور لئیر 2 ٹو-بائی-ٹو — شمارہ نمبر 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [ZK-رول اپس بمقابلہ ویلیڈیم](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [وولیشن اور ابھرتا ہوا ڈیٹا دستیابی اسپیکٹرم](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) +- [رول اپس، ویلیڈیمز، اور وولیشنز: گرم ترین ایتھریم اسکیلنگ سلوشنز کے بارے میں جانیں](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [Ethereum رول اپس کے لیے عملی گائیڈ](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) diff --git a/public/content/translations/ur/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/ur/developers/docs/scaling/zk-rollups/index.md new file mode 100644 index 00000000000..bcfdb4d9a4d --- /dev/null +++ b/public/content/translations/ur/developers/docs/scaling/zk-rollups/index.md @@ -0,0 +1,257 @@ +--- +title: "زیرو-نالج رول اپس" +description: "زیرو-نالج رول اپس کا تعارف — ایک اسکیلنگ حل جسے ایتھیریم کمیونٹی استعمال کرتی ہے۔" +lang: ur-in +--- + +زیرو-نالج رول اپس (ZK-rollups) لیئر 2 [اسکیلنگ حل](/developers/docs/scaling/) ہیں جو کمپیوٹیشن اور اسٹیٹ-اسٹوریج کو آف چین منتقل کرکے Ethereum Mainnet پر تھرو پُٹ میں اضافہ کرتے ہیں۔ ZK-rollups ایک بیچ میں ہزاروں ٹرانزیکشنز پر کارروائی کر سکتے ہیں اور پھر Mainnet پر صرف کچھ کم سے کم سمری ڈیٹا پوسٹ کرتے ہیں۔ یہ سمری ڈیٹا ان تبدیلیوں کی وضاحت کرتا ہے جو ایتھیریم اسٹیٹ میں کی جانی چاہئیں اور اس بات کا کرپٹوگرافک ثبوت فراہم کرتا ہے کہ وہ تبدیلیاں درست ہیں۔ + +## شرائط {#prerequisites} + +آپ کو [ایتھریم اسکیلنگ](/developers/docs/scaling/) اور [لئیر 2](/layer-2) پر ہمارا صفحہ پڑھا اور سمجھا ہوا ہونا چاہیے۔ + +## زیرو-نالج رول اپس کیا ہیں؟ {#what-are-zk-rollups} + +**زیرو-نالج رول اپس (ZK-rollups)** ٹرانزیکشنز کو بیچوں میں بنڈل (یا 'رول اپ') کرتے ہیں جنہیں آف چین عمل میں لایا جاتا ہے۔ آف چین کمپیوٹیشن ڈیٹا کی اس مقدار کو کم کرتا ہے جسے بلاک چین پر پوسٹ کرنا پڑتا ہے۔ ZK-rollup آپریٹرز ہر ٹرانزیکشن کو انفرادی طور پر بھیجنے کے بجائے، ایک بیچ میں تمام ٹرانزیکشنز کی نمائندگی کے لیے درکار تبدیلیوں کا خلاصہ جمع کراتے ہیں۔ وہ اپنی تبدیلیوں کی درستگی کو ثابت کرنے کے لیے [ویلیڈیٹی پروف](/glossary/#validity-proof) بھی تیار کرتے ہیں۔ + +ZK-rollup کا اسٹیٹ Ethereum نیٹ ورک پر ڈیپلائے کیے گئے ایک اسمارٹ کنٹریکٹ کے ذریعے برقرار رکھا جاتا ہے۔ اس اسٹیٹ کو اپ ڈیٹ کرنے کے لیے، ZK-rollup نوڈز کو تصدیق کے لیے ایک ویلیڈیٹی پروف جمع کرانا ہوگا۔ جیسا کہ ذکر کیا گیا ہے، ویلیڈیٹی پروف ایک کرپٹوگرافک یقین دہانی ہے کہ رول اپ کی طرف سے تجویز کردہ اسٹیٹ-چینج واقعی دیے گئے ٹرانزیکشنز کے بیچ کو انجام دینے کا نتیجہ ہے۔ اس کا مطلب ہے کہ ZK-rollups کو Ethereum پر ٹرانزیکشنز کو حتمی شکل دینے کے لیے صرف ویلیڈیٹی پروف فراہم کرنے کی ضرورت ہوتی ہے، بجائے اس کے کہ [آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups/) کی طرح تمام ٹرانزیکشن ڈیٹا کو آن چین پوسٹ کیا جائے۔ + +ZK-rollup سے Ethereum میں فنڈز منتقل کرتے وقت کوئی تاخیر نہیں ہوتی ہے کیونکہ ایگزٹ ٹرانزیکشنز پر عمل درآمد اس وقت ہو جاتا ہے جب ZK-rollup کنٹریکٹ ویلیڈیٹی پروف کی تصدیق کر لیتا ہے۔ اس کے برعکس، آپٹیمسٹک رول اپس سے فنڈز نکالنے میں تاخیر ہوتی ہے تاکہ کوئی بھی [فراڈ پروف](/glossary/#fraud-proof) کے ساتھ ایگزٹ ٹرانزیکشن کو چیلنج کر سکے۔ + +ZK-rollups ٹرانزیکشنز کو Ethereum پر `calldata` کے طور پر لکھتے ہیں۔ `calldata` وہ جگہ ہے جہاں وہ ڈیٹا اسٹور کیا جاتا ہے جو اسمارٹ کنٹریکٹ فنکشنز کی بیرونی کالز میں شامل ہوتا ہے۔ `calldata` میں موجود معلومات بلاک چین پر شائع کی جاتی ہیں، جس سے کوئی بھی آزادانہ طور پر رول اپ کے اسٹیٹ کو دوبارہ تشکیل دے سکتا ہے۔ ZK-rollups ٹرانزیکشن ڈیٹا کو کم کرنے کے لیے کمپریشن تکنیک کا استعمال کرتے ہیں—مثال کے طور پر، اکاؤنٹس کو ایڈریس کے بجائے ایک انڈیکس کے ذریعے دکھایا جاتا ہے، جس سے 28 بائٹس ڈیٹا کی بچت ہوتی ہے۔ آن چین ڈیٹا کی اشاعت رول اپس کے لیے ایک اہم لاگت ہے، اس لیے ڈیٹا کمپریشن صارفین کے لیے فیس کو کم کر سکتا ہے۔ + +## ZK-rollups ایتھیریم کے ساتھ کیسے تعامل کرتے ہیں؟ {#zk-rollups-and-ethereum} + +ایک ZK-rollup چین ایک آف چین پروٹوکول ہے جو Ethereum بلاک چین کے اوپر کام کرتا ہے اور اسے آن چین Ethereum اسمارٹ کنٹریکٹس کے ذریعے منظم کیا جاتا ہے۔ ZK-rollups ٹرانزیکشنز کو Mainnet سے باہر انجام دیتے ہیں، لیکن وقتاً فوقتاً آف چین ٹرانزیکشن بیچوں کو ایک آن چین رول اپ کنٹریکٹ میں کمٹ کرتے ہیں۔ یہ ٹرانزیکشن ریکارڈ ناقابل تغیر ہے، بالکل Ethereum بلاک چین کی طرح، اور ZK-rollup چین بناتا ہے۔ + +ZK-rollup کے بنیادی فن تعمیر میں درج ذیل اجزاء شامل ہیں: + +1. **آن چین کنٹریکٹس**: جیسا کہ ذکر کیا گیا ہے، ZK-rollup پروٹوکول کو Ethereum پر چلنے والے اسمارٹ کنٹریکٹس کے ذریعے کنٹرول کیا جاتا ہے۔ اس میں مین کنٹریکٹ شامل ہے جو رول اپ بلاکس کو اسٹور کرتا ہے، ڈپازٹس کو ٹریک کرتا ہے، اور اسٹیٹ اپ ڈیٹس کی نگرانی کرتا ہے۔ ایک اور آن چین کنٹریکٹ (ویریفائر کنٹریکٹ) بلاک پروڈیوسرز کے ذریعے جمع کرائے گئے زیرو-نالج پروف کی تصدیق کرتا ہے۔ اس طرح، Ethereum ZK-rollup کے لیے بیس لیئر یا "لیئر 1" کے طور پر کام کرتا ہے۔ + +2. **آف چین ورچوئل مشین (VM)**: جب کہ ZK-rollup پروٹوکول Ethereum پر رہتا ہے، ٹرانزیکشن پر عمل درآمد اور اسٹیٹ اسٹوریج [EVM](/developers/docs/evm/) سے آزاد ایک علیحدہ ورچوئل مشین پر ہوتا ہے۔ یہ آف چین VM ZK-rollup پر ٹرانزیکشنز کے لیے ایگزیکیوشن ماحول ہے اور ZK-rollup پروٹوکول کے لیے ثانوی پرت یا "لیئر 2" کے طور پر کام کرتا ہے۔ Ethereum Mainnet پر تصدیق شدہ ویلیڈیٹی پروف آف چین VM میں اسٹیٹ ٹرانزیشن کی درستگی کی ضمانت دیتے ہیں۔ + +ZK-rollups "ہائبرڈ اسکیلنگ حل" ہیں—آف چین پروٹوکول جو آزادانہ طور پر کام کرتے ہیں لیکن Ethereum سے سیکیورٹی حاصل کرتے ہیں۔ خاص طور پر، Ethereum نیٹ ورک ZK-rollup پر اسٹیٹ اپ ڈیٹس کی درستگی کو نافذ کرتا ہے اور رول اپ کے اسٹیٹ میں ہر اپ ڈیٹ کے پیچھے ڈیٹا کی دستیابی کی ضمانت دیتا ہے۔ نتیجے کے طور پر، ZK-rollups خالص آف چین اسکیلنگ حلوں سے کافی زیادہ محفوظ ہیں، جیسے کہ [سائیڈ چینز](/developers/docs/scaling/sidechains/)، جو اپنی سیکیورٹی خصوصیات کے لیے خود ذمہ دار ہیں، یا [ویلیڈیمز](/developers/docs/scaling/validium/)، جو ویلیڈیٹی پروف کے ساتھ Ethereum پر ٹرانزیکشنز کی تصدیق بھی کرتے ہیں، لیکن ٹرانزیکشن ڈیٹا کہیں اور اسٹور کرتے ہیں۔ + +ZK-rollups درج ذیل کے لیے مرکزی Ethereum پروٹوکول پر انحصار کرتے ہیں: + +### ڈیٹا کی دستیابی {#data-availability} + +ZK-rollups آف چین پر کارروائی کیے گئے ہر ٹرانزیکشن کے لیے اسٹیٹ ڈیٹا کو Ethereum پر شائع کرتے ہیں۔ اس ڈیٹا کے ساتھ، افراد یا کاروبار کے لیے رول اپ کے اسٹیٹ کو دوبارہ پیش کرنا اور خود چین کی توثیق کرنا ممکن ہے۔ Ethereum اس ڈیٹا کو نیٹ ورک کے تمام شرکاء کے لیے `calldata` کے طور پر دستیاب کرتا ہے۔ + +ZK-rollups کو آن چین زیادہ ٹرانزیکشن ڈیٹا شائع کرنے کی ضرورت نہیں ہے کیونکہ ویلیڈیٹی پروف پہلے ہی اسٹیٹ ٹرانزیشن کی صداقت کی تصدیق کر چکے ہیں۔ اس کے باوجود، آن چین ڈیٹا اسٹور کرنا اب بھی اہم ہے کیونکہ یہ L2 چین کے اسٹیٹ کی اجازت کے بغیر، آزادانہ تصدیق کی اجازت دیتا ہے جس کے نتیجے میں کسی کو بھی ٹرانزیکشنز کے بیچ جمع کرانے کی اجازت ملتی ہے، جس سے بدنیتی پر مبنی آپریٹرز کو چین کو سنسر کرنے یا منجمد کرنے سے روکا جاتا ہے۔ + +صارفین کو رول اپ کے ساتھ تعامل کرنے کے لیے آن چین کی ضرورت ہے۔ اسٹیٹ ڈیٹا تک رسائی کے بغیر صارفین اپنے اکاؤنٹ کا بیلنس دریافت نہیں کر سکتے یا ایسی ٹرانزیکشنز (جیسے، نکاسی) شروع نہیں کر سکتے جو اسٹیٹ کی معلومات پر انحصار کرتی ہیں۔ + +### ٹرانزیکشن کی حتمیت {#transaction-finality} + +Ethereum ZK-rollups کے لیے ایک سیٹلمنٹ لیئر کے طور پر کام کرتا ہے: L2 ٹرانزیکشنز صرف اس صورت میں حتمی شکل دی جاتی ہیں جب L1 کنٹریکٹ ویلیڈیٹی پروف کو قبول کرتا ہے۔ اس سے بدنیتی پر مبنی آپریٹرز کے چین کو خراب کرنے (جیسے، رول اپ فنڈز چوری کرنا) کے خطرے کو ختم کرتا ہے کیونکہ ہر ٹرانزیکشن کو Mainnet پر منظور ہونا ضروری ہے۔ اس کے علاوہ، Ethereum اس بات کی ضمانت دیتا ہے کہ L1 پر حتمی شکل دینے کے بعد صارف کے آپریشنز کو واپس نہیں کیا جا سکتا۔ + +### سنسرشپ مزاحمت {#censorship-resistance} + +زیادہ تر ZK-rollups ٹرانزیکشنز پر عمل درآمد کرنے، بیچ تیار کرنے اور L1 میں بلاکس جمع کرانے کے لیے ایک "سپر نوڈ" (آپریٹر) کا استعمال کرتے ہیں۔ اگرچہ یہ کارکردگی کو یقینی بناتا ہے، لیکن یہ سنسرشپ کے خطرے کو بڑھاتا ہے: بدنیتی پر مبنی ZK-rollup آپریٹرز صارفین کو ان کے ٹرانزیکشنز کو بیچوں میں شامل کرنے سے انکار کرکے سنسر کر سکتے ہیں۔ + +ایک حفاظتی اقدام کے طور پر، ZK-rollups صارفین کو براہ راست Mainnet پر رول اپ کنٹریکٹ میں ٹرانزیکشنز جمع کرانے کی اجازت دیتے ہیں اگر وہ سوچتے ہیں کہ آپریٹر ان کو سنسر کر رہا ہے۔ اس سے صارفین آپریٹر کی اجازت پر انحصار کیے بغیر ZK-rollup سے Ethereum تک جبری اخراج کر سکتے ہیں۔ + +## ZK-rollups کیسے کام کرتے ہیں؟ {#how-do-zk-rollups-work} + +### ٹرانزیکشنز {#transactions} + +ZK-rollup میں صارفین ٹرانزیکشنز پر دستخط کرتے ہیں اور پروسیسنگ اور اگلے بیچ میں شامل کرنے کے لیے L2 آپریٹرز کو جمع کراتے ہیں۔ کچھ معاملات میں، آپریٹر ایک مرکزی ادارہ ہے، جسے سیکوینسر کہا جاتا ہے، جو ٹرانزیکشنز کو انجام دیتا ہے، انہیں بیچوں میں جمع کرتا ہے، اور L1 کو جمع کراتا ہے۔ اس سسٹم میں سیکوینسر واحد ادارہ ہے جسے L2 بلاکس تیار کرنے اور ZK-rollup کنٹریکٹ میں رول اپ ٹرانزیکشنز شامل کرنے کی اجازت ہے۔ + +دیگر ZK-rollups [پروف-آف-اسٹیک](/developers/docs/consensus-mechanisms/pos/) توثیق کار سیٹ کا استعمال کرکے آپریٹر کے کردار کو گھما سکتے ہیں۔ متوقع آپریٹرز رول اپ کنٹریکٹ میں فنڈز جمع کرتے ہیں، ہر اسٹیک کا سائز اگلے رول اپ بیچ کو تیار کرنے کے لیے منتخب ہونے کے اسٹیکر کے امکانات کو متاثر کرتا ہے۔ اگر آپریٹر بدنیتی سے کام کرتا ہے تو اس کے اسٹیک کو سلیش کیا جاسکتا ہے، جو انہیں درست بلاکس پوسٹ کرنے کی ترغیب دیتا ہے۔ + +#### ZK-rollups Ethereum پر ٹرانزیکشن ڈیٹا کیسے شائع کرتے ہیں {#how-zk-rollups-publish-transaction-data-on-ethereum} + +جیسا کہ وضاحت کی گئی ہے، ٹرانزیکشن ڈیٹا کو Ethereum پر `calldata` کے طور پر شائع کیا جاتا ہے۔ `calldata` ایک اسمارٹ کنٹریکٹ میں ایک ڈیٹا ایریا ہے جو کسی فنکشن میں دلائل منتقل کرنے کے لیے استعمال ہوتا ہے اور [میموری](/developers/docs/smart-contracts/anatomy/#memory) کی طرح برتاؤ کرتا ہے۔ اگرچہ `calldata` کو Ethereum کے اسٹیٹ کے حصے کے طور پر اسٹور نہیں کیا جاتا ہے، یہ Ethereum چین کے [ہسٹری لاگز](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) کے حصے کے طور پر آن چین برقرار رہتا ہے۔ `calldata` Ethereum کے اسٹیٹ کو متاثر نہیں کرتا ہے، جو اسے آن چین ڈیٹا اسٹور کرنے کا ایک سستا طریقہ بناتا ہے۔ + +`calldata` کلیدی لفظ اکثر اسمارٹ کنٹریکٹ کے طریقہ کار کی نشاندہی کرتا ہے جسے کسی ٹرانزیکشن کے ذریعے بلایا جا رہا ہے اور اس طریقہ کار کے ان پٹس کو بائٹس کی ایک صوابدیدی ترتیب کی شکل میں رکھتا ہے۔ ZK-rollups کمپریسڈ ٹرانزیکشن ڈیٹا کو آن چین شائع کرنے کے لیے `calldata` کا استعمال کرتے ہیں؛ رول اپ آپریٹر صرف رول اپ کنٹریکٹ میں مطلوبہ فنکشن کو کال کرکے ایک نیا بیچ شامل کرتا ہے اور کمپریسڈ ڈیٹا کو فنکشن آرگیومنٹس کے طور پر پاس کرتا ہے۔ اس سے صارفین کے لیے لاگت کو کم کرنے میں مدد ملتی ہے کیونکہ رول اپ فیس کا ایک بڑا حصہ آن چین ٹرانزیکشن ڈیٹا کو اسٹور کرنے پر جاتا ہے۔ + +### اسٹیٹ کمٹمنٹس {#state-commitments} + +ZK-rollup کا اسٹیٹ، جس میں L2 اکاؤنٹس اور بیلنس شامل ہیں، کو ایک [مرکل ٹری](/whitepaper/#merkle-trees) کے طور پر دکھایا جاتا ہے۔ مرکل ٹری کے روٹ (مرکل روٹ) کا ایک کرپٹوگرافک ہیش آن چین کنٹریکٹ میں اسٹور کیا جاتا ہے، جس سے رول اپ پروٹوکول کو ZK-rollup کے اسٹیٹ میں تبدیلیوں کو ٹریک کرنے کی اجازت ملتی ہے۔ + +رول اپ ٹرانزیکشنز کے ایک نئے سیٹ کے عمل درآمد کے بعد ایک نئے اسٹیٹ میں منتقل ہوجاتا ہے۔ اسٹیٹ کی منتقلی شروع کرنے والے آپریٹر کو ایک نیا اسٹیٹ روٹ کا حساب لگانے اور آن چین کنٹریکٹ میں جمع کرانے کی ضرورت ہوتی ہے۔ اگر بیچ سے وابستہ ویلیڈیٹی پروف کی تصدیق ویریفائر کنٹریکٹ کے ذریعے کی جاتی ہے، تو نیا مرکل روٹ ZK-rollup کا کینونیکل اسٹیٹ روٹ بن جاتا ہے۔ + +اسٹیٹ روٹس کا حساب لگانے کے علاوہ، ZK-rollup آپریٹر ایک بیچ روٹ بھی بناتا ہے — ایک مرکل ٹری کا روٹ جس میں ایک بیچ کے تمام ٹرانزیکشنز شامل ہوتے ہیں۔ جب کوئی نیا بیچ جمع کیا جاتا ہے، تو رول اپ کنٹریکٹ بیچ روٹ کو اسٹور کرتا ہے، جس سے صارفین کو یہ ثابت کرنے کی اجازت ملتی ہے کہ ایک ٹرانزیکشن (جیسے، واپسی کی درخواست) بیچ میں شامل تھا۔ صارفین کو ٹرانزیکشن کی تفصیلات، بیچ روٹ، اور ایک [مرکل پروف](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) فراہم کرنا ہوگا جو شمولیت کا راستہ دکھاتا ہے۔ + +### ویلیڈیٹی پروف {#validity-proofs} + +نیا اسٹیٹ روٹ جو ZK-rollup آپریٹر L1 کنٹریکٹ میں جمع کرتا ہے، وہ رول اپ کے اسٹیٹ میں اپ ڈیٹس کا نتیجہ ہے۔ فرض کریں ایلس باب کو 10 ٹوکن بھیجتی ہے، آپریٹر صرف ایلس کے بیلنس میں 10 کی کمی کرتا ہے اور باب کے بیلنس میں 10 کا اضافہ کرتا ہے۔ آپریٹر پھر اپ ڈیٹ شدہ اکاؤنٹ ڈیٹا کو ہیش کرتا ہے، رول اپ کے مرکل ٹری کو دوبارہ بناتا ہے، اور نیا مرکل روٹ آن چین کنٹریکٹ میں جمع کرتا ہے۔ + +لیکن رول اپ کنٹریکٹ خود بخود مجوزہ اسٹیٹ کمٹمنٹ کو قبول نہیں کرے گا جب تک کہ آپریٹر یہ ثابت نہ کر دے کہ نیا مرکل روٹ رول اپ کے اسٹیٹ میں درست اپ ڈیٹس کا نتیجہ ہے۔ ZK-rollup آپریٹر ایک ویلیڈیٹی پروف تیار کرکے ایسا کرتا ہے، جو ایک مختصر کرپٹوگرافک کمٹمنٹ ہے جو بیچڈ ٹرانزیکشنز کی درستگی کی تصدیق کرتا ہے۔ + +ویلیڈیٹی پروف فریقین کو بیان کو ظاہر کیے بغیر اس کی درستگی کو ثابت کرنے کی اجازت دیتے ہیں—اس لیے، انہیں زیرو-نالج پروف بھی کہا جاتا ہے۔ ZK-rollups Ethereum پر ٹرانزیکشنز کو دوبارہ انجام دیے بغیر آف چین اسٹیٹ ٹرانزیشن کی درستگی کی تصدیق کے لیے ویلیڈیٹی پروف کا استعمال کرتے ہیں۔ یہ ثبوت [ZK-SNARK](https://arxiv.org/abs/2202.06877) (زیرو-نالج سکسینکٹ نان-انٹرایکٹو آرگیومنٹ آف نالج) یا [ZK-STARK](https://eprint.iacr.org/2018/046) (زیرو-نالج اسکیل ایبل ٹرانسپیرنٹ آرگیومنٹ آف نالج) کی شکل میں آسکتے ہیں۔ + +SNARKs اور STARKs دونوں ZK-rollups میں آف چین کمپیوٹیشن کی سالمیت کی تصدیق میں مدد کرتے ہیں، حالانکہ ہر پروف کی قسم کی اپنی الگ خصوصیات ہیں۔ + +**ZK-SNARKs** + +ZK-SNARK پروٹوکول کے کام کرنے کے لیے، ایک کامن ریفرنس اسٹرنگ (CRS) بنانا ضروری ہے: CRS ویلیڈیٹی پروف کو ثابت کرنے اور تصدیق کرنے کے لیے عوامی پیرامیٹرز فراہم کرتا ہے۔ پروفنگ سسٹم کی سیکیورٹی CRS سیٹ اپ پر منحصر ہے؛ اگر عوامی پیرامیٹرز بنانے کے لیے استعمال ہونے والی معلومات بدنیتی پر مبنی اداکاروں کے قبضے میں آجاتی ہیں تو وہ غلط ویلیڈیٹی پروف تیار کرنے کے قابل ہو سکتے ہیں۔ + +کچھ ZK-rollups اس مسئلے کو حل کرنے کی کوشش کرتے ہیں جس میں [ملٹی پارٹی کمپیوٹیشن سیریمونی (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) کا استعمال کیا جاتا ہے، جس میں قابل اعتماد افراد شامل ہوتے ہیں، تاکہ ZK-SNARK سرکٹ کے لیے عوامی پیرامیٹرز تیار کیے جاسکیں۔ ہر پارٹی CRS کی تعمیر میں کچھ بے ترتیبی (جسے "زہریلا فضلہ" کہا جاتا ہے) کا حصہ ڈالتی ہے، جسے انہیں فوری طور پر تباہ کرنا ہوگا۔ + +قابل اعتماد سیٹ اپ استعمال کیے جاتے ہیں کیونکہ وہ CRS سیٹ اپ کی سیکیورٹی کو بڑھاتے ہیں۔ جب تک ایک ایماندار شریک اپنے ان پٹ کو تباہ کرتا ہے، ZK-SNARK سسٹم کی سیکیورٹی کی ضمانت دی جاتی ہے۔ پھر بھی، اس نقطہ نظر میں شامل افراد پر بھروسہ کرنے کی ضرورت ہے کہ وہ اپنی نمونہ کردہ بے ترتیبی کو حذف کریں اور سسٹم کی سیکیورٹی کی ضمانتوں کو کمزور نہ کریں۔ + +اعتماد کے مفروضوں کے علاوہ، ZK-SNARKs اپنے چھوٹے پروف سائز اور مستقل وقت کی تصدیق کے لیے مقبول ہیں۔ چونکہ L1 پر پروف کی تصدیق ZK-rollup کو چلانے کی بڑی لاگت پر مشتمل ہے، L2s ZK-SNARKs کا استعمال ایسے پروف تیار کرنے کے لیے کرتے ہیں جن کی Mainnet پر جلدی اور سستے طریقے سے تصدیق کی جا سکے۔ + +**ZK-STARKs** + +ZK-SNARKs کی طرح، ZK-STARKs ان پٹ کو ظاہر کیے بغیر آف چین کمپیوٹیشن کی درستگی کو ثابت کرتے ہیں۔ تاہم، ZK-STARKs کو ان کی اسکیل ایبلٹی اور شفافیت کی وجہ سے ZK-SNARKs پر ایک بہتری سمجھا جاتا ہے۔ + +ZK-STARKs 'شفاف' ہیں، کیونکہ وہ کامن ریفرنس اسٹرنگ (CRS) کے قابل اعتماد سیٹ اپ کے بغیر کام کر سکتے ہیں۔ اس کے بجائے، ZK-STARKs پروف تیار کرنے اور تصدیق کرنے کے لیے پیرامیٹرز سیٹ کرنے کے لیے عوامی طور پر قابل تصدیق بے ترتیبی پر انحصار کرتے ہیں۔ + +ZK-STARKs زیادہ اسکیل ایبلٹی بھی فراہم کرتے ہیں کیونکہ ویلیڈیٹی پروف کو ثابت کرنے اور تصدیق کرنے کے لیے درکار وقت بنیادی کمپیوٹیشن کی پیچیدگی کے سلسلے میں _کواسی لینیئرلی_ طور پر بڑھتا ہے۔ ZK-SNARKs کے ساتھ، ثابت کرنے اور تصدیق کرنے کا وقت بنیادی کمپیوٹیشن کے سائز کے سلسلے میں _لینیئرلی_ طور پر اسکیل ہوتا ہے۔ اس کا مطلب ہے کہ ZK-STARKs کو ZK-SNARKs کے مقابلے میں ثابت کرنے اور تصدیق کرنے میں کم وقت درکار ہوتا ہے جب بڑے ڈیٹاسیٹ شامل ہوتے ہیں، جو انہیں زیادہ حجم والی ایپلی کیشنز کے لیے مفید بناتا ہے۔ + +ZK-STARKs کوانٹم کمپیوٹرز کے خلاف بھی محفوظ ہیں، جبکہ ZK-SNARKs میں استعمال ہونے والی ایلیپٹک کرو کرپٹوگرافی (ECC) کے بارے میں وسیع پیمانے پر خیال کیا جاتا ہے کہ وہ کوانٹم کمپیوٹنگ حملوں کے لیے حساس ہے۔ ZK-STARKs کا نقصان یہ ہے کہ وہ بڑے پروف سائز تیار کرتے ہیں، جن کی Ethereum پر تصدیق کرنا زیادہ مہنگا ہوتا ہے۔ + +#### ZK-rollups میں ویلیڈیٹی پروف کیسے کام کرتے ہیں؟ {#validity-proofs-in-zk-rollups} + +##### پروف کی تیاری + +ٹرانزیکشنز قبول کرنے سے پہلے، آپریٹر معمول کی جانچ پڑتال کرے گا۔ اس میں اس بات کی تصدیق شامل ہے کہ: + +- بھیجنے والے اور وصول کنندہ کے اکاؤنٹس اسٹیٹ ٹری کا حصہ ہیں۔ +- بھیجنے والے کے پاس ٹرانزیکشن پر کارروائی کرنے کے لیے کافی فنڈز ہیں۔ +- ٹرانزیکشن درست ہے اور رول اپ پر بھیجنے والے کی پبلک کلید سے میل کھاتا ہے۔ +- بھیجنے والے کا نونس درست ہے، وغیرہ۔ + +ایک بار جب ZK-rollup نوڈ کے پاس کافی ٹرانزیکشنز ہو جاتے ہیں، تو وہ انہیں ایک بیچ میں جمع کرتا ہے اور پروفنگ سرکٹ کے لیے ان پٹس کو مرتب کرتا ہے تاکہ ایک مختصر ZK-پروف میں مرتب کیا جا سکے۔ اس میں شامل ہیں: + +- ایک مرکل ٹری روٹ جس میں بیچ کے تمام ٹرانزیکشنز شامل ہیں۔ +- بیچ میں شمولیت ثابت کرنے کے لیے ٹرانزیکشنز کے لیے مرکل پروف۔ +- ٹرانزیکشنز میں ہر بھیجنے والے-وصول کنندہ جوڑے کے لیے مرکل پروف یہ ثابت کرنے کے لیے کہ وہ اکاؤنٹس رول اپ کے اسٹیٹ ٹری کا حصہ ہیں۔ +- انٹرمیڈیٹ اسٹیٹ روٹس کا ایک سیٹ، جو ہر ٹرانزیکشن کے لیے اسٹیٹ اپ ڈیٹس لاگو کرنے کے بعد اسٹیٹ روٹ کو اپ ڈیٹ کرنے سے حاصل ہوتا ہے (یعنی، بھیجنے والے اکاؤنٹس کو کم کرنا اور وصول کنندہ اکاؤنٹس میں اضافہ کرنا)۔ + +پروفنگ سرکٹ ہر ٹرانزیکشن پر "لوپنگ" کرکے ویلیڈیٹی پروف کا حساب لگاتا ہے اور وہی جانچ پڑتال کرتا ہے جو آپریٹر نے ٹرانزیکشن پر کارروائی کرنے سے پہلے مکمل کی تھی۔ سب سے پہلے، یہ فراہم کردہ مرکل پروف کا استعمال کرتے ہوئے تصدیق کرتا ہے کہ بھیجنے والے کا اکاؤنٹ موجودہ اسٹیٹ روٹ کا حصہ ہے۔ پھر یہ بھیجنے والے کے بیلنس کو کم کرتا ہے، ان کے نونس کو بڑھاتا ہے، اپ ڈیٹ شدہ اکاؤنٹ ڈیٹا کو ہیش کرتا ہے اور اسے مرکل پروف کے ساتھ ملا کر ایک نیا مرکل روٹ تیار کرتا ہے۔ + +یہ مرکل روٹ ZK-rollup کے اسٹیٹ میں واحد تبدیلی کی عکاسی کرتا ہے: بھیجنے والے کے بیلنس اور نونس میں تبدیلی۔ یہ ممکن ہے کیونکہ اکاؤنٹ کے وجود کو ثابت کرنے کے لیے استعمال ہونے والا مرکل پروف نیا اسٹیٹ روٹ حاصل کرنے کے لیے استعمال ہوتا ہے۔ + +پروفنگ سرکٹ وصول کنندہ کے اکاؤنٹ پر بھی یہی عمل انجام دیتا ہے۔ یہ چیک کرتا ہے کہ آیا وصول کنندہ کا اکاؤنٹ انٹرمیڈیٹ اسٹیٹ روٹ کے تحت موجود ہے (مرکل پروف کا استعمال کرتے ہوئے)، ان کے بیلنس کو بڑھاتا ہے، اکاؤنٹ ڈیٹا کو دوبارہ ہیش کرتا ہے اور اسے مرکل پروف کے ساتھ ملا کر ایک نیا اسٹیٹ روٹ تیار کرتا ہے۔ + +یہ عمل ہر ٹرانزیکشن کے لیے دہرایا جاتا ہے؛ ہر "لوپ" بھیجنے والے کے اکاؤنٹ کو اپ ڈیٹ کرنے سے ایک نیا اسٹیٹ روٹ اور وصول کنندہ کے اکاؤنٹ کو اپ ڈیٹ کرنے سے ایک نیا روٹ بناتا ہے۔ جیسا کہ وضاحت کی گئی ہے، اسٹیٹ روٹ میں ہر اپ ڈیٹ رول اپ کے اسٹیٹ ٹری کے ایک حصے کی تبدیلی کی نمائندگی کرتا ہے۔ + +ZK-پروفنگ سرکٹ پورے ٹرانزیکشن بیچ پر اعادہ کرتا ہے، ان اپ ڈیٹس کی ترتیب کی تصدیق کرتا ہے جن کے نتیجے میں آخری ٹرانزیکشن کے عمل میں آنے کے بعد ایک حتمی اسٹیٹ روٹ ہوتا ہے۔ آخری مرکل روٹ جو شمار کیا جاتا ہے وہ ZK-rollup کا جدید ترین کینونیکل اسٹیٹ روٹ بن جاتا ہے۔ + +##### پروف کی تصدیق + +پروفنگ سرکٹ کے اسٹیٹ اپ ڈیٹس کی درستگی کی تصدیق کے بعد، L2 آپریٹر شمار شدہ ویلیڈیٹی پروف کو L1 پر ویریفائر کنٹریکٹ میں جمع کرتا ہے۔ کنٹریکٹ کا تصدیقی سرکٹ پروف کی درستگی کی تصدیق کرتا ہے اور پروف کا حصہ بننے والے عوامی ان پٹس کو بھی چیک کرتا ہے: + +- **پری-اسٹیٹ روٹ**: ZK-rollup کا پرانا اسٹیٹ روٹ (یعنی، بیچڈ ٹرانزیکشنز کے عمل میں آنے سے پہلے)، جو L2 چین کی آخری معلوم درست اسٹیٹ کی عکاسی کرتا ہے۔ + +- **پوسٹ-اسٹیٹ روٹ**: ZK-rollup کا نیا اسٹیٹ روٹ (یعنی، بیچڈ ٹranzیکshnz کے عمل درآمد کے بعد)، جو L2 چین کی جدید ترین اسٹیٹ کی عکاسی کرتا ہے۔ پوسٹ-اسٹیٹ روٹ پروفنگ سرکٹ میں اسٹیٹ اپ ڈیٹس لاگو کرنے کے بعد حاصل ہونے والا حتمی روٹ ہے۔ + +- **بیچ روٹ**: بیچ کا مرکل روٹ، جو بیچ میں ٹرانزیکشنز کو _مرکلائز_ کرکے اور ٹری کے روٹ کو ہیش کرکے حاصل کیا جاتا ہے۔ + +- **ٹرانزیکشن ان پٹس**: جمع کرائے گئے بیچ کے حصے کے طور پر انجام دی گئی ٹرانزیکشنز سے وابستہ ڈیٹا۔ + +اگر پروف سرکٹ کو مطمئن کرتا ہے (یعنی، یہ درست ہے)، تو اس کا مطلب ہے کہ درست ٹرانزیکشنز کا ایک سلسلہ موجود ہے جو رول اپ کو پچھلے اسٹیٹ (کرپٹوگرافک طور پر پری-اسٹیٹ روٹ کے ذریعے فنگر پرنٹ شدہ) سے ایک نئے اسٹیٹ (کرپٹوگرافک طور پر پوسٹ-اسٹیٹ روٹ کے ذریعے فنگر پرنٹ شدہ) میں منتقل کرتا ہے۔ اگر پری-اسٹیٹ روٹ رول اپ کنٹریکٹ میں اسٹور کیے گئے روٹ سے میل کھاتا ہے، اور پروف درست ہے، تو رول اپ کنٹریکٹ پروف سے پوسٹ-اسٹیٹ روٹ لیتا ہے اور رول اپ کی تبدیل شدہ اسٹیٹ کی عکاسی کرنے کے لیے اپنے اسٹیٹ ٹری کو اپ ڈیٹ کرتا ہے۔ + +### اندراج اور اخراج {#entries-and-exits} + +صارفین ZK-rollup میں L1 چین پر ڈیپلائے کیے گئے رول اپ کے کنٹریکٹ میں ٹوکن جمع کرکے داخل ہوتے ہیں۔ یہ ٹرانزیکشن قطار میں لگ جاتی ہے کیونکہ صرف آپریٹرز ہی رول اپ کنٹریکٹ میں ٹرانزیکشنز جمع کرا سکتے ہیں۔ + +اگر زیر التواء ڈپازٹ قطار بھرنے لگتی ہے، تو ZK-rollup آپریٹر ڈپازٹ ٹرانزیکشنز لے کر انہیں رول اپ کنٹریکٹ میں جمع کرائے گا۔ ایک بار جب صارف کے فنڈز رول اپ میں آجائیں، تو وہ پروسیسنگ کے لیے آپریٹر کو ٹرانزیکشنز بھیج کر لین دین شروع کر سکتے ہیں۔ صارفین اپنے اکاؤنٹ ڈیٹا کو ہیش کرکے، ہیش کو رول اپ کنٹریکٹ میں بھیج کر، اور موجودہ اسٹیٹ روٹ کے خلاف تصدیق کے لیے ایک مرکل پروف فراہم کرکے رول اپ پر بیلنس کی تصدیق کر سکتے ہیں۔ + +ZK-rollup سے L1 میں واپسی سیدھی ہے۔ صارف رول اپ پر اپنے اثاثوں کو جلانے کے لیے ایک مخصوص اکاؤنٹ میں بھیج کر ایگزٹ ٹرانزیکشن شروع کرتا ہے۔ اگر آپریٹر ٹرانزیکشن کو اگلے بیچ میں شامل کرتا ہے، تو صارف آن چین کنٹریکٹ میں واپسی کی درخواست جمع کرا سکتا ہے۔ اس واپسی کی درخواست میں درج ذیل شامل ہوں گے: + +- مرکل پروف جو ایک ٹرانزیکشن بیچ میں برن اکاؤنٹ میں صارف کے ٹرانزیکشن کی شمولیت کو ثابت کرتا ہے۔ + +- ٹرانزیکشن ڈیٹا + +- بیچ روٹ + +- جمع شدہ فنڈز وصول کرنے کے لیے L1 ایڈریس + +رول اپ کنٹریکٹ ٹرانزیکشن ڈیٹا کو ہیش کرتا ہے، چیک کرتا ہے کہ آیا بیچ روٹ موجود ہے، اور مرکل پروف کا استعمال کرکے چیک کرتا ہے کہ آیا ٹرانزیکشن ہیش بیچ روٹ کا حصہ ہے۔ اس کے بعد، کنٹریکٹ ایگزٹ ٹرانزیکشن کو انجام دیتا ہے اور فنڈز کو L1 پر صارف کے منتخب کردہ ایڈریس پر بھیجتا ہے۔ + +## ZK-rollups اور EVM مطابقت {#zk-rollups-and-evm-compatibility} + +آپٹیمسٹک رول اپس کے برعکس، ZK-rollups [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) کے ساتھ آسانی سے مطابقت نہیں رکھتے۔ سرکٹس میں عمومی مقصد کے EVM کمپیوٹیشن کو ثابت کرنا سادہ کمپیوٹیشنز (جیسے پہلے بیان کردہ ٹوکن ٹرانسفر) کو ثابت کرنے سے زیادہ مشکل اور وسائل سے بھرپور ہے۔ + +تاہم، [زیرو-نالج ٹیکنالوجی میں ترقی](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) EVM کمپیوٹیشن کو زیرو-نالج پروف میں لپیٹنے میں نئی دلچسپی پیدا کر رہی ہے۔ یہ کوششیں ایک زیرو-نالج EVM (zkEVM) نفاذ بنانے کی طرف مرکوز ہیں جو پروگرام کے عمل کی درستگی کی مؤثر طریقے سے تصدیق کر سکے۔ ایک zkEVM سرکٹس میں ثابت کرنے/تصدیق کرنے کے لیے موجودہ EVM آپ کوڈز کو دوبارہ بناتا ہے، جس سے اسمارٹ کنٹریکٹس پر عمل درآمد کی اجازت ملتی ہے۔ + +EVM کی طرح، ایک zkEVM کچھ ان پٹس پر کمپیوٹیشن کیے جانے کے بعد اسٹیٹس کے درمیان منتقلی کرتا ہے۔ فرق یہ ہے کہ zkEVM پروگرام کے عمل میں ہر قدم کی درستگی کی تصدیق کے لیے زیرو-نالج پروف بھی بناتا ہے۔ ویلیڈیٹی پروف ان آپریشنز کی درستگی کی تصدیق کر سکتے ہیں جو VM کے اسٹیٹ (میموری، اسٹیک، اسٹوریج) اور خود کمپیوٹیشن کو چھوتے ہیں (یعنی، کیا آپریشن نے صحیح آپ کوڈز کو کال کیا اور انہیں صحیح طریقے سے انجام دیا؟)۔ + +EVM-مطابقت رکھنے والے ZK-rollups کے تعارف سے امید کی جاتی ہے کہ وہ ڈویلپرز کو زیرو-نالج پروف کی اسکیل ایبلٹی اور سیکیورٹی ضمانتوں سے فائدہ اٹھانے میں مدد کریں گے۔ زیادہ اہم بات یہ ہے کہ مقامی Ethereum انفراسٹرکچر کے ساتھ مطابقت کا مطلب ہے کہ ڈویلپرز مانوس (اور جنگ میں آزمودہ) ٹولنگ اور زبانوں کا استعمال کرتے ہوئے ZK-دوستانہ dapps بنا سکتے ہیں۔ + +## ZK-rollup فیس کیسے کام کرتی ہے؟ {#how-do-zk-rollup-fees-work} + +ZK-rollups پر ٹرانزیکشنز کے لیے صارفین کتنی رقم ادا کرتے ہیں اس کا انحصار گیس فیس پر ہوتا ہے، بالکل اسی طرح جیسے Ethereum Mainnet پر۔ تاہم، گیس فیس L2 پر مختلف طریقے سے کام کرتی ہے اور درج ذیل اخراجات سے متاثر ہوتی ہے: + +1. **اسٹیٹ رائٹ**: Ethereum کے اسٹیٹ پر لکھنے کے لیے ایک مقررہ لاگت ہے (یعنی، Ethereum بلاک چین پر ایک ٹرانزیکشن جمع کرانا)۔ ZK-rollups ٹرانزیکشنز کو بیچ کرکے اور مقررہ اخراجات کو متعدد صارفین میں تقسیم کرکے اس لاگت کو کم کرتے ہیں۔ + +2. **ڈیٹا پبلیکیشن**: ZK-rollups ہر ٹرانزیکشن کے لیے اسٹیٹ ڈیٹا کو Ethereum پر `calldata` کے طور پر شائع کرتے ہیں۔ `calldata` کی لاگت فی الحال [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) کے زیر انتظام ہے، جو بالترتیب `calldata` کے غیر صفر بائٹس کے لیے 16 گیس اور صفر بائٹس کے لیے 4 گیس کی لاگت کا تعین کرتا ہے۔ ہر ٹرانزیکشن پر ادا کی جانے والی لاگت اس بات سے متاثر ہوتی ہے کہ اس کے لیے آن چین کتنا `calldata` پوسٹ کرنے کی ضرورت ہے۔ + +3. **L2 آپریٹر فیس**: یہ وہ رقم ہے جو رول اپ آپریٹر کو ٹرانزیکشنز پر کارروائی میں ہونے والے کمپیوٹیشنل اخراجات کے معاوضے کے طور پر ادا کی جاتی ہے، بالکل اسی طرح جیسے Ethereum Mainnet پر [ٹرانزیکشن "ترجیحی فیس (ٹپس)"](/developers/docs/gas/#how-are-gas-fees-calculated)۔ + +4. **پروف کی تیاری اور تصدیق**: ZK-rollup آپریٹرز کو ٹرانزیکشن بیچوں کے لیے ویلیڈیٹی پروف تیار کرنا ضروری ہے، جو وسائل سے بھرپور ہے۔ Mainnet پر زیرو-نالج پروف کی تصدیق پر بھی گیس (~ 500,000 گیس) خرچ ہوتی ہے۔ + +ٹرانزیکشنز کو بیچ کرنے کے علاوہ، ZK-rollups ٹرانزیکشن ڈیٹا کو کمپریس کرکے صارفین کے لیے فیس کو کم کرتے ہیں۔ آپ Ethereum ZK-rollups استعمال کرنے کی لاگت کا [ریئل ٹائم جائزہ](https://l2fees.info/) دیکھ سکتے ہیں۔ + +## ZK-rollups Ethereum کو کیسے اسکیل کرتے ہیں؟ {#scaling-ethereum-with-zk-rollups} + +### ٹرانزیکشن ڈیٹا کمپریشن {#transaction-data-compression} + +ZK-rollups کمپیوٹیشن کو آف چین لے کر Ethereum کی بیس لیئر پر تھرو پُٹ کو بڑھاتے ہیں، لیکن اسکیلنگ کے لیے اصل فروغ ٹرانزیکشن ڈیٹا کو کمپریس کرنے سے آتا ہے۔ Ethereum کا [بلاک سائز](/developers/docs/blocks/#block-size) ہر بلاک میں موجود ڈیٹا کی مقدار کو محدود کرتا ہے اور، توسیع کے طور پر، فی بلاک پر کارروائی ہونے والے ٹرانزیکشنز کی تعداد کو۔ ٹرانزیکشن سے متعلقہ ڈیٹا کو کمپریس کرکے، ZK-rollups فی بلاک پر کارروائی ہونے والے ٹرانزیکشنز کی تعداد میں نمایاں اضافہ کرتے ہیں۔ + +ZK-rollups آپٹیمسٹک رول اپس کے مقابلے میں ٹرانزیکشن ڈیٹا کو بہتر طریقے سے کمپریس کر سکتے ہیں کیونکہ انہیں ہر ٹرانزیکشن کی توثیق کے لیے درکار تمام ڈیٹا پوسٹ کرنے کی ضرورت نہیں ہوتی ہے۔ انہیں صرف رول اپ پر اکاؤنٹس اور بیلنس کی تازہ ترین اسٹیٹ کو دوبارہ بنانے کے لیے درکار کم سے کم ڈیٹا پوسٹ کرنا ہوتا ہے۔ + +### ریکرسیو پروفس {#recursive-proofs} + +زیرو-نالج پروف کا ایک فائدہ یہ ہے کہ پروف دوسرے پروف کی تصدیق کر سکتے ہیں۔ مثال کے طور پر، ایک واحد ZK-SNARK دوسرے ZK-SNARKs کی تصدیق کر سکتا ہے۔ ایسے "پروف-آف-پروف" کو ریکرسیو پروف کہا جاتا ہے اور یہ ZK-rollups پر تھرو پُٹ میں ڈرامائی طور پر اضافہ کرتے ہیں۔ + +فی الحال، ویلیڈیٹی پروف بلاک بہ بلاک کی بنیاد پر تیار کیے جاتے ہیں اور تصدیق کے لیے L1 کنٹریکٹ میں جمع کرائے جاتے ہیں۔ تاہم، واحد بلاک پروف کی تصدیق اس تھرو پُٹ کو محدود کرتی ہے جسے ZK-rollups حاصل کر سکتے ہیں کیونکہ جب آپریٹر ایک پروف جمع کرتا ہے تو صرف ایک بلاک کو حتمی شکل دی جا سکتی ہے۔ + +تاہم، ریکرسیو پروف ایک ویلیڈیٹی پروف کے ساتھ کئی بلاکس کو حتمی شکل دینا ممکن بناتے ہیں۔ اس کی وجہ یہ ہے کہ پروفنگ سرکٹ بار بار متعدد بلاک پروف کو جمع کرتا ہے جب تک کہ ایک حتمی پروف نہ بن جائے۔ L2 آپریٹر اس ریکرسیو پروف کو جمع کرتا ہے، اور اگر کنٹریکٹ اسے قبول کرتا ہے، تو تمام متعلقہ بلاکس فوری طور پر حتمی شکل اختیار کر لیں گے۔ ریکرسیو پروف کے ساتھ، ZK-rollup ٹرانزیکشنز کی تعداد جو وقفوں پر Ethereum پر حتمی شکل دی جا سکتی ہے، بڑھ جاتی ہے۔ + +### ZK-rollups کے فائدے اور نقصانات {#zk-rollups-pros-and-cons} + +| فوائد | نقصانات | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ویلیڈیٹی پروف آف چین ٹرانزیکشنز کی درستگی کو یقینی بناتے ہیں اور آپریٹرز کو غلط اسٹیٹ ٹرانزیشن پر عمل کرنے سے روکتے ہیں۔ | ویلیڈیٹی پروف کو کمپیوٹ کرنے اور تصدیق کرنے سے وابستہ لاگت کافی زیادہ ہے اور یہ رول اپ صارفین کے لیے فیس میں اضافہ کر سکتی ہے۔ | +| تیز تر ٹرانزیکشن کی حتمیت پیش کرتا ہے کیونکہ L1 پر ویلیڈیٹی پروف کی تصدیق کے بعد اسٹیٹ اپ ڈیٹس منظور ہو جاتی ہیں۔ | زیرو-نالج ٹیکنالوجی کی پیچیدگی کی وجہ سے EVM-مطابقت رکھنے والے ZK-rollups بنانا مشکل ہے۔ | +| سیکیورٹی کے لیے بغیر اعتماد کے کرپٹوگرافک میکانزم پر انحصار کرتا ہے، نہ کہ [آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons) کی طرح مراعات یافتہ اداکاروں کی ایمانداری پر۔ | ویلیڈیٹی پروف تیار کرنے کے لیے خصوصی ہارڈویئر کی ضرورت ہوتی ہے، جو چند پارٹیوں کے ذریعے چین کے مرکزی کنٹرول کی حوصلہ افزائی کر سکتا ہے۔ | +| آف چین اسٹیٹ کو بحال کرنے کے لیے درکار ڈیٹا کو L1 پر اسٹور کرتا ہے، جو سیکیورٹی، سنسرشپ-مزاحمت، اور ڈی سینٹرلائزیشن کی ضمانت دیتا ہے۔ | مرکزی آپریٹرز (سیکوینسرز) ٹرانزیکشنز کی ترتیب کو متاثر کر سکتے ہیں۔ | +| صارفین زیادہ کیپٹل کی کارکردگی سے فائدہ اٹھاتے ہیں اور بغیر کسی تاخیر کے L2 سے فنڈز نکال سکتے ہیں۔ | ہارڈویئر کی ضروریات شرکاء کی تعداد کو کم کر سکتی ہیں جو چین کو پیشرفت کرنے پر مجبور کر سکتے ہیں، جس سے بدنیتی پر مبنی آپریٹرز کے رول اپ کی اسٹیٹ کو منجمد کرنے اور صارفین کو سنسر کرنے کا خطرہ بڑھ جاتا ہے۔ | +| لائیونس مفروضوں پر انحصار نہیں کرتا اور صارفین کو اپنے فنڈز کی حفاظت کے لیے چین کی توثیق کرنے کی ضرورت نہیں ہے۔ | کچھ پروفنگ سسٹمز (مثلاً، ZK-SNARK) کو ایک قابل اعتماد سیٹ اپ کی ضرورت ہوتی ہے، جسے اگر غلط طریقے سے ہینڈل کیا جائے تو یہ ممکنہ طور پر ZK-rollup کے سیکیورٹی ماڈل سے سمجھوتہ کر سکتا ہے۔ | +| بہتر ڈیٹا کمپریشن Ethereum پر `calldata` شائع کرنے کے اخراجات کو کم کرنے اور صارفین کے لیے رول اپ فیس کو کم کرنے میں مدد کر سکتا ہے۔ | | + +### ZK-rollups کی ایک بصری وضاحت {#zk-video} + +Finematics کو ZK-rollups کی وضاحت کرتے ہوئے دیکھیں: + + + +## zkEVM پر کون کام کر رہا ہے؟ {#zkevm-projects} + +zkEVMs پر کام کرنے والے پروجیکٹس میں شامل ہیں: + +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM ایک پروجیکٹ ہے جسے Ethereum فاؤنڈیشن نے EVM-کمپٹیبل ZK-rollup اور Ethereum بلاکس کے لیے ویلیڈیٹی پروف بنانے کے لیے ایک میکانزم تیار کرنے کے لیے فنڈ کیا ہے۔_ + +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _Ethereum mainnet پر ایک ڈی سینٹرلائزڈ ZK Rollup ہے جو ایک زیرو-نالج Ethereum Virtual Machine (zkEVM) پر کام کر رہا ہے جو Ethereum ٹرانزیکشنز کو شفاف طریقے سے انجام دیتا ہے، بشمول زیرو-نالج-پروف توثیق کے ساتھ اسمارٹ کنٹریکٹس۔_ + +- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll ایک ٹیک پر مبنی کمپنی ہے جو Ethereum کے لیے ایک مقامی zkEVM لیئر 2 حل بنانے پر کام کر رہی ہے۔_ + +- **[Taiko](https://taiko.xyz)** - _Taiko ایک ڈی سینٹرلائزڈ، Ethereum-ایکویلینٹ ZK-rollup (ایک [Type 1 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)) ہے۔_ + +- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era ایک EVM-مطابقت رکھنے والا ZK Rollup ہے جسے Matter Labs نے بنایا ہے، جو اس کے اپنے zkEVM سے چلتا ہے۔_ + +- **[Starknet](https://starkware.co/starknet/)** - _StarkNet ایک EVM-مطابقت رکھنے والا لیئر 2 اسکیلنگ حل ہے جسے StarkWare نے بنایا ہے۔_ + +- **[Morph](https://www.morphl2.io/)** - _Morph ایک ہائبرڈ رول اپ اسکیلنگ حل ہے جو لیئر 2 اسٹیٹ چیلنج کے مسئلے کو حل کرنے کے لیے zk-پروف کا استعمال کرتا ہے۔_ + +- **[Linea](https://linea.build)** - _Linea ایک Ethereum-equivalent zkEVM Layer 2 ہے جسے Consensys نے بنایا ہے، جو Ethereum ایکو سسٹم کے ساتھ مکمل طور پر ہم آہنگ ہے۔_ + +## ZK-rollups پر مزید پڑھنا {#further-reading-on-zk-rollups} + +- [زیرو-نالج رول اپس کیا ہیں؟](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) +- [زیرو-نالج رول اپس کیا ہیں؟](https://alchemy.com/blog/zero-knowledge-rollups) +- [ایتھیریم رولپس کے لیے عملی گائیڈ](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [STARKs بمقابلہ SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [ایک zkEVM کیا ہے؟](https://www.alchemy.com/overviews/zkevm) +- [ZK-EVM اقسام: Ethereum-equivalent, EVM-equivalent, Type 1, Type 4, اور دیگر کرپٹک بزورڈز](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [zkEVM کا تعارف](https://hackmd.io/@yezhang/S1_KMMbGt) +- [ZK-EVM L2s کیا ہیں؟](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) +- [Awesome-zkEVM وسائل](https://github.com/LuozhuZhang/awesome-zkevm) +- [پردے کے پیچھے ZK-SNARKS](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) +- [SNARKs کیسے ممکن ہیں؟](https://vitalik.eth.limo/general/2021/01/26/snarks.html) 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/) diff --git a/public/content/translations/ur/developers/docs/transactions/index.md b/public/content/translations/ur/developers/docs/transactions/index.md new file mode 100644 index 00000000000..b1e028603be --- /dev/null +++ b/public/content/translations/ur/developers/docs/transactions/index.md @@ -0,0 +1,231 @@ +--- +title: "ٹرانزیکشنز" +description: "ایتھیریم ٹرانزیکشنز کا ایک جائزہ – وہ کیسے کام کرتے ہیں، ان کا ڈیٹا اسٹرکچر، اور انہیں کسی ایپلیکیشن کے ذریعے کیسے بھیجا جائے۔" +lang: ur-in +--- + +ٹرانزیکشنز اکاؤنٹس سے بھیجی گئی کرپٹوگرافک طور پر دستخط شدہ ہدایات ہیں۔ ایک اکاؤنٹ ایتھیریم نیٹ ورک کی حالت کو اپ ڈیٹ کرنے کے لیے ایک ٹرانزیکشن شروع کرے گا۔ سب سے آسان ٹرانزیکشن ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں ETH منتقل کرنا ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے میں آپ کی مدد کرنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [اکاؤنٹس](/developers/docs/accounts/) اور ہمارا [ایتھیریم کا تعارف](/developers/docs/intro-to-ethereum/) پڑھیں۔ + +## ٹرانزیکشن کیا ہے؟ {#whats-a-transaction} + +ایتھیریم ٹرانزیکشن سے مراد ایک بیرونی ملکیت والے اکاؤنٹ کے ذریعے شروع کی گئی کارروائی ہے، دوسرے الفاظ میں ایک ایسا اکاؤنٹ جسے انسان کے ذریعے منظم کیا جاتا ہے، نہ کہ کسی کنٹریکٹ کے ذریعے۔ مثال کے طور پر، اگر باب ایلس کو 1 ETH بھیجتا ہے، تو باب کے اکاؤنٹ سے ڈیبٹ ہونا چاہیے اور ایلس کے اکاؤنٹ میں کریڈٹ ہونا چاہیے۔ یہ حالت بدلنے والی کارروائی ایک ٹرانزیکشن کے اندر ہوتی ہے۔ + +![ٹرانزیکشن کی وجہ سے حالت میں تبدیلی کو ظاہر کرنے والا ڈایاگرام](./tx.png) +_[ایتھیریم EVM کی تصویری وضاحت](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے لیا گیا ڈایاگرام_ + +ٹرانزیکشنز، جو EVM کی حالت کو تبدیل کرتی ہیں، کو پورے نیٹ ورک پر براڈکاسٹ کرنے کی ضرورت ہوتی ہے۔ کوئی بھی نوڈ EVM پر ٹرانزیکشن کو انجام دینے کی درخواست کو براڈکاسٹ کر سکتا ہے؛ اس کے بعد، ایک ویلیڈیٹر ٹرانزیکشن کو انجام دے گا اور نتیجے میں ہونے والی حالت کی تبدیلی کو باقی نیٹ ورک تک پھیلائے گا۔ + +ٹرانزیکشنز کے لیے فیس درکار ہوتی ہے اور انہیں ایک توثیق شدہ بلاک میں شامل کیا جانا چاہیے۔ اس جائزے کو آسان بنانے کے لیے ہم گیس فیس اور توثیق کو کہیں اور کور کریں گے۔ + +جمع کرائی گئی ٹرانزیکشن میں درج ذیل معلومات شامل ہوتی ہیں: + +- `from` – بھیجنے والے کا پتہ، جو ٹرانزیکشن پر دستخط کرے گا۔ یہ ایک بیرونی ملکیت والا اکاؤنٹ ہوگا کیونکہ کنٹریکٹ اکاؤنٹس ٹرانزیکشن نہیں بھیج سکتے۔ +- `to` – وصول کرنے والا پتہ (اگر ایک بیرونی ملکیت والا اکاؤنٹ ہے، تو ٹرانزیکشن قدر منتقل کرے گا۔ اگر ایک کنٹریکٹ اکاؤنٹ ہے، تو ٹرانزیکشن کنٹریکٹ کوڈ کو انجام دے گی) +- `signature` – بھیجنے والے کی شناخت کنندہ۔ یہ اس وقت پیدا ہوتا ہے جب بھیجنے والے کی نجی کلید ٹرانزیکشن پر دستخط کرتی ہے اور تصدیق کرتی ہے کہ بھیجنے والے نے اس ٹرانزیکشن کی اجازت دی ہے۔ +- `nonce` - ایک ترتیب سے بڑھنے والا کاؤنٹر جو اکاؤنٹ سے ٹرانزیکشن نمبر کی نشاندہی کرتا ہے۔ +- `value` – بھیجنے والے سے وصول کنندہ کو منتقل کی جانے والی ETH کی رقم (WEI میں ظاہر کی گئی، جہاں 1ETH برابر ہے 1e+18wei کے) +- `input data` – صوابدیدی ڈیٹا شامل کرنے کے لیے اختیاری فیلڈ۔ +- `gasLimit` – گیس یونٹس کی زیادہ سے زیادہ مقدار جو ٹرانزیکشن کے ذریعے استعمال کی جا سکتی ہے۔ [EVM](/developers/docs/evm/opcodes) ہر حسابی مرحلے کے لیے درکار گیس کی اکائیوں کی وضاحت کرتا ہے۔ +- `maxPriorityFeePerGas` - استعمال شدہ گیس کی زیادہ سے زیادہ قیمت جو ویلیڈیٹر کو ٹپ کے طور پر شامل کی جائے گی۔ +- `maxFeePerGas` - ٹرانزیکشن کے لیے ادا کی جانے والی فی یونٹ گیس کی زیادہ سے زیادہ فیس (`baseFeePerGas` اور `maxPriorityFeePerGas` سمیت)۔ + +گیس اس حساب کا حوالہ ہے جو ایک ویلیڈیٹر کے ذریعے ٹرانزیکشن پر کارروائی کرنے کے لیے درکار ہوتا ہے۔ صارفین کو اس حساب کے لیے فیس ادا کرنی ہوتی ہے۔ `gasLimit`، اور `maxPriorityFeePerGas` ویلیڈیٹر کو ادا کی جانے والی زیادہ سے زیادہ ٹرانزیکشن فیس کا تعین کرتے ہیں۔ [گیس پر مزید](/developers/docs/gas/). + +ٹرانزیکشن آبجیکٹ کچھ اس طرح نظر آئے گا: + +```js +{ + from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8", + to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a", + gasLimit: "21000", + maxFeePerGas: "300", + maxPriorityFeePerGas: "10", + nonce: "0", + value: "10000000000" +} +``` + +لیکن ایک ٹرانزیکشن آبجیکٹ کو بھیجنے والے کی نجی کلید کا استعمال کرتے ہوئے دستخط کرنے کی ضرورت ہوتی ہے۔ یہ ثابت کرتا ہے کہ ٹرانزیکشن صرف بھیجنے والے کی طرف سے آسکتی تھی اور دھوکہ دہی سے نہیں بھیجی گئی تھی۔ + +ایک ایتھیریم کلائنٹ جیسے Geth اس دستخطی عمل کو سنبھالے گا۔ + +مثال [JSON-RPC](/developers/docs/apis/json-rpc) کال: + +```json +{ + "id": 2, + "jsonrpc": "2.0", + "method": "account_signTransaction", + "params": [ + { + "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db", + "gas": "0x55555", + "maxFeePerGas": "0x1234", + "maxPriorityFeePerGas": "0x1234", + "input": "0xabcd", + "nonce": "0x0", + "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", + "value": "0x1234" + } + ] +} +``` + +مثال کے طور پر جواب: + +```json +{ + "jsonrpc": "2.0", + "id": 2, + "result": { + "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", + "tx": { + "nonce": "0x0", + "maxFeePerGas": "0x1234", + "maxPriorityFeePerGas": "0x1234", + "gas": "0x55555", + "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", + "value": "0x1234", + "input": "0xabcd", + "v": "0x26", + "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e", + "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", + "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e" + } + } +} +``` + +- `raw` دستخط شدہ ٹرانزیکشن ہے [ریکرسیو لینتھ پریفکس (RLP)](/developers/docs/data-structures-and-encoding/rlp) انکوڈ شدہ شکل میں۔ +- `tx` دستخط شدہ ٹرانزیکشن JSON شکل میں ہے۔ + +دستخطی ہیش کے ساتھ، ٹرانزیکشن کو کرپٹوگرافک طور پر ثابت کیا جا سکتا ہے کہ یہ بھیجنے والے کی طرف سے آئی ہے اور نیٹ ورک پر جمع کرائی گئی ہے۔ + +### ڈیٹا فیلڈ {#the-data-field} + +ٹرانزیکشنز کی بڑی اکثریت ایک بیرونی ملکیت والے اکاؤنٹ سے ایک کنٹریکٹ تک رسائی حاصل کرتی ہے۔ +زیادہ تر کنٹریکٹس Solidity میں لکھے جاتے ہیں اور اپنے ڈیٹا فیلڈ کی تشریح [ایپلیکیشن بائنری انٹرفیس (ABI)](/glossary/#abi) کے مطابق کرتے ہیں۔ + +پہلے چار بائٹس یہ بتاتے ہیں کہ کون سا فنکشن کال کرنا ہے، فنکشن کے نام اور دلائل کے ہیش کا استعمال کرتے ہوئے۔ +آپ کبھی کبھی [اس ڈیٹا بیس](https://www.4byte.directory/signatures/) کا استعمال کرتے ہوئے سلیکٹر سے فنکشن کی شناخت کر سکتے ہیں۔ + +باقی کال ڈیٹا دلائل ہیں، [ABI کی خصوصیات میں بیان کردہ کے مطابق انکوڈ شدہ](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)۔ + +مثال کے طور پر، آئیے [اس ٹرانزیکشن](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1) کو دیکھتے ہیں۔ +کال ڈیٹا دیکھنے کے لیے **مزید دیکھنے کے لیے کلک کریں** استعمال کریں۔ + +فنکشن سلیکٹر `0xa9059cbb` ہے۔ اس دستخط کے ساتھ کئی [معروف فنکشنز](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb) ہیں۔ +اس صورت میں [کنٹریکٹ کا سورس کوڈ](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) Etherscan پر اپ لوڈ کیا گیا ہے، لہذا ہم جانتے ہیں کہ فنکشن `transfer(address,uint256)` ہے۔ + +باقی ڈیٹا یہ ہے: + +``` +0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279 +000000000000000000000000000000000000000000000000000000003b0559f4 +``` + +ABI کی خصوصیات کے مطابق، انٹیجر ویلیوز (جیسے کہ ایڈریس، جو 20 بائٹ انٹیجرز ہیں) ABI میں 32 بائٹ کے الفاظ کے طور پر ظاہر ہوتے ہیں، جن کے سامنے صفر کے ساتھ پیڈنگ کی جاتی ہے۔ +لہذا ہم جانتے ہیں کہ `to` ایڈریس [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279) ہے۔ +`value` 0x3b0559f4 = 990206452 ہے۔ + +## ٹرانزیکشنز کی اقسام {#types-of-transactions} + +ایتھیریم پر چند مختلف قسم کی ٹرانزیکشنز ہوتی ہیں: + +- باقاعدہ ٹرانزیکشنز: ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں ایک ٹرانزیکشن۔ +- کنٹریکٹ کی تعیناتی کی ٹرانزیکشنز: ایک 'to' ایڈریس کے بغیر ایک ٹرانزیکشن، جہاں ڈیٹا فیلڈ کنٹریکٹ کوڈ کے لیے استعمال ہوتا ہے۔ +- کنٹریکٹ کا نفاذ: ایک ٹرانزیکشن جو ایک تعینات شدہ اسمارٹ کنٹریکٹ کے ساتھ تعامل کرتی ہے۔ اس صورت میں، 'to' ایڈریس اسمارٹ کنٹریکٹ ایڈریس ہے۔ + +### گیس پر {#on-gas} + +جیسا کہ ذکر کیا گیا ہے، ٹرانزیکشنز کو انجام دینے کے لیے [گیس](/developers/docs/gas/) کی لاگت آتی ہے۔ سادہ منتقلی کی ٹرانزیکشنز کے لیے 21000 یونٹ گیس درکار ہوتی ہے۔ + +لہذا باب کو ایلس کو 190 gwei کے `baseFeePerGas` اور 10 gwei کے `maxPriorityFeePerGas` پر 1 ETH بھیجنے کے لیے، باب کو درج ذیل فیس ادا کرنی ہوگی: + +``` +(190 + 10) * 21000 = 4,200,000 gwei +--or-- +0.0042 ETH +``` + +باب کے اکاؤنٹ سے **-1.0042 ETH** ڈیبٹ کیا جائے گا (ایلس کے لیے 1 ETH + گیس فیس میں 0.0042 ETH) + +ایلس کے اکاؤنٹ میں **+1.0 ETH** کریڈٹ کیا جائے گا۔ + +بیس فیس **-0.00399 ETH** جلا دی جائے گی۔ + +ویلیڈیٹر ٹپ **+0.000210 ETH** رکھتا ہے۔ + +![ڈایاگرام جس میں دکھایا گیا ہے کہ غیر استعمال شدہ گیس کیسے واپس کی جاتی ہے](./gas-tx.png) +_[ایتھیریم EVM کی تصویری وضاحت](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) سے لیا گیا ڈایاگرام_ + +کسی ٹرانزیکشن میں استعمال نہ ہونے والی کوئی بھی گیس صارف کے اکاؤنٹ میں واپس کر دی جاتی ہے۔ + +### اسمارٹ کنٹریکٹ کے تعاملات {#smart-contract-interactions} + +کسی بھی ٹرانزیکشن کے لیے گیس درکار ہے جس میں اسمارٹ کنٹریکٹ شامل ہو۔ + +اسمارٹ کنٹریکٹس میں [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) یا [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) فنکشنز کے نام سے جانے جانے والے فنکشنز بھی شامل ہو سکتے ہیں، جو کنٹریکٹ کی حالت کو تبدیل نہیں کرتے ہیں۔ اس طرح، EOA سے ان فنکشنز کو کال کرنے کے لیے کسی گیس کی ضرورت نہیں ہوگی۔ اس منظر نامے کے لیے بنیادی RPC کال [`eth_call`](/developers/docs/apis/json-rpc#eth_call) ہے۔ + +`eth_call` کا استعمال کرتے ہوئے رسائی حاصل کرنے کے برعکس، یہ `view` یا `pure` فنکشنز عام طور پر اندرونی طور پر بھی کال کیے جاتے ہیں (یعنی، خود کنٹریکٹ سے یا کسی دوسرے کنٹریکٹ سے) جس پر گیس کی لاگت آتی ہے۔ + +## ٹرانزیکشن لائف سائیکل {#transaction-lifecycle} + +ایک بار ٹرانزیکشن جمع ہو جانے کے بعد درج ذیل ہوتا ہے: + +1. ایک ٹرانزیکشن ہیش کرپٹوگرافک طور پر تیار کیا جاتا ہے: + `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` +2. اس کے بعد ٹرانزیکشن کو نیٹ ورک پر براڈکاسٹ کیا جاتا ہے اور ایک ٹرانزیکشن پول میں شامل کیا جاتا ہے جس میں دیگر تمام زیر التواء نیٹ ورک ٹرانزیکشنز شامل ہوتے ہیں۔ +3. ایک ویلیڈیٹر کو آپ کی ٹرانزیکشن کو منتخب کرنا ہوگا اور اسے ٹرانزیکشن کی تصدیق کرنے اور اسے "کامیاب" سمجھنے کے لیے ایک بلاک میں شامل کرنا ہوگا۔ +4. جیسے جیسے وقت گزرتا ہے آپ کی ٹرانزیکشن پر مشتمل بلاک کو "جواز" پھر "حتمی" میں اپ گریڈ کر دیا جائے گا۔ یہ اپ گریڈ اس بات کو بہت زیادہ یقینی بناتے ہیں کہ آپ کی ٹرانزیکشن کامیاب تھی اور اسے کبھی تبدیل نہیں کیا جائے گا۔ ایک بار جب کوئی بلاک "حتمی" ہو جاتا ہے تو اسے صرف ایک نیٹ ورک سطح کے حملے سے ہی تبدیل کیا جا سکتا ہے جس پر کئی بلین ڈالر لاگت آئے گی۔ + +## ایک بصری ڈیمو {#a-visual-demo} + +آسٹن کو ٹرانزیکشنز، گیس، اور مائننگ کے بارے میں بتاتے ہوئے دیکھیں۔ + + + +## ٹائپ شدہ ٹرانزیکشن انویلپ {#typed-transaction-envelope} + +ایتھیریم میں اصل میں ٹرانزیکشنز کے لیے ایک ہی فارمیٹ تھا۔ ہر ٹرانزیکشن میں ایک نانس، گیس کی قیمت، گیس کی حد، ٹو ایڈریس، ویلیو، ڈیٹا، v، r، اور s شامل ہوتے تھے۔ یہ فیلڈز [RLP-انکوڈڈ](/developers/docs/data-structures-and-encoding/rlp/) ہیں، جو کچھ اس طرح نظر آتے ہیں: + +`RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` + +ایتھیریم نے کئی قسم کی ٹرانزیکشنز کو سپورٹ کرنے کے لیے ترقی کی ہے تاکہ ایکسیس لسٹ اور [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) جیسی نئی خصوصیات کو پرانے ٹرانزیکشن فارمیٹس کو متاثر کیے بغیر نافذ کیا جا سکے۔ + +[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) وہی ہے جو اس طرز عمل کی اجازت دیتا ہے۔ ٹرانزیکشنز کی تشریح اس طرح کی جاتی ہے: + +`TransactionType || TransactionPayload` + +جہاں فیلڈز کی تعریف اس طرح کی گئی ہے: + +- `TransactionType` - 0 اور 0x7f کے درمیان ایک عدد، کل 128 ممکنہ ٹرانزیکشن اقسام کے لیے۔ +- `TransactionPayload` - ٹرانزیکشن کی قسم کے ذریعے بیان کردہ ایک صوابدیدی بائٹ ارے۔ + +`TransactionType` قدر کی بنیاد پر، ایک ٹرانزیکشن کو اس طرح درجہ بندی کیا جا سکتا ہے: + +1. **قسم 0 (لیگیسی) ٹرانزیکشنز:** ایتھیریم کے آغاز کے بعد سے استعمال ہونے والا اصل ٹرانزیکشن فارمیٹ۔ ان میں [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) کی خصوصیات شامل نہیں ہیں جیسے ڈائنامک گیس فیس کا حساب یا اسمارٹ کنٹریکٹس کے لیے ایکسیس لسٹ۔ لیگیسی ٹرانزیکشنز میں ان کی سیریلائزڈ شکل میں ان کی قسم کی نشاندہی کرنے والے ایک مخصوص پریفکس کی کمی ہوتی ہے، جو [ریکرسیو لینتھ پریفکس (RLP)](/developers/docs/data-structures-and-encoding/rlp) انکوڈنگ کا استعمال کرتے وقت بائٹ `0xf8` سے شروع ہوتی ہے۔ ان ٹرانزیکشنز کے لیے TransactionType کی قدر `0x0` ہے۔ + +2. **قسم 1 ٹرانزیکشنز:** ایتھیریم کے [برلن اپ گریڈ](/ethereum-forks/#berlin) کے حصے کے طور پر [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) میں متعارف کرائی گئیں، ان ٹرانزیکشنز میں ایک `accessList` پیرامیٹر شامل ہے۔ یہ فہرست ان پتوں اور اسٹوریج کیز کی وضاحت کرتی ہے جن تک ٹرانزیکشن رسائی کی توقع رکھتی ہے، جو اسمارٹ کنٹریکٹس پر مشتمل پیچیدہ ٹرانزیکشنز کے لیے ممکنہ طور پر [گیس](/developers/docs/gas/) کے اخراجات کو کم کرنے میں مدد کرتی ہے۔ EIP-1559 فیس مارکیٹ کی تبدیلیاں قسم 1 کی ٹرانزیکشنز میں شامل نہیں ہیں۔ قسم 1 کی ٹرانزیکشنز میں ایک `yParity` پیرامیٹر بھی شامل ہوتا ہے، جو یا تو `0x0` یا `0x1` ہو سکتا ہے، جو secp256k1 دستخط کی y-value کی پیریٹی کی نشاندہی کرتا ہے۔ ان کی شناخت بائٹ `0x01` سے شروع ہونے سے ہوتی ہے، اور ان کی TransactionType کی قدر `0x1` ہے۔ + +3. **قسم 2 ٹرانزیکشنز**، جنہیں عام طور پر EIP-1559 ٹرانزیکشنز کہا جاتا ہے، وہ ٹرانزیکشنز ہیں جو ایتھیریم کے [لندن اپ گریڈ](/ethereum-forks/#london) میں، [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) میں متعارف کرائی گئی ہیں۔ وہ ایتھیریم نیٹ ورک پر معیاری ٹرانزیکشن کی قسم بن گئے ہیں۔ یہ ٹرانزیکشنز ایک نیا فیس مارکیٹ میکانزم متعارف کراتے ہیں جو ٹرانزیکشن فیس کو ایک بیس فیس اور ایک ترجیحی فیس میں الگ کرکے پیشین گوئی کو بہتر بناتا ہے۔ وہ بائٹ `0x02` سے شروع ہوتے ہیں اور ان میں `maxPriorityFeePerGas` اور `maxFeePerGas` جیسے فیلڈز شامل ہوتے ہیں۔ قسم 2 کی ٹرانزیکشنز اب ان کی لچک اور کارکردگی کی وجہ سے ڈیفالٹ ہیں، خاص طور پر زیادہ نیٹ ورک کی بھیڑ کے دوران ان کی صارفین کو ٹرانزیکشن فیس کو زیادہ پیشین گوئی کے ساتھ منظم کرنے میں مدد کرنے کی صلاحیت کی وجہ سے پسند کی جاتی ہیں۔ ان ٹرانزیکشنز کے لیے TransactionType کی قدر `0x2` ہے۔ + +4. **قسم 3 (بلاب) ٹرانزیکشنز** ایتھیریم کے [Dencun اپ گریڈ](/ethereum-forks/#dencun) کے حصے کے طور پر [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) میں متعارف کرائی گئیں۔ یہ ٹرانزیکشنز "blob" ڈیٹا (بائنری لارج آبجیکٹس) کو زیادہ مؤثر طریقے سے ہینڈل کرنے کے لیے ڈیزائن کی گئی ہیں، خاص طور پر Layer 2 رول اپس کو کم قیمت پر ایتھیریم نیٹ ورک پر ڈیٹا پوسٹ کرنے کا ایک طریقہ فراہم کرکے فائدہ پہنچاتی ہیں۔ بلاب ٹرانزیکشنز میں اضافی فیلڈز جیسے `blobVersionedHashes`، `maxFeePerBlobGas`، اور `blobGasPrice` شامل ہیں۔ وہ بائٹ `0x03` سے شروع ہوتے ہیں، اور ان کی TransactionType کی قدر `0x3` ہے۔ بلاب ٹرانزیکشنز ایتھیریم کی ڈیٹا کی دستیابی اور اسکیلنگ کی صلاحیتوں میں ایک اہم بہتری کی نمائندگی کرتی ہیں۔ + +5. **قسم 4 ٹرانزیکشنز** ایتھیریم کے [Pectra اپ گریڈ](/roadmap/pectra/) کے حصے کے طور پر [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) میں متعارف کرائی گئیں۔ یہ ٹرانزیکشنز اکاؤنٹ ابسٹریکشن کے ساتھ فارورڈ-کمپیٹیبل ہونے کے لیے ڈیزائن کی گئی ہیں۔ وہ EOAs کو اپنی اصل فعالیت پر سمجھوتہ کیے بغیر عارضی طور پر اسمارٹ کنٹریکٹ اکاؤنٹس کی طرح برتاؤ کرنے کی اجازت دیتے ہیں۔ ان میں ایک `authorization_list` پیرامیٹر شامل ہوتا ہے، جو اس اسمارٹ کنٹریکٹ کی وضاحت کرتا ہے جس پر EOA اپنے اختیار کو تفویض کرتا ہے۔ ٹرانزیکشن کے بعد، EOA کے کوڈ فیلڈ میں تفویض کردہ اسمارٹ کنٹریکٹ کا پتہ ہوگا۔ + +## مزید پڑھیں {#further-reading} + +- [EIP-2718: ٹائپ شدہ ٹرانزیکشن انویلپ](https://eips.ethereum.org/EIPS/eip-2718) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [اکاؤنٹس](/developers/docs/accounts/) +- [ایتھیریم ورچوئل مشین (EVM)](/developers/docs/evm/) +- [گیس](/developers/docs/gas/) diff --git a/public/content/translations/ur/developers/docs/web2-vs-web3/index.md b/public/content/translations/ur/developers/docs/web2-vs-web3/index.md new file mode 100644 index 00000000000..34be732efcf --- /dev/null +++ b/public/content/translations/ur/developers/docs/web2-vs-web3/index.md @@ -0,0 +1,62 @@ +--- +title: "ویب 2 بمقابلہ ویب 3" +description: "ایتھیریم بلاک چین ٹیکنالوجی پر مبنی مرکزی ویب 2 خدمات کا غیر مرکزی ویب 3 ایپلیکیشنز سے موازنہ کریں۔" +lang: ur-in +--- + +ویب 2 سے مراد انٹرنیٹ کا وہ ورژن ہے جسے آج ہم میں سے بیشتر جانتے ہیں۔ ایک ایسا انٹرنیٹ جس پر ایسی کمپنیوں کا غلبہ ہے جو آپ کے ذاتی ڈیٹا کے بدلے خدمات فراہم کرتی ہیں۔ ویب 3، ایتھیریم کے تناظر میں، ان غیر مرکزی ایپس سے مراد ہے جو بلاک چین پر چلتی ہیں۔ یہ وہ ایپس ہیں جو کسی کو بھی ان کے ذاتی ڈیٹا سے پیسہ کمائے بغیر حصہ لینے کی اجازت دیتی ہیں۔ + +کیا آپ مبتدیوں کے لیے زیادہ موزوں وسیلہ تلاش کر رہے ہیں؟ ہمارا [ویب 3 کا تعارف](/web3/) دیکھیں۔ + +## ویب 3 کے فوائد {#web3-benefits} + +بہت سے ویب 3 ڈیولپرز نے ایتھیریم کی موروثی غیر مرکزیت کی وجہ سے ڈی ایپس بنانے کا انتخاب کیا ہے: + +- نیٹ ورک پر موجود ہر شخص کو سروس استعمال کرنے کی اجازت ہے – یا دوسرے لفظوں میں، اجازت کی ضرورت نہیں ہے۔ +- کوئی بھی آپ کو بلاک نہیں کر سکتا یا سروس تک رسائی سے انکار نہیں کر سکتا۔ +- ادائیگیاں مقامی ٹوکن، ایتھر (ETH) کے ذریعے اس میں شامل ہیں۔ +- ایتھیریم ٹیورنگ-کمپلیٹ ہے، جس کا مطلب ہے کہ آپ تقریباً کچھ بھی پروگرام کر سکتے ہیں۔ + +## عملی موازنے {#practical-comparisons} + +| ویب 2 | Web3 | +| ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | +| ٹویٹر کسی بھی اکاؤنٹ یا ٹویٹ کو سنسر کر سکتا ہے | ویب 3 ٹویٹس کو سنسر نہیں کیا جا سکے گا کیونکہ کنٹرول غیر مرکزی ہوتا ہے | +| ادائیگی کی سروس کچھ خاص قسم کے کاموں کے لیے ادائیگیوں کی اجازت نہ دینے کا فیصلہ کر سکتی ہے | ویب 3 ادائیگی ایپس کو کسی ذاتی ڈیٹا کی ضرورت نہیں ہوتی اور وہ ادائیگیوں کو نہیں روک سکتیں | +| گگ اکانومی ایپس کے سرورز ڈاؤن ہو سکتے ہیں اور کارکنوں کی آمدنی کو متاثر کر سکتے ہیں | ویب 3 سرورز ڈاؤن نہیں ہو سکتے – وہ اپنے بیک اینڈ کے طور پر ایتھیریم، جو ہزاروں کمپیوٹرز کا ایک غیر مرکزی نیٹ ورک ہے، کا استعمال کرتے ہیں | + +اس کا مطلب یہ نہیں ہے کہ تمام خدمات کو ڈی ایپ میں تبدیل کرنے کی ضرورت ہے۔ یہ مثالیں ویب 2 اور ویب 3 خدمات کے درمیان اہم فرق کو واضح کرتی ہیں۔ + +## ویب 3 کی حدود {#web3-limitations} + +ویب 3 کی ابھی کچھ حدود ہیں: + +- اسکیل ایبلیٹی – ویب 3 پر ٹرانزیکشنز سست ہیں کیونکہ وہ غیر مرکزی ہیں۔ حالت میں تبدیلیوں، جیسے کہ ادائیگی، کو ایک نوڈ کے ذریعے پراسیس کرنے اور پورے نیٹ ورک میں پھیلانے کی ضرورت ہوتی ہے۔ +- یو ایکس – ویب 3 ایپلیکیشنز کے ساتھ تعامل کرنے کے لیے اضافی اقدامات، سافٹ ویئر، اور تعلیم کی ضرورت ہو سکتی ہے۔ یہ اپنانے میں ایک رکاوٹ ہو سکتی ہے۔ +- رسائی – جدید ویب براؤزرز میں انضمام کی کمی ویب 3 کو زیادہ تر صارفین کے لیے کم قابل رسائی بناتی ہے۔ +- لاگت – زیادہ تر کامیاب ڈی ایپس اپنے کوڈ کے بہت چھوٹے حصے بلاک چین پر ڈالتی ہیں کیونکہ یہ مہنگا ہے۔ + +## مرکزیت بمقابلہ غیر مرکزیت {#centralization-vs-decentralization} + +نیچے دی گئی جدول میں، ہم مرکزی اور غیر مرکزی ڈیجیٹل نیٹ ورکس کے کچھ بڑے فوائد اور نقصانات کی فہرست دیتے ہیں۔ + +| مرکزی نظام | غیر مرکزی نظام | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| کم نیٹ ورک ڈایامیٹر (تمام شرکاء ایک مرکزی اتھارٹی سے جڑے ہوئے ہیں)؛ معلومات تیزی سے پھیلتی ہے، کیونکہ پھیلاؤ کو بہت سے کمپیوٹیشنل وسائل والی ایک مرکزی اتھارٹی سنبھالتی ہے۔ | نیٹ ورک پر سب سے دور کے شرکاء ممکنہ طور پر ایک دوسرے سے کئی ایجز دور ہو سکتے ہیں۔ نیٹ ورک کے ایک طرف سے نشر کی گئی معلومات کو دوسری طرف پہنچنے میں کافی وقت لگ سکتا ہے۔ | +| عام طور پر اعلیٰ کارکردگی (اعلیٰ تھروپٹ، کم کل کمپیوٹیشنل وسائل خرچ ہوتے ہیں) اور نافذ کرنا آسان۔ | عام طور پر کم کارکردگی (کم تھروپٹ، زیادہ کل کمپیوٹیشنل وسائل خرچ ہوتے ہیں) اور نافذ کرنا زیادہ پیچیدہ۔ | +| متضاد ڈیٹا کی صورت میں، حل واضح اور آسان ہے: سچائی کا حتمی ذریعہ مرکزی اتھارٹی ہے۔ | تنازعات کے حل کے لیے ایک پروٹوکول (اکثر پیچیدہ) کی ضرورت ہوتی ہے، اگر پیئرز اس ڈیٹا کی حالت کے بارے میں متضاد دعوے کرتے ہیں جس پر شرکاء کو ہم آہنگ ہونا ہوتا ہے۔ | +| ناکامی کا واحد نقطہ: بدنیتی پر مبنی اداکار مرکزی اتھارٹی کو نشانہ بنا کر نیٹ ورک کو ڈاؤن کر سکتے ہیں۔ | ناکامی کا کوئی واحد نقطہ نہیں: نیٹ ورک پھر بھی کام کر سکتا ہے چاہے شرکاء کے ایک بڑے حصے پر حملہ ہو/انہیں نکال دیا جائے۔ | +| نیٹ ورک کے شرکاء کے درمیان ہم آہنگی بہت آسان ہے، اور اسے ایک مرکزی اتھارٹی سنبھالتی ہے۔ مرکزی اتھارٹی نیٹ ورک کے شرکاء کو بہت کم رگڑ کے ساتھ اپ گریڈ، پروٹوکول اپ ڈیٹس وغیرہ کو اپنانے پر مجبور کر سکتی ہے۔ | ہم آہنگی اکثر مشکل ہوتی ہے، کیونکہ نیٹ ورک کی سطح کے فیصلوں، پروٹوکول اپ گریڈز وغیرہ میں کسی ایک ایجنٹ کا حتمی فیصلہ نہیں ہوتا۔ بدترین صورت میں، جب پروٹوکول کی تبدیلیوں پر اختلافات ہوں تو نیٹ ورک ٹوٹ پھوٹ کا شکار ہو سکتا ہے۔ | +| مرکزی اتھارٹی ڈیٹا کو سنسر کر سکتی ہے، ممکنہ طور پر نیٹ ورک کے کچھ حصوں کو باقی نیٹ ورک کے ساتھ تعامل کرنے سے روک سکتی ہے۔ | سنسرشپ بہت مشکل ہے، کیونکہ معلومات کے پاس پورے نیٹ ورک میں پھیلنے کے کئی طریقے ہوتے ہیں۔ | +| نیٹ ورک میں شرکت مرکزی اتھارٹی کے ذریعے کنٹرول کی جاتی ہے۔ | کوئی بھی نیٹ ورک میں حصہ لے سکتا ہے؛ کوئی "گیٹ کیپرز" نہیں ہیں۔ مثالی طور پر، شرکت کی لاگت بہت کم ہے۔ | + +نوٹ کریں کہ یہ عمومی نمونے ہیں جو ہر نیٹ ورک میں درست ثابت نہیں ہو سکتے۔ مزید برآں، حقیقت میں کسی نیٹ ورک کی مرکزیت/غیر مرکزیت کی ڈگری ایک اسپیکٹرم پر ہوتی ہے؛ کوئی بھی نیٹ ورک مکمل طور پر مرکزی یا مکمل طور پر غیر مرکزی نہیں ہوتا ہے۔ + +## مزید پڑھیں {#further-reading} + +- [ویب 3 کیا ہے؟](/web3/) - _ethereum.org_ +- [The Architecture of a Web 3.0 application](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [غیر مرکزیت کا مطلب](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _6 فروری، 2017 - وائٹلک بٹیرن_ +- [غیر مرکزیت کیوں اہمیت رکھتی ہے](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) _18 فروری، 2018 - کرس ڈکسن_ +- [ویب 3.0 کیا ہے اور یہ کیوں اہمیت رکھتا ہے](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _31 دسمبر، 2019 - میکس مرش اور رچرڈ موئرہیڈ_ +- [ہمیں ویب 3.0 کی ضرورت کیوں ہے](https://gavofyork.medium.com/why-we-need-web-3-0-5da4f2bf95ab) _12 ستمبر، 2018 - گیون ووڈ_ diff --git a/public/content/translations/ur/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md b/public/content/translations/ur/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md new file mode 100644 index 00000000000..657e1a5fcb7 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md @@ -0,0 +1,300 @@ +--- +title: "ایک پائتھن ڈیولپر کے لیے ایتھیریم کا تعارف، حصہ 1" +description: "ایتھیریم ڈیولپمنٹ کا تعارف، خاص طور پر ان لوگوں کے لیے مفید ہے جنہیں پائتھن پروگرامنگ زبان کا علم ہے۔" +author: Marc Garreau +lang: ur-in +tags: [ "python", "web3.py" ] +skill: beginner +published: 2020-09-08 +source: Snake charmers +sourceUrl: https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/ +--- + +تو، آپ نے اس ایتھیریم نامی چیز کے بارے میں سنا ہے اور کیا آپ اس کی گہرائی میں جانے کے لیے تیار ہیں؟ یہ پوسٹ جلد ہی کچھ بلاک چین کی بنیادی باتوں کا احاطہ کرے گی، پھر آپ کو ایک سیمولیٹیڈ ایتھیریم نوڈ کے ساتھ تعامل کرائے گی – بلاک ڈیٹا پڑھنا، اکاؤنٹ بیلنس چیک کرنا، اور ٹرانزیکشن بھیجنا۔ اس دوران، ہم ایپس بنانے کے روایتی طریقوں اور اس نئے ڈی سینٹرلائزڈ پیراڈائم کے درمیان فرق کو اجاگر کریں گے۔ + +## (غیر سخت) پیشگی شرائط {#soft-prerequisites} + +اس پوسٹ کا مقصد ڈیولپرز کی ایک وسیع رینج کے لیے قابل رسائی ہونا ہے۔ [پائتھن ٹولز](/developers/docs/programming-languages/python/) شامل ہوں گے، لیکن وہ صرف خیالات کے لیے ایک ذریعہ ہیں – اگر آپ پائتھن ڈیولپر نہیں ہیں تو کوئی مسئلہ نہیں۔ تاہم، میں اس بارے میں صرف چند مفروضے کروں گا کہ آپ پہلے سے کیا جانتے ہیں، تاکہ ہم جلد ہی ایتھیریم سے متعلق مخصوص چیزوں پر آگے بڑھ سکیں۔ + +مفروضے: + +- آپ ٹرمینل میں کام کر سکتے ہیں، +- آپ نے پائتھن کوڈ کی چند لائنیں لکھی ہیں، +- آپ کی مشین پر پائتھن ورژن 3.6 یا اس سے زیادہ انسٹال ہے ([ورچوئل اینوائرمنٹ](https://realpython.com/effective-python-environment/#virtual-environments) کے استعمال کی سختی سے حوصلہ افزائی کی جاتی ہے)، اور +- آپ نے `pip`، پائتھن کا پیکیج انسٹالر استعمال کیا ہے۔ + دوبارہ، اگر ان میں سے کوئی بھی بات غلط ہے، یا آپ اس مضمون میں کوڈ کو دوبارہ بنانے کا ارادہ نہیں رکھتے ہیں، تو بھی آپ غالباً ٹھیک سے عمل کر سکتے ہیں۔ + +## بلاک چینز، مختصراً {#blockchains-briefly} + +ایتھیریم کو بیان کرنے کے بہت سے طریقے ہیں، لیکن اس کے مرکز میں ایک بلاک چین ہے۔ بلاک چینز بلاکس کی ایک سیریز سے بنے ہیں، تو آئیے وہیں سے شروع کرتے ہیں۔ سادہ ترین الفاظ میں، ایتھیریم بلاک چین پر ہر بلاک صرف کچھ میٹا ڈیٹا اور ٹرانزیکشنز کی ایک فہرست ہے۔ JSON فارمیٹ میں، یہ کچھ اس طرح نظر آتا ہے: + +```json +{ + "number": 1234567, + "hash": "0xabc123...", + "parentHash": "0xdef456...", + ..., + "transactions": [...] +} +``` + +ہر [بلاک](/developers/docs/blocks/) میں اس سے پہلے آنے والے بلاک کا ایک حوالہ ہوتا ہے؛ `parentHash` صرف پچھلے بلاک کا ہیش ہے۔ + +نوٹ: ایتھیریم مقررہ سائز کی ویلیوز (“ہیشز”) تیار کرنے کے لیے باقاعدگی سے ہیش فنکشنز کا استعمال کرتا ہے۔ ہیشز ایتھیریم میں ایک اہم کردار ادا کرتے ہیں، لیکن آپ فی الحال انہیں محفوظ طریقے سے منفرد IDs کے طور پر سوچ سکتے ہیں۔ + +![ایک ڈایاگرام جو ہر بلاک کے اندر ڈیٹا سمیت ایک بلاک چین کو دکھاتا ہے](./blockchain-diagram.png) + +_ایک بلاک چین بنیادی طور پر ایک لنکڈ لسٹ ہے؛ ہر بلاک میں پچھلے بلاک کا ایک حوالہ ہوتا ہے۔_ + +یہ ڈیٹا اسٹرکچر کوئی نئی چیز نہیں ہے، لیکن وہ اصول (یعنی، پیئر-ٹو-پیئر پروٹوکولز) جو نیٹ ورک کو چلاتے ہیں، وہ نئے ہیں۔ کوئی مرکزی اتھارٹی نہیں ہے؛ پیئرز کے نیٹ ورک کو نیٹ ورک کو برقرار رکھنے کے لیے تعاون کرنا چاہیے، اور یہ فیصلہ کرنے کے لیے مقابلہ کرنا چاہیے کہ اگلے بلاک میں کون سے ٹرانزیکشن شامل کیے جائیں۔ لہذا، جب آپ کسی دوست کو کچھ رقم بھیجنا چاہتے ہیں، تو آپ کو اس ٹرانزیکشن کو نیٹ ورک پر براڈکاسٹ کرنے کی ضرورت ہوگی، پھر اس کے آنے والے بلاک میں شامل ہونے کا انتظار کرنا ہوگا۔ + +بلاک چین کے لیے یہ تصدیق کرنے کا واحد طریقہ کہ رقم واقعی ایک صارف سے دوسرے کو بھیجی گئی تھی، یہ ہے کہ اس بلاک چین کی مقامی کرنسی (یعنی، جو اس بلاک چین کے ذریعے بنائی اور چلائی جاتی ہے) کا استعمال کیا جائے۔ ایتھیریم میں، اس کرنسی کو ایتھر کہا جاتا ہے، اور ایتھیریم بلاک چین اکاؤنٹ بیلنس کا واحد سرکاری ریکارڈ رکھتا ہے۔ + +## ایک نیا پیراڈائم {#a-new-paradigm} + +اس نئے ڈی سینٹرلائزڈ ٹیک اسٹیک نے نئے ڈیولپر ٹولز کو جنم دیا ہے۔ ایسے ٹولز بہت سی پروگرامنگ زبانوں میں موجود ہیں، لیکن ہم اسے پائتھن کے نظریے سے دیکھیں گے۔ دوبارہ بتاتا چلوں: چاہے پائتھن آپ کی پسند کی زبان نہ بھی ہو، اس کے ساتھ چلنے میں زیادہ پریشانی نہیں ہونی چاہیے۔ + +پائتھن ڈیولپرز جو ایتھیریم کے ساتھ تعامل کرنا چاہتے ہیں وہ ممکنہ طور پر [Web3.py](https://web3py.readthedocs.io/) کا استعمال کریں گے۔ Web3.py ایک لائبریری ہے جو آپ کے ایتھیریم نوڈ سے جڑنے کے طریقے کو بہت آسان بناتی ہے، پھر اس سے ڈیٹا بھیجتی اور وصول کرتی ہے۔ + +نوٹ: “ایتھیریم نوڈ” اور “ایتھیریم کلائنٹ” ایک دوسرے کی جگہ پر استعمال ہوتے ہیں۔ دونوں صورتوں میں، یہ اس سافٹ ویئر سے مراد ہے جسے ایتھیریم نیٹ ورک میں ایک شریک چلاتا ہے۔ یہ سافٹ ویئر بلاک ڈیٹا پڑھ سکتا ہے، جب چین میں نئے بلاکس شامل کیے جاتے ہیں تو اپ ڈیٹس وصول کر سکتا ہے، نئے ٹرانزیکشنز کو براڈکاسٹ کر سکتا ہے، اور بہت کچھ۔ تکنیکی طور پر، کلائنٹ سافٹ ویئر ہے، نوڈ وہ کمپیوٹر ہے جو سافٹ ویئر چلا رہا ہے۔ + +[ایتھیریم کلائنٹس](/developers/docs/nodes-and-clients/) کو [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTP، یا Websockets کے ذریعے قابل رسائی ہونے کے لیے کنفیگر کیا جا سکتا ہے، لہذا Web3.py کو اس کنفیگریشن کو مرر کرنے کی ضرورت ہوگی۔ Web3.py ان کنکشن آپشنز کو **پرووائیڈرز** کے طور پر حوالہ دیتا ہے۔ آپ کو Web3.py انسٹنس کو اپنے نوڈ کے ساتھ لنک کرنے کے لیے تین پرووائیڈرز میں سے ایک کا انتخاب کرنا ہوگا۔ + +![ایک ڈایاگرام جو دکھاتا ہے کہ web3.py آپ کی ایپلیکیشن کو ایک ایتھیریم نوڈ سے جوڑنے کے لیے IPC کا استعمال کیسے کرتا ہے](./web3py-and-nodes.png) + +_ایتھیریم نوڈ اور Web3.py کو ایک ہی پروٹوکول کے ذریعے کمیونیکیٹ کرنے کے لیے کنفیگر کریں، مثال کے طور پر، اس ڈایاگرام میں IPC۔_ + +ایک بار جب Web3.py صحیح طریقے سے کنفیگر ہو جاتا ہے، تو آپ بلاک چین کے ساتھ تعامل شروع کر سکتے ہیں۔ یہاں Web3.py کے استعمال کی چند مثالیں ہیں جو آنے والی چیزوں کے پیش منظر کے طور پر ہیں: + +```python +# بلاک ڈیٹا پڑھیں: +w3.eth.get_block('latest') + +# ایک ٹرانزیکشن بھیجیں: +w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...}) +``` + +## انسٹالیشن {#installation} + +اس واک تھرو میں، ہم صرف ایک پائتھن انٹرپریٹر کے اندر کام کریں گے۔ ہم کوئی ڈائریکٹریز، فائلیں، کلاسز یا فنکشنز نہیں بنائیں گے۔ + +نوٹ: نیچے دی گئی مثالوں میں، `$` سے شروع ہونے والی کمانڈز ٹرمینل میں چلانے کے لیے ہیں۔ ( `$` ٹائپ نہ کریں، یہ صرف لائن کے آغاز کی نشاندہی کرتا ہے۔) + +سب سے پہلے، [IPython](https://ipython.org/) کو ایک صارف دوست ماحول کے لیے انسٹال کریں جس میں کھوج کی جا سکے۔ IPython دیگر خصوصیات کے علاوہ ٹیب کی تکمیل کی پیشکش کرتا ہے، جس سے یہ دیکھنا بہت آسان ہو جاتا ہے کہ Web3.py کے اندر کیا ممکن ہے۔ + +```bash +pip install ipython +``` + +Web3.py `web3` نام کے تحت شائع ہوتا ہے۔ اسے اس طرح انسٹال کریں: + +```bash +pip install web3 +``` + +ایک اور بات – ہم بعد میں ایک بلاک چین کو سیمولیٹ کرنے جا رہے ہیں, جس کے لیے کچھ اور ڈیپینڈنسیز کی ضرورت ہے۔ آپ انہیں اس کے ذریعے انسٹال کر سکتے ہیں: + +```bash +pip install 'web3[tester]' +``` + +آپ جانے کے لیے پوری طرح تیار ہیں! + +نوٹ: `web3[tester]` پیکیج Python 3.10.xx تک کام کرتا ہے + +## ایک سینڈ باکس شروع کریں {#spin-up-a-sandbox} + +اپنے ٹرمینل میں `ipython` چلا کر ایک نیا پائتھن ماحول کھولیں۔ یہ `python` چلانے کے مترادف ہے، لیکن اس میں مزید خصوصیات ہیں۔ + +```bash +ipython +``` + +یہ آپ کے چل رہے پائتھن اور IPython کے ورژنز کے بارے میں کچھ معلومات پرنٹ کرے گا، پھر آپ کو ان پٹ کا انتظار کرتے ہوئے ایک پرامپٹ نظر آنا چاہیے: + +```python +In [1]: +``` + +اب آپ ایک انٹرایکٹو پائتھن شیل دیکھ رہے ہیں۔ بنیادی طور پر، یہ کھیلنے کے لیے ایک سینڈ باکس ہے۔ اگر آپ یہاں تک پہنچ گئے ہیں، تو Web3.py کو امپورٹ کرنے کا وقت آ گیا ہے: + +```python +In [1]: from web3 import Web3 +``` + +## Web3 ماڈیول کا تعارف {#introducing-the-web3-module} + +ایتھیریم کا گیٹ وے ہونے کے علاوہ، [Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) ماڈیول کچھ سہولتی فنکشنز پیش کرتا ہے۔ آئیے چند کو کھوجتے ہیں۔ + +ایک ایتھیریم ایپلیکیشن میں، آپ کو عام طور پر کرنسی کی ڈینامینیشنز کو تبدیل کرنے کی ضرورت ہوگی۔ Web3 ماڈیول صرف اس کے لیے کچھ ہیلپر میتھڈز فراہم کرتا ہے: [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) اور [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei)۔ + + +نوٹ: کمپیوٹرز اعشاریہ کی ریاضی کو سنبھالنے میں بدنام زمانہ خراب ہیں۔ اس سے بچنے کے لیے، ڈیولپرز اکثر ڈالر کی رقم کو سینٹ میں اسٹور کرتے ہیں۔ مثال کے طور پر، $5.99 کی قیمت والی کوئی چیز ڈیٹا بیس میں 599 کے طور پر اسٹور کی جا سکتی ہے۔ + +جب ایتھر میں ٹرانزیکشنز کو سنبھالتے ہیں تو اسی طرح کا ایک پیٹرن استعمال کیا جاتا ہے۔ تاہم، دو اعشاریہ پوائنٹس کے بجائے، ایتھر کے 18 ہوتے ہیں! ایتھر کی سب سے چھوٹی ڈینامینیشن کو wei کہا جاتا ہے، لہذا یہ وہ ویلیو ہے جو ٹرانزیکشن بھیجتے وقت بتائی جاتی ہے۔ + +1 ایتھر = 1000000000000000000 wei + +1 wei = 0.000000000000000001 ایتھر + + + +کچھ ویلیوز کو wei میں اور wei سے تبدیل کرنے کی کوشش کریں۔ نوٹ کریں کہ ایتھر اور wei کے درمیان [بہت سی ڈینامینیشنز کے نام ہیں](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations)۔ ان میں سے ایک بہتر جانا جاتا **gwei** ہے، کیونکہ اکثر ٹرانزیکشن فیس اسی طرح ظاہر کی جاتی ہے۔ + +```python +In [2]: Web3.to_wei(1, 'ether') +Out[2]: 1000000000000000000 + +In [3]: Web3.from_wei(500000000, 'gwei') +Out[3]: Decimal('0.5') +``` + +Web3 ماڈیول پر دیگر یوٹیلیٹی میتھڈز میں ڈیٹا فارمیٹ کنورٹرز (مثلاً، [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex))، ایڈریس ہیلپرز (مثلاً، [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress))، اور ہیش فنکشنز (مثلاً، [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)) شامل ہیں۔ ان میں سے بہت سے سیریز میں بعد میں کور کیے جائیں گے۔ تمام دستیاب میتھڈز اور پراپرٹیز کو دیکھنے کے لیے، `Web3` ٹائپ کرکے IPython کی آٹو-کمپلیٹ کا استعمال کریں۔ اور پیریڈ کے بعد دو بار ٹیب کی کو دبائیں۔ + +## چین سے بات کریں {#talk-to-the-chain} + +سہولتی میتھڈز بہت اچھے ہیں، لیکن آئیے بلاک چین کی طرف بڑھتے ہیں۔ اگلا قدم Web3.py کو ایک ایتھیریم نوڈ کے ساتھ کمیونیکیٹ کرنے کے لیے کنفیگر کرنا ہے۔ یہاں ہمارے پاس IPC, HTTP، یا Websocket پرووائیڈرز استعمال کرنے کا آپشن ہے۔ + +ہم اس راستے پر نہیں جائیں گے، لیکن HTTP پرووائیڈر کا استعمال کرتے ہوئے ایک مکمل ورک فلو کی مثال کچھ اس طرح نظر آسکتی ہے: + +- ایک ایتھیریم نوڈ ڈاؤن لوڈ کریں، جیسے، [Geth](https://geth.ethereum.org/)۔ +- ایک ٹرمینل ونڈو میں Geth شروع کریں اور اس کے نیٹ ورک کو سنک کرنے کا انتظار کریں۔ ڈیفالٹ HTTP پورٹ `8545` ہے، لیکن اسے کنفیگر کیا جا سکتا ہے۔ +- Web3.py کو بتائیں کہ نوڈ سے HTTP کے ذریعے `localhost:8545` پر جڑیں۔ + `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))` +- نوڈ کے ساتھ تعامل کے لیے `w3` انسٹنس کا استعمال کریں۔ + +جبکہ یہ اسے کرنے کا ایک "حقیقی" طریقہ ہے، سنکنگ کے عمل میں گھنٹوں لگتے ہیں اور اگر آپ صرف ایک ڈیولپمنٹ ماحول چاہتے ہیں تو یہ غیر ضروری ہے۔ Web3.py اس مقصد کے لیے ایک چوتھا پرووائیڈر فراہم کرتا ہے، **EthereumTesterProvider**۔ یہ ٹیسٹر پرووائیڈر ایک سیمولیٹیڈ ایتھیریم نوڈ سے جڑتا ہے جس میں نرم اجازتیں اور کھیلنے کے لیے جعلی کرنسی ہوتی ہے۔ + +![ایک ڈایاگرام جو دکھاتا ہے کہ EthereumTesterProvider آپ کی web3.py ایپلیکیشن کو ایک سیمولیٹیڈ ایتھیریم نوڈ سے جوڑتا ہے](./ethereumtesterprovider.png) + +_EthereumTesterProvider ایک سیمولیٹیڈ نوڈ سے جڑتا ہے اور فوری ڈیولپمنٹ ماحول کے لیے کارآمد ہے۔_ + +اس سیمولیٹیڈ نوڈ کو [eth-tester](https://github.com/ethereum/eth-tester) کہا جاتا ہے اور ہم نے اسے `pip install web3[tester]` کمانڈ کے حصے کے طور پر انسٹال کیا تھا۔ اس ٹیسٹر پرووائیڈر کو استعمال کرنے کے لیے Web3.py کو کنفیگر کرنا اتنا ہی آسان ہے جتنا کہ: + +```python +In [4]: w3 = Web3(Web3.EthereumTesterProvider()) +``` + +اب آپ چین پر سرفنگ کے لیے تیار ہیں! یہ وہ بات نہیں ہے جو لوگ کہتے ہیں۔ یہ میں نے ابھی بنایا ہے۔ آئیے ایک مختصر دورہ کرتے ہیں۔ + +## مختصر دورہ {#the-quick-tour} + +سب سے پہلے، ایک سینیٹی چیک: + +```python +In [5]: w3.is_connected() +Out[5]: True +``` + +چونکہ ہم ٹیسٹر پرووائیڈر کا استعمال کر رہے ہیں، یہ ایک بہت قیمتی ٹیسٹ نہیں ہے، لیکن اگر یہ ناکام ہو جاتا ہے، تو امکان ہے کہ آپ نے `w3` متغیر کو انسٹینشیئیٹ کرتے وقت کچھ غلط ٹائپ کیا ہو۔ دوبارہ چیک کریں کہ آپ نے اندرونی قوسین شامل کیے ہیں، یعنی `Web3.EthereumTesterProvider()`۔ + +## ٹور اسٹاپ #1: [اکاؤنٹس](/developers/docs/accounts/) {#tour-stop-1-accounts} + +سہولت کے طور پر، ٹیسٹر پرووائیڈر نے کچھ اکاؤنٹس بنائے اور انہیں ٹیسٹ ایتھر سے پہلے سے لوڈ کر دیا۔ + +سب سے پہلے، آئیے ان اکاؤنٹس کی ایک فہرست دیکھتے ہیں: + +```python +In [6]: w3.eth.accounts +Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf', + '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF', + '0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...] +``` + +اگر آپ یہ کمانڈ چلاتے ہیں، تو آپ کو دس سٹرنگز کی ایک فہرست نظر آنی چاہیے جو `0x` سے شروع ہوتی ہیں۔ ہر ایک ایک **پبلک ایڈریس** ہے اور، کچھ طریقوں سے، چیکنگ اکاؤنٹ پر اکاؤنٹ نمبر کے مترادف ہے۔ آپ یہ ایڈریس کسی ایسے شخص کو فراہم کریں گے جو آپ کو ایتھر بھیجنا چاہتا ہے۔ + +جیسا کہ ذکر کیا گیا ہے، ٹیسٹر پرووائیڈر نے ان میں سے ہر ایک اکاؤنٹ کو کچھ ٹیسٹ ایتھر سے پہلے سے لوڈ کیا ہے۔ آئیے معلوم کرتے ہیں کہ پہلے اکاؤنٹ میں کتنی رقم ہے: + +```python +In [7]: w3.eth.get_balance(w3.eth.accounts[0]) +Out[7]: 1000000000000000000000000 +``` + +یہ بہت سارے صفر ہیں! اس سے پہلے کہ آپ جعلی بینک تک ہنستے ہوئے جائیں، کرنسی کی ڈینامینیشنز کے بارے میں پہلے والا سبق یاد کریں۔ ایتھر کی ویلیوز سب سے چھوٹی ڈینامینیشن، wei میں ظاہر کی جاتی ہیں۔ اسے ایتھر میں تبدیل کریں: + +```python +In [8]: w3.from_wei(1000000000000000000000000, 'ether') +Out[8]: Decimal('1000000') +``` + +ایک ملین ٹیسٹ ایتھر - اب بھی بہت اچھا ہے۔ + +## ٹور اسٹاپ #2: بلاک ڈیٹا {#tour-stop-2-block-data} + +آئیے اس سیمولیٹیڈ بلاک چین کی حالت پر ایک نظر ڈالتے ہیں: + +```python +In [9]: w3.eth.get_block('latest') +Out[9]: AttributeDict({ + 'number': 0, + 'hash': HexBytes('0x9469878...'), + 'parentHash': HexBytes('0x0000000...'), + ... + 'transactions': [] +}) +``` + +ایک بلاک کے بارے میں بہت سی معلومات واپس آتی ہیں، لیکن یہاں صرف چند چیزوں کی نشاندہی کرنی ہے: + +- بلاک نمبر صفر ہے - چاہے آپ نے کتنی ہی دیر پہلے ٹیسٹر پرووائیڈر کو کنفیگر کیا ہو۔ حقیقی ایتھیریم نیٹ ورک کے برعکس، جو ہر 12 سیکنڈ میں ایک نیا بلاک شامل کرتا ہے، یہ سیمولیشن اس وقت تک انتظار کرے گا جب تک آپ اسے کرنے کے لیے کچھ کام نہ دیں۔ +- `transactions` ایک خالی فہرست ہے، اسی وجہ سے: ہم نے ابھی تک کچھ نہیں کیا ہے۔ یہ پہلا بلاک ایک **خالی بلاک** ہے، صرف چین کو شروع کرنے کے لیے۔ +- نوٹ کریں کہ `parentHash` صرف خالی بائٹس کا ایک گچھا ہے۔ یہ اس بات کی نشاندہی کرتا ہے کہ یہ چین میں پہلا بلاک ہے، جسے **جینیسس بلاک** بھی کہا جاتا ہے۔ + +## ٹور اسٹاپ #3: [ٹرانزیکشنز](/developers/docs/transactions/) {#tour-stop-3-transactions} + +ہم بلاک صفر پر پھنسے ہوئے ہیں جب تک کہ کوئی پینڈنگ ٹرانزیکشن نہ ہو، تو آئیے اسے ایک دیتے ہیں۔ ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں چند ٹیسٹ ایتھر بھیجیں: + +```python +In [10]: tx_hash = w3.eth.send_transaction({ + 'from': w3.eth.accounts[0], + 'to': w3.eth.accounts[1], + 'value': w3.to_wei(3, 'ether'), + 'gas': 21000 +}) +``` + +یہ عام طور پر وہ نقطہ ہے جہاں آپ اپنے ٹرانزیکشن کو ایک نئے بلاک میں شامل ہونے کے لیے کئی سیکنڈ انتظار کریں گے۔ پورا عمل کچھ اس طرح ہوتا ہے: + +1. ایک ٹرانزیکشن جمع کریں اور ٹرانزیکشن ہیش کو پکڑے رہیں۔ جب تک ٹرانزیکشن پر مشتمل بلاک بن کر براڈکاسٹ نہیں ہو جاتا، ٹرانزیکشن “پینڈنگ” رہتا ہے۔ + `tx_hash = w3.eth.send_transaction({ … })` +2. ٹرانزیکشن کو ایک بلاک میں شامل ہونے کا انتظار کریں: + `w3.eth.wait_for_transaction_receipt(tx_hash)` +3. ایپلیکیشن لاجک جاری رکھیں۔ کامیاب ٹرانزیکشن کو دیکھنے کے لیے: + `w3.eth.get_transaction(tx_hash)` + +ہمارا سیمولیٹیڈ ماحول فوری طور پر ایک نئے بلاک میں ٹرانزیکشن شامل کر دے گا، لہذا ہم فوری طور پر ٹرانزیکشن دیکھ سکتے ہیں: + +```python +In [11]: w3.eth.get_transaction(tx_hash) +Out[11]: AttributeDict({ + 'hash': HexBytes('0x15e9fb95dc39...'), + 'blockNumber': 1, + 'transactionIndex': 0, + 'from': '0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf', + 'to': '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF', + 'value': 3000000000000000000, + ... +}) +``` + +آپ کو یہاں کچھ جانی پہچانی تفصیلات نظر آئیں گی: `from`، `to`، اور `value` فیلڈز ہمارے `send_transaction` کال کے ان پٹس سے مماثل ہونے چاہئیں۔ دوسری تسلی بخش بات یہ ہے کہ یہ ٹرانزیکشن بلاک نمبر 1 کے اندر پہلے ٹرانزیکشن (`'transactionIndex': 0`) کے طور پر شامل کیا گیا تھا۔ + +ہم اس ٹرانزیکشن کی کامیابی کی تصدیق دونوں ملوث اکاؤنٹس کے بیلنس چیک کر کے بھی آسانی سے کر سکتے ہیں۔ تین ایتھر کو ایک سے دوسرے میں منتقل ہونا چاہیے تھا۔ + +```python +In [12]: w3.eth.get_balance(w3.eth.accounts[0]) +Out[12]: 999996999979000000000000 + +In [13]: w3.eth.get_balance(w3.eth.accounts[1]) +Out[13]: 1000003000000000000000000 +``` + +بعد والا اچھا لگ رہا ہے! بیلنس 1,000,000 سے 1,000,003 ایتھر ہو گیا۔ لیکن پہلے اکاؤنٹ کا کیا ہوا؟ ایسا لگتا ہے کہ اس نے تین ایتھر سے تھوڑا زیادہ کھو دیا ہے۔ افسوس، زندگی میں کچھ بھی مفت نہیں ہے، اور ایتھیریم پبلک نیٹ ورک کا استعمال کرنے کے لیے آپ کو اپنے پیئرز کو ان کے معاون کردار کے لیے معاوضہ دینا ہوگا۔ ٹرانزیکشن جمع کرانے والے اکاؤنٹ سے ایک چھوٹی ٹرانزیکشن فیس کاٹی گئی - یہ فیس جلائی گئی گیس کی مقدار ہے (ETH ٹرانسفر کے لیے 21000 یونٹ گیس) جسے نیٹ ورک کی سرگرمی کے مطابق بدلنے والی ایک بیس فیس سے ضرب دیا جاتا ہے اور اس کے ساتھ ایک ٹپ شامل ہوتی ہے جو اس ویلیڈیٹر کو جاتی ہے جو ٹرانزیکشن کو ایک بلاک میں شامل کرتا ہے۔ + +[گیس](/developers/docs/gas/#post-london) پر مزید + +نوٹ: پبلک نیٹ ورک پر، ٹرانزیکشن فیس نیٹ ورک کی ڈیمانڈ اور آپ کتنی جلدی ایک ٹرانزیکشن پروسیس کرنا چاہتے ہیں، کی بنیاد پر متغیر ہوتی ہے۔ اگر آپ فیس کا حساب لگانے کے طریقے کی تفصیل میں دلچسپی رکھتے ہیں، تو میری پچھلی پوسٹ دیکھیں جس کا عنوان ہے بلاک میں ٹرانزیکشنز کیسے شامل کی جاتی ہیں۔ + +## اور سانس لیں {#and-breathe} + +ہم اس پر تھوڑی دیر سے کام کر رہے ہیں، لہذا یہ وقفہ لینے کے لیے کسی بھی جگہ کی طرح اچھی جگہ لگتی ہے۔ گہرائی کا سلسلہ جاری ہے، اور ہم اس سیریز کے دوسرے حصے میں کھوج جاری رکھیں گے۔ آنے والے کچھ تصورات: ایک حقیقی نوڈ سے جڑنا، اسمارٹ کانٹریکٹس، اور ٹوکنز۔ کیا آپ کے پاس مزید سوالات ہیں؟ مجھے بتائیں! آپ کی رائے اس بات پر اثر انداز ہوگی کہ ہم یہاں سے کہاں جاتے ہیں۔ درخواستیں [Twitter](https://twitter.com/wolovim) کے ذریعے خوش آمدید ہیں۔ diff --git a/public/content/translations/ur/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/ur/developers/tutorials/all-you-can-cache/index.md new file mode 100644 index 00000000000..1ea50457b41 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/all-you-can-cache/index.md @@ -0,0 +1,867 @@ +--- +title: "وہ سب کچھ جو آپ کیش کر سکتے ہیں" +description: "سستے رول اپ ٹرانزیکشنز کے لیے کیشنگ کنٹریکٹ بنانے اور استعمال کرنے کا طریقہ سیکھیں" +author: Ori Pomerantz +tags: [ "لیئر 2", "کیشنگ", "اسٹوریج" ] +skill: intermediate +published: 2022-09-15 +lang: ur-in +--- + +رول اپس کا استعمال کرتے وقت ٹرانزیکشن میں ایک بائٹ کی قیمت اسٹوریج سلاٹ کی قیمت سے کہیں زیادہ مہنگی ہوتی ہے۔ لہذا، زیادہ سے زیادہ معلومات کو آن چین کیش کرنا سمجھ میں آتا ہے۔ + +اس مضمون میں آپ یہ سیکھیں گے کہ کیشنگ کنٹریکٹ کو اس طرح کیسے بنایا اور استعمال کیا جائے کہ کوئی بھی پیرامیٹر ویلیو جس کے متعدد بار استعمال ہونے کا امکان ہو، کیش ہو جائے اور بہت کم تعداد میں بائٹس کے ساتھ (پہلی بار کے بعد) استعمال کے لیے دستیاب ہو، اور اس کیش کو استعمال کرنے والا آف چین کوڈ کیسے لکھا جائے۔ + +اگر آپ مضمون کو چھوڑنا چاہتے ہیں اور صرف سورس کوڈ دیکھنا چاہتے ہیں، تو [یہ یہاں ہے](https://github.com/qbzzt/20220915-all-you-can-cache)۔ ڈیولپمنٹ اسٹیک [Foundry](https://getfoundry.sh/introduction/installation/) ہے۔ + +## مجموعی ڈیزائن {#overall-design} + +سادگی کی خاطر ہم یہ فرض کریں گے کہ تمام ٹرانزیکشن پیرامیٹرز `uint256` ہیں، 32 بائٹس لمبے ہیں۔ جب ہمیں کوئی ٹرانزیکشن موصول ہوگا، تو ہم ہر پیرامیٹر کو اس طرح پارس کریں گے: + +1. اگر پہلا بائٹ `0xFF` ہے، تو اگلے 32 بائٹس کو پیرامیٹر ویلیو کے طور پر لیں اور اسے کیش میں لکھیں۔ + +2. اگر پہلا بائٹ `0xFE` ہے، تو اگلے 32 بائٹس کو پیرامیٹر ویلیو کے طور پر لیں لیکن اسے کیش میں _نہ_ لکھیں۔ + +3. کسی بھی دوسری ویلیو کے لیے، اوپر کے چار بٹس کو اضافی بائٹس کی تعداد کے طور پر لیں، اور نیچے کے چار بٹس کو کیش کی (key) کے سب سے اہم بٹس کے طور پر لیں۔ یہاں کچھ مثالیں ہیں: + + | کال ڈیٹا میں بائٹس | کیش کی (key) | + | :----------------- | ------------------------------: | + | 0x0F | 0x0F | + | 0x10,0x10 | 0x10 | + | 0x12,0xAC | 0x02AC | + | 0x2D,0xEA, 0xD6 | 0x0DEAD6 | + +## کیش مینیپولیشن {#cache-manipulation} + +کیش [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol) میں نافذ کیا گیا ہے۔ آئیے اس کا لائن بہ لائن جائزہ لیں۔ + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; + + +contract Cache { + + bytes1 public constant INTO_CACHE = 0xFF; + bytes1 public constant DONT_CACHE = 0xFE; +``` + +یہ کونسٹنٹس ان خاص معاملات کی تشریح کے لیے استعمال ہوتے ہیں جہاں ہم تمام معلومات فراہم کرتے ہیں اور یا تو چاہتے ہیں کہ اسے کیش میں لکھا جائے یا نہیں۔ کیش میں لکھنے کے لیے پہلے سے غیر استعمال شدہ اسٹوریج سلاٹس میں دو [`SSTORE`](https://www.evm.codes/#55) آپریشنز کی ضرورت ہوتی ہے، جن میں سے ہر ایک پر 22100 گیس لاگت آتی ہے، اس لیے ہم اسے اختیاری بناتے ہیں۔ + +```solidity + + mapping(uint => uint) public val2key; +``` + +ویلیوز اور ان کی کیز (keys) کے درمیان ایک [میپنگ](https://www.geeksforgeeks.org/solidity/solidity-mappings/)۔ ٹرانزیکشن بھیجنے سے پہلے ویلیوز کو انکوڈ کرنے کے لیے یہ معلومات ضروری ہے۔ + +```solidity + // لوکیشن n میں کی (key) n+1 کے لیے ویلیو ہے، کیونکہ ہمیں صفر کو "کیش میں نہیں" کے طور پر محفوظ کرنے کی ضرورت ہے۔ + // + uint[] public key2val; +``` + +ہم کیز (keys) سے ویلیوز تک میپنگ کے لیے ایک ارے (array) کا استعمال کر سکتے ہیں کیونکہ ہم کیز (keys) تفویض کرتے ہیں، اور سادگی کے لیے ہم اسے ترتیب وار کرتے ہیں۔ + +```solidity + function cacheRead(uint _key) public view returns (uint) { + require(_key <= key2val.length, "غیر شروع شدہ کیش انٹری کو پڑھنا"); + return key2val[_key-1]; + } // cacheRead +``` + +کیش سے ایک ویلیو پڑھیں۔ + +```solidity + // اگر ویلیو پہلے سے موجود نہیں ہے تو اسے کیش میں لکھیں + // ٹیسٹ کو کام کرنے کے قابل بنانے کے لیے صرف پبلک + function cacheWrite(uint _value) public returns (uint) { + // اگر ویلیو پہلے سے ہی کیش میں ہے، تو موجودہ کی (key) واپس کریں + if (val2key[_value] != 0) { + return val2key[_value]; + } +``` + +ایک ہی ویلیو کو ایک سے زیادہ بار کیش میں ڈالنے کا کوئی فائدہ نہیں ہے۔ اگر ویلیو پہلے سے موجود ہے، تو صرف موجودہ کی (key) واپس کریں۔ + +```solidity + // چونکہ 0xFE ایک خاص کیس ہے، اس لیے سب سے بڑی کی (key) جو کیش + // رکھ سکتا ہے وہ 0x0D ہے جس کے بعد 15 0xFF's ہیں۔ اگر کیش کی لمبائی پہلے ہی اتنی + // بڑی ہے، تو ناکام ہو جائیں۔ + // 1 2 3 4 5 6 7 8 9 A B C D E F + require(key2val.length+1 < 0x0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, + "کیش اوور فلو"); +``` + +مجھے نہیں لگتا کہ ہمیں کبھی اتنا بڑا کیش ملے گا (تقریباً 1.8\*1037 اندراجات، جسے اسٹور کرنے کے لیے تقریباً 1027 ٹی بی کی ضرورت ہوگی)۔ تاہم، میں اتنا بوڑھا ہوں کہ مجھے ["640kB ہمیشہ کافی ہوگا"](https://quoteinvestigator.com/2011/09/08/640k-enough/) یاد ہے۔ یہ ٹیسٹ بہت سستا ہے۔ + +```solidity + // اگلی کی (key) کا استعمال کرتے ہوئے ویلیو لکھیں + val2key[_value] = key2val.length+1; +``` + +ریورس لک اپ (ویلیو سے کی (key) تک) شامل کریں۔ + +```solidity + key2val.push(_value); +``` + +فارورڈ لک اپ (کی (key) سے ویلیو تک) شامل کریں۔ چونکہ ہم ویلیوز کو ترتیب وار تفویض کرتے ہیں، اس لیے ہم اسے صرف آخری ارے ویلیو کے بعد شامل کر سکتے ہیں۔ + +```solidity + return key2val.length; + } // cacheWrite +``` + +`key2val` کی نئی لمبائی واپس کریں، جو وہ سیل ہے جہاں نئی ​​ویلیو اسٹور کی گئی ہے۔ + +```solidity + function _calldataVal(uint startByte, uint length) + private pure returns (uint) +``` + +یہ فنکشن کال ڈیٹا سے کسی بھی لمبائی کی ویلیو پڑھتا ہے (32 بائٹس تک، ورڈ سائز)۔ + +```solidity + { + uint _retVal; + + require(length < 0x21, + "_calldataVal لمبائی کی حد 32 بائٹس ہے"); + require(length + startByte <= msg.data.length, + "_calldataVal کال ڈیٹا سائز سے آگے پڑھنے کی کوشش کر رہا ہے"); +``` + +یہ فنکشن اندرونی ہے، لہذا اگر باقی کوڈ صحیح طریقے سے لکھا گیا ہے تو ان ٹیسٹوں کی ضرورت نہیں ہے۔ تاہم، ان پر زیادہ لاگت نہیں آتی ہے لہذا ہم انہیں رکھ سکتے ہیں۔ + +```solidity + assembly { + _retVal := calldataload(startByte) + } +``` + +یہ کوڈ [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html) میں ہے۔ یہ کال ڈیٹا سے 32 بائٹ کی ویلیو پڑھتا ہے۔ یہ تب بھی کام کرتا ہے اگر کال ڈیٹا `startByte+32` سے پہلے رک جاتا ہے کیونکہ EVM میں غیر شروع شدہ جگہ کو صفر سمجھا جاتا ہے۔ + +```solidity + _retVal = _retVal >> (256-length*8); +``` + +ہم ضروری نہیں کہ 32 بائٹ کی ویلیو چاہتے ہیں۔ اس سے اضافی بائٹس سے چھٹکارا مل جاتا ہے۔ + +```solidity + return _retVal; + } // _calldataVal + + + // کال ڈیٹا سے ایک پیرامیٹر پڑھیں، _fromByte سے شروع ہو کر + function _readParam(uint _fromByte) internal + returns (uint _nextByte, uint _parameterValue) + { +``` + +کال ڈیٹا سے ایک پیرامیٹر پڑھیں۔ نوٹ کریں کہ ہمیں نہ صرف وہ ویلیو واپس کرنے کی ضرورت ہے جو ہم نے پڑھی ہے، بلکہ اگلے بائٹ کا مقام بھی واپس کرنے کی ضرورت ہے کیونکہ پیرامیٹرز 1 بائٹ سے لے کر 33 بائٹس تک کے ہو سکتے ہیں۔ + +```solidity + // پہلا بائٹ ہمیں بتاتا ہے کہ باقی کی تشریح کیسے کی جائے + uint8 _firstByte; + + _firstByte = uint8(_calldataVal(_fromByte, 1)); +``` + +Solidity ممکنہ طور پر خطرناک [مضمر قسم کی تبدیلیوں](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions) پر پابندی لگا کر بگس کی تعداد کو کم کرنے کی کوشش کرتا ہے۔ ایک ڈاؤن گریڈ، مثال کے طور پر 256 بٹس سے 8 بٹس تک، واضح ہونا چاہیے۔ + +```solidity + + // ویلیو کو پڑھیں، لیکن اسے کیش میں نہ لکھیں + if (_firstByte == uint8(DONT_CACHE)) + return(_fromByte+33, _calldataVal(_fromByte+1, 32)); + + // ویلیو کو پڑھیں، اور اسے کیش میں لکھیں + if (_firstByte == uint8(INTO_CACHE)) { + uint _param = _calldataVal(_fromByte+1, 32); + cacheWrite(_param); + return(_fromByte+33, _param); + } + + // اگر ہم یہاں پہنچ گئے تو اس کا مطلب ہے کہ ہمیں کیش سے پڑھنے کی ضرورت ہے + + // پڑھنے کے لیے اضافی بائٹس کی تعداد + uint8 _extraBytes = _firstByte / 16; +``` + +نچلے [نببل](https://en.wikipedia.org/wiki/Nibble) کو لیں اور اسے دوسرے بائٹس کے ساتھ ملا کر کیش سے ویلیو پڑھیں۔ + +```solidity + uint _key = (uint256(_firstByte & 0x0F) << (8*_extraBytes)) + + _calldataVal(_fromByte+1, _extraBytes); + + return (_fromByte+_extraBytes+1, cacheRead(_key)); + + } // _readParam + + + // n پیرامیٹرز پڑھیں (فنکشنز جانتے ہیں کہ وہ کتنے پیرامیٹرز کی توقع کرتے ہیں) + function _readParams(uint _paramNum) internal returns (uint[] memory) { +``` + +ہم کال ڈیٹا سے ہی پیرامیٹرز کی تعداد حاصل کر سکتے ہیں، لیکن جو فنکشنز ہمیں کال کرتے ہیں وہ جانتے ہیں کہ وہ کتنے پیرامیٹرز کی توقع کرتے ہیں۔ انہیں ہمیں بتانے دینا آسان ہے۔ + +```solidity + // جو پیرامیٹرز ہم پڑھتے ہیں + uint[] memory params = new uint[](_paramNum); + + // پیرامیٹرز بائٹ 4 سے شروع ہوتے ہیں، اس سے پہلے فنکشن کا دستخط ہوتا ہے + uint _atByte = 4; + + for(uint i=0; i<_paramNum; i++) { + (_atByte, params[i]) = _readParam(_atByte); + } +``` + +پیرامیٹرز کو اس وقت تک پڑھیں جب تک آپ کے پاس مطلوبہ تعداد نہ ہو۔ اگر ہم کال ڈیٹا کے آخر سے آگے نکل جاتے ہیں، تو `_readParams` کال کو واپس کر دے گا۔ + +```solidity + + return(params); + } // readParams + + // _readParams کی جانچ کے لیے، چار پیرامیٹرز پڑھنے کی جانچ کریں + function fourParam() public + returns (uint256,uint256,uint256,uint256) + { + uint[] memory params; + params = _readParams(4); + return (params[0], params[1], params[2], params[3]); + } // fourParam +``` + +Foundry کا ایک بڑا فائدہ یہ ہے کہ یہ Solidity میں ٹیسٹ لکھنے کی اجازت دیتا ہے ([نیچے کیش کی جانچ دیکھیں](#testing-the-cache))۔ اس سے یونٹ ٹیسٹ بہت آسان ہو جاتے ہیں۔ یہ ایک ایسا فنکشن ہے جو چار پیرامیٹرز کو پڑھتا ہے اور انہیں واپس کرتا ہے تاکہ ٹیسٹ اس بات کی تصدیق کر سکے کہ وہ درست تھے۔ + +```solidity + // ایک ویلیو حاصل کریں، وہ بائٹس واپس کریں جو اسے انکوڈ کریں گے (اگر ممکن ہو تو کیش کا استعمال کرتے ہوئے) + function encodeVal(uint _val) public view returns(bytes memory) { +``` + +`encodeVal` ایک فنکشن ہے جسے آف چین کوڈ کال کرتا ہے تاکہ کال ڈیٹا بنانے میں مدد ملے جو کیش کا استعمال کرتا ہے۔ یہ ایک ویلیو وصول کرتا ہے اور ان بائٹس کو واپس کرتا ہے جو اسے انکوڈ کرتے ہیں۔ یہ فنکشن ایک `view` ہے، لہذا اسے ٹرانزیکشن کی ضرورت نہیں ہے اور جب بیرونی طور پر کال کیا جاتا ہے تو اس پر کوئی گیس لاگت نہیں آتی ہے۔ + +```solidity + uint _key = val2key[_val]; + + // ویلیو ابھی کیش میں نہیں ہے، اسے شامل کریں + if (_key == 0) + return bytes.concat(INTO_CACHE, bytes32(_val)); +``` + +[EVM](/developers/docs/evm/) میں تمام غیر شروع شدہ اسٹوریج کو صفر سمجھا جاتا ہے۔ لہذا اگر ہم کسی ایسی ویلیو کی کی (key) تلاش کرتے ہیں جو وہاں نہیں ہے، تو ہمیں صفر ملتا ہے۔ اس صورت میں جو بائٹس اسے انکوڈ کرتے ہیں وہ `INTO_CACHE` ہیں (تاکہ یہ اگلی بار کیش ہو جائے)، اس کے بعد اصل ویلیو ہوتی ہے۔ + +```solidity + // اگر کی (key) <0x10 ہے، تو اسے ایک بائٹ کے طور پر واپس کریں + if (_key < 0x10) + return bytes.concat(bytes1(uint8(_key))); +``` + +سنگل بائٹس سب سے آسان ہیں۔ ہم صرف [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) کا استعمال کرتے ہیں تاکہ `bytes` قسم کو بائٹ ارے میں تبدیل کیا جا سکے جو کسی بھی لمبائی کا ہو سکتا ہے۔ نام کے باوجود، یہ صرف ایک آرگیومنٹ فراہم کرنے پر ٹھیک کام کرتا ہے۔ + +```solidity + // دو بائٹ ویلیو، 0x1vvv کے طور پر انکوڈ کی گئی + if (_key < 0x1000) + return bytes.concat(bytes2(uint16(_key) | 0x1000)); +``` + +جب ہمارے پاس ایک کی (key) ہوتی ہے جو 163 سے کم ہوتی ہے، تو ہم اسے دو بائٹس میں ظاہر کر سکتے ہیں۔ ہم پہلے `_key` کو، جو 256 بٹ کی ویلیو ہے، 16 بٹ کی ویلیو میں تبدیل کرتے ہیں اور پہلے بائٹ میں اضافی بائٹس کی تعداد شامل کرنے کے لیے منطقی یا (logical or) کا استعمال کرتے ہیں۔ پھر ہم اسے `bytes2` ویلیو میں ڈالتے ہیں، جسے `bytes` میں تبدیل کیا جا سکتا ہے۔ + +```solidity + // مندرجہ ذیل لائنوں کو لوپ کے طور پر کرنے کا شاید کوئی ہوشیار طریقہ ہے، + // لیکن یہ ایک ویو فنکشن ہے اس لیے میں پروگرامر کے وقت اور + // سادگی کے لیے آپٹمائز کر رہا ہوں۔ + + if (_key < 16*256**2) + return bytes.concat(bytes3(uint24(_key) | (0x2 * 16 * 256**2))); + if (_key < 16*256**3) + return bytes.concat(bytes4(uint32(_key) | (0x3 * 16 * 256**3))); + . + . + . + if (_key < 16*256**14) + return bytes.concat(bytes15(uint120(_key) | (0xE * 16 * 256**14))); + if (_key < 16*256**15) + return bytes.concat(bytes16(uint128(_key) | (0xF * 16 * 256**15))); +``` + +دیگر ویلیوز (3 بائٹس، 4 بائٹس، وغیرہ) اسی طرح ہینڈل کی جاتی ہیں، صرف مختلف فیلڈ سائز کے ساتھ۔ + +```solidity + // اگر ہم یہاں پہنچ جاتے ہیں، تو کچھ غلط ہے۔ + revert("encodeVal میں خرابی، ایسا نہیں ہونا چاہیے"); +``` + +اگر ہم یہاں پہنچ جاتے ہیں تو اس کا مطلب ہے کہ ہمیں ایک ایسی کی (key) ملی ہے جو 16\*25615 سے کم نہیں ہے۔ لیکن `cacheWrite` کیز (keys) کو محدود کرتا ہے لہذا ہم 14\*25616 تک بھی نہیں پہنچ سکتے (جس کا پہلا بائٹ 0xFE ہوگا، لہذا یہ `DONT_CACHE` کی طرح نظر آئے گا)۔ لیکن مستقبل میں کسی پروگرامر کی طرف سے بگ متعارف کرانے کی صورت میں ٹیسٹ شامل کرنے میں ہمیں زیادہ لاگت نہیں آتی۔ + +```solidity + } // encodeVal + +} // Cache +``` + +### کیش کی جانچ {#testing-the-cache} + +Foundry کے فوائد میں سے ایک یہ ہے کہ [یہ آپ کو Solidity میں ٹیسٹ لکھنے دیتا ہے](https://getfoundry.sh/forge/tests/overview/)، جس سے یونٹ ٹیسٹ لکھنا آسان ہو جاتا ہے۔ `Cache` کلاس کے لیے ٹیسٹ [یہاں](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol) ہیں۔ چونکہ ٹیسٹنگ کوڈ بار بار ہوتا ہے، جیسا کہ ٹیسٹ ہوتے ہیں، یہ مضمون صرف دلچسپ حصوں کی وضاحت کرتا ہے۔ + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; + +import "forge-std/Test.sol"; + + +// کنسول کے لیے `forge test -vv` چلانے کی ضرورت ہے۔ +import "forge-std/console.sol"; +``` + +یہ صرف بوائلر پلیٹ ہے جو ٹیسٹ پیکیج اور `console.log` استعمال کرنے کے لیے ضروری ہے۔ + +```solidity +import "src/Cache.sol"; +``` + +ہمیں اس کنٹریکٹ کو جاننے کی ضرورت ہے جس کی ہم جانچ کر رہے ہیں۔ + +```solidity +contract CacheTest is Test { + Cache cache; + + function setUp() public { + cache = new Cache(); + } +``` + +`setUp` فنکشن ہر ٹیسٹ سے پہلے کال کیا جاتا ہے۔ اس صورت میں ہم صرف ایک نیا کیش بناتے ہیں، تاکہ ہمارے ٹیسٹ ایک دوسرے کو متاثر نہ کریں۔ + +```solidity + function testCaching() public { +``` + +ٹیسٹ وہ فنکشنز ہیں جن کے نام `test` سے شروع ہوتے ہیں۔ یہ فنکشن بنیادی کیش کی فعالیت، ویلیوز لکھنے اور انہیں دوبارہ پڑھنے کی جانچ کرتا ہے۔ + +```solidity + for(uint i=1; i<5000; i++) { + cache.cacheWrite(i*i); + } + + for(uint i=1; i<5000; i++) { + assertEq(cache.cacheRead(i), i*i); +``` + +یہ ہے کہ آپ اصل جانچ کیسے کرتے ہیں، [`assert...` فنکشنز](https://getfoundry.sh/reference/forge-std/std-assertions/) کا استعمال کرتے ہوئے۔ اس صورت میں، ہم جانچتے ہیں کہ ہم نے جو ویلیو لکھی ہے وہی ہے جو ہم نے پڑھی ہے۔ ہم `cache.cacheWrite` کے نتیجے کو مسترد کر سکتے ہیں کیونکہ ہم جانتے ہیں کہ کیش کیز (keys) لکیری طور پر تفویض کی جاتی ہیں۔ + +```solidity + } + } // testCaching + + + // ایک ہی ویلیو کو متعدد بار کیش کریں، یقینی بنائیں کہ کی (key) وہی + // رہتی ہے + function testRepeatCaching() public { + for(uint i=1; i<100; i++) { + uint _key1 = cache.cacheWrite(i); + uint _key2 = cache.cacheWrite(i); + assertEq(_key1, _key2); + } +``` + +پہلے ہم ہر ویلیو کو دو بار کیش میں لکھتے ہیں اور یقینی بناتے ہیں کہ کیز (keys) ایک جیسی ہیں (مطلب دوسری لکھائی واقعی نہیں ہوئی)۔ + +```solidity + for(uint i=1; i<100; i+=3) { + uint _key = cache.cacheWrite(i); + assertEq(_key, i); + } + } // testRepeatCaching +``` + +نظریاتی طور پر ایک ایسا بگ ہو سکتا ہے جو لگاتار کیش رائٹس کو متاثر نہیں کرتا ہے۔ لہذا یہاں ہم کچھ ایسی رائٹس کرتے ہیں جو لگاتار نہیں ہیں اور دیکھتے ہیں کہ ویلیوز اب بھی دوبارہ نہیں لکھی گئیں۔ + +```solidity + // میموری بفر سے ایک uint پڑھیں (یقینی بنانے کے لیے کہ ہمیں بھیجے گئے پیرامیٹرز + // واپس ملیں) + function toUint256(bytes memory _bytes, uint256 _start) internal pure + returns (uint256) +``` + +`bytes memory` بفر سے 256 بٹ کا ورڈ پڑھیں۔ یہ یوٹیلیٹی فنکشن ہمیں اس بات کی تصدیق کرنے دیتا ہے کہ جب ہم کیش کا استعمال کرنے والی فنکشن کال چلاتے ہیں تو ہمیں درست نتائج موصول ہوتے ہیں۔ + +```solidity + { + require(_bytes.length >= _start + 32, "toUint256_outOfBounds"); + uint256 tempUint; + + assembly { + tempUint := mload(add(add(_bytes, 0x20), _start)) + } +``` + +Yul `uint256` سے آگے ڈیٹا ڈھانچے کو سپورٹ نہیں کرتا، لہذا جب آپ کسی زیادہ نفیس ڈیٹا ڈھانچے کا حوالہ دیتے ہیں، جیسے میموری بفر `_bytes`، تو آپ کو اس ڈھانچے کا ایڈریس ملتا ہے۔ Solidity `bytes memory` ویلیوز کو 32 بائٹ ورڈ کے طور پر اسٹور کرتا ہے جس میں لمبائی ہوتی ہے، اس کے بعد اصل بائٹس ہوتے ہیں، لہذا بائٹ نمبر `_start` حاصل کرنے کے لیے ہمیں `_bytes+32+_start` کا حساب لگانے کی ضرورت ہے۔ + +```solidity + + return tempUint; + } // toUint256 + + // fourParams() کے لیے فنکشن کا دستخط، بشکریہ + // https://www.4byte.directory/signatures/?bytes4_signature=0x3edc1e6d + bytes4 constant FOUR_PARAMS = 0x3edc1e6d; + + // صرف کچھ مستقل ویلیوز یہ دیکھنے کے لیے کہ ہمیں صحیح ویلیوز واپس مل رہی ہیں + uint256 constant VAL_A = 0xDEAD60A7; + uint256 constant VAL_B = 0xBEEF; + uint256 constant VAL_C = 0x600D; + uint256 constant VAL_D = 0x600D60A7; +``` + +جانچ کے لیے ہمیں کچھ مستقل کی ضرورت ہے۔ + +```solidity + function testReadParam() public { +``` + +`fourParams()` کو کال کریں، ایک فنکشن جو `readParams` استعمال کرتا ہے، یہ جانچنے کے لیے کہ ہم پیرامیٹرز کو صحیح طریقے سے پڑھ سکتے ہیں۔ + +```solidity + address _cacheAddr = address(cache); + bool _success; + bytes memory _callInput; + bytes memory _callOutput; +``` + +ہم کیش کا استعمال کرتے ہوئے کسی فنکشن کو کال کرنے کے لیے عام ABI میکانزم کا استعمال نہیں کر سکتے، اس لیے ہمیں نچلی سطح کے [`
.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses) میکانزم کا استعمال کرنے کی ضرورت ہے۔ وہ میکانزم ان پٹ کے طور پر ایک `bytes memory` لیتا ہے، اور اسے (ساتھ ہی ایک بولین ویلیو) آؤٹ پٹ کے طور پر واپس کرتا ہے۔ + +```solidity + // پہلی کال، کیش خالی ہے + _callInput = bytes.concat( + FOUR_PARAMS, +``` + +ایک ہی کنٹریکٹ کے لیے کیشڈ فنکشنز (براہ راست ٹرانزیکشنز سے کالز کے لیے) اور نان-کیشڈ فنکشنز (دیگر اسمارٹ کنٹریکٹس سے کالز کے لیے) دونوں کو سپورٹ کرنا مفید ہے۔ ایسا کرنے کے لیے ہمیں صحیح فنکشن کو کال کرنے کے لیے Solidity میکانزم پر انحصار جاری رکھنے کی ضرورت ہے، بجائے اس کے کہ ہر چیز کو [ایک `فال بیک` فنکشن](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function) میں ڈالیں۔ ایسا کرنے سے کمپوزیبلیٹی بہت آسان ہو جاتی ہے۔ زیادہ تر معاملات میں فنکشن کی شناخت کے لیے ایک بائٹ کافی ہوگا، اس لیے ہم تین بائٹس (16\*3=48 گیس) ضائع کر رہے ہیں۔ تاہم، جیسا کہ میں یہ لکھ رہا ہوں ان 48 گیس کی قیمت 0.07 سینٹ ہے، جو آسان، کم بگ والے، کوڈ کے لیے ایک معقول قیمت ہے۔ + +```solidity + // پہلی ویلیو، اسے کیش میں شامل کریں + cache.INTO_CACHE(), + bytes32(VAL_A), +``` + +پہلی ویلیو: ایک جھنڈا جو کہتا ہے کہ یہ ایک مکمل ویلیو ہے جسے کیش میں لکھنے کی ضرورت ہے، اس کے بعد ویلیو کے 32 بائٹس۔ دیگر تین ویلیوز بھی اسی طرح کی ہیں، سوائے اس کے کہ `VAL_B` کو کیش میں نہیں لکھا گیا اور `VAL_C` تیسرا پیرامیٹر اور چوتھا پیرامیٹر دونوں ہے۔ + +```solidity + . + . + . + ); + (_success, _callOutput) = _cacheAddr.call(_callInput); +``` + +یہ وہ جگہ ہے جہاں ہم اصل میں `Cache` کنٹریکٹ کو کال کرتے ہیں۔ + +```solidity + assertEq(_success, true); +``` + +ہمیں امید ہے کہ کال کامیاب ہوگی۔ + +```solidity + assertEq(cache.cacheRead(1), VAL_A); + assertEq(cache.cacheRead(2), VAL_C); +``` + +ہم ایک خالی کیش سے شروع کرتے ہیں اور پھر `VAL_A` کے بعد `VAL_C` شامل کرتے ہیں۔ ہم توقع کریں گے کہ پہلے والے کی کی (key) 1 ہوگی، اور دوسرے والے کی 2 ہوگی۔ + +``` + assertEq(toUint256(_callOutput,0), VAL_A); + assertEq(toUint256(_callOutput,32), VAL_B); + assertEq(toUint256(_callOutput,64), VAL_C); + assertEq(toUint256(_callOutput,96), VAL_C); +``` + +آؤٹ پٹ چار پیرامیٹرز ہیں۔ یہاں ہم اس بات کی تصدیق کرتے ہیں کہ یہ درست ہے۔ + +```solidity + // دوسری کال، ہم کیش کا استعمال کر سکتے ہیں + _callInput = bytes.concat( + FOUR_PARAMS, + + // کیش میں پہلی ویلیو + bytes1(0x01), +``` + +16 سے نیچے کیش کیز (keys) صرف ایک بائٹ کی ہوتی ہیں۔ + +```solidity + // دوسری ویلیو، اسے کیش میں شامل نہ کریں + cache.DONT_CACHE(), + bytes32(VAL_B), + + // تیسری اور چوتھی ویلیوز، ایک ہی ویلیو + bytes1(0x02), + bytes1(0x02) + ); + . + . + . + } // testReadParam +``` + +کال کے بعد کے ٹیسٹ پہلی کال کے بعد کے ٹیسٹوں کی طرح ہیں۔ + +```solidity + function testEncodeVal() public { +``` + +یہ فنکشن `testReadParam` سے ملتا جلتا ہے، سوائے اس کے کہ پیرامیٹرز کو واضح طور پر لکھنے کے بجائے ہم `encodeVal()` استعمال کرتے ہیں۔ + +```solidity + . + . + . + _callInput = bytes.concat( + FOUR_PARAMS, + cache.encodeVal(VAL_A), + cache.encodeVal(VAL_B), + cache.encodeVal(VAL_C), + cache.encodeVal(VAL_D) + ); + . + . + . + assertEq(_callInput.length, 4+1*4); + } // testEncodeVal +``` + +`testEncodeVal()` میں واحد اضافی ٹیسٹ یہ تصدیق کرنا ہے کہ `_callInput` کی لمبائی درست ہے۔ پہلی کال کے لیے یہ 4+33\*4 ہے۔ دوسرے کے لیے، جہاں ہر ویلیو پہلے سے ہی کیش میں ہے، یہ 4+1\*4 ہے۔ + +```solidity + // encodeVal کی جانچ کریں جب کی (key) ایک بائٹ سے زیادہ ہو + // زیادہ سے زیادہ تین بائٹس کیونکہ کیش کو چار بائٹس تک بھرنے میں + // بہت زیادہ وقت لگتا ہے۔ + function testEncodeValBig() public { + // کیش میں کئی ویلیوز ڈالیں۔ + // چیزوں کو آسان رکھنے کے لیے، ویلیو n کے لیے کی (key) n استعمال کریں۔ + for(uint i=1; i<0x1FFF; i++) { + cache.cacheWrite(i); + } +``` + +اوپر `testEncodeVal` فنکشن کیش میں صرف چار ویلیوز لکھتا ہے، اس لیے [فنکشن کا وہ حصہ جو ملٹی بائٹ ویلیوز سے نمٹتا ہے](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) چیک نہیں کیا جاتا ہے۔ لیکن وہ کوڈ پیچیدہ اور غلطی کا شکار ہے۔ + +اس فنکشن کا پہلا حصہ ایک لوپ ہے جو 1 سے 0x1FFF تک کی تمام ویلیوز کو ترتیب سے کیش میں لکھتا ہے، لہذا ہم ان ویلیوز کو انکوڈ کر سکیں گے اور جان سکیں گے کہ وہ کہاں جا رہی ہیں۔ + +```solidity + . + . + . + + _callInput = bytes.concat( + FOUR_PARAMS, + cache.encodeVal(0x000F), // ایک بائٹ 0x0F + cache.encodeVal(0x0010), // دو بائٹس 0x1010 + cache.encodeVal(0x0100), // دو بائٹس 0x1100 + cache.encodeVal(0x1000) // تین بائٹس 0x201000 + ); +``` + +ایک بائٹ، دو بائٹ، اور تین بائٹ ویلیوز کی جانچ کریں۔ ہم اس سے آگے کی جانچ نہیں کرتے ہیں کیونکہ کافی اسٹیک اندراجات لکھنے میں بہت زیادہ وقت لگے گا (کم از کم 0x10000000، تقریباً ایک چوتھائی ارب)۔ + +```solidity + . + . + . + . + } // testEncodeValBig + + + // ٹیسٹ کریں کہ ضرورت سے زیادہ چھوٹے بفر کے ساتھ ہمیں ایک ریورٹ ملتا ہے + function testShortCalldata() public { +``` + +جانچ کریں کہ غیر معمولی صورت میں کیا ہوتا ہے جہاں کافی پیرامیٹرز نہیں ہوتے ہیں۔ + +```solidity + . + . + . + (_success, _callOutput) = _cacheAddr.call(_callInput); + assertEq(_success, false); + } // testShortCalldata +``` + +چونکہ یہ ریورٹ ہوتا ہے، اس لیے ہمیں جو نتیجہ ملنا چاہیے وہ `غلط` ہے۔ + +``` + // کیش کیز (keys) کے ساتھ کال کریں جو وہاں نہیں ہیں + function testNoCacheKey() public { + . + . + . + _callInput = bytes.concat( + FOUR_PARAMS, + + // پہلی ویلیو، اسے کیش میں شامل کریں + cache.INTO_CACHE(), + bytes32(VAL_A), + + // دوسری ویلیو + bytes1(0x0F), + bytes2(0x1234), + bytes11(0xA10102030405060708090A) + ); +``` + +یہ فنکشن چار بالکل جائز پیرامیٹرز حاصل کرتا ہے، سوائے اس کے کہ کیش خالی ہے لہذا وہاں پڑھنے کے لیے کوئی ویلیو نہیں ہے۔ + +```solidity + . + . + . + // ٹیسٹ کریں کہ ضرورت سے زیادہ لمبے بفر کے ساتھ سب کچھ فائل کام کرتا ہے + function testLongCalldata() public { + address _cacheAddr = address(cache); + bool _success; + bytes memory _callInput; + bytes memory _callOutput; + + // پہلی کال، کیش خالی ہے + _callInput = bytes.concat( + FOUR_PARAMS, + + // پہلی ویلیو، اسے کیش میں شامل کریں + cache.INTO_CACHE(), bytes32(VAL_A), + + // دوسری ویلیو، اسے کیش میں شامل کریں + cache.INTO_CACHE(), bytes32(VAL_B), + + // تیسری ویلیو، اسے کیش میں شامل کریں + cache.INTO_CACHE(), bytes32(VAL_C), + + // چوتھی ویلیو، اسے کیش میں شامل کریں + cache.INTO_CACHE(), bytes32(VAL_D), + + // اور "اچھی قسمت" کے لیے ایک اور ویلیو + bytes4(0x31112233) + ); +``` + +یہ فنکشن پانچ ویلیوز بھیجتا ہے۔ ہم جانتے ہیں کہ پانچویں ویلیو کو نظر انداز کر دیا جاتا ہے کیونکہ یہ ایک درست کیش انٹری نہیں ہے، جو اگر شامل نہ کی جاتی تو ریورٹ کا سبب بنتی۔ + +```solidity + (_success, _callOutput) = _cacheAddr.call(_callInput); + assertEq(_success, true); + . + . + . + } // testLongCalldata + +} // CacheTest + +``` + +## ایک نمونہ ایپلی کیشن {#a-sample-app} + +Solidity میں ٹیسٹ لکھنا بہت اچھا ہے، لیکن دن کے آخر میں ایک dapp کو مفید ہونے کے لیے چین کے باہر سے درخواستوں پر کارروائی کرنے کے قابل ہونا چاہیے۔ یہ مضمون یہ ظاہر کرتا ہے کہ `WORM` کے ساتھ dapp میں کیشنگ کا استعمال کیسے کیا جائے، جس کا مطلب ہے "ایک بار لکھیں، کئی بار پڑھیں"۔ اگر کوئی کی (key) ابھی تک نہیں لکھی گئی ہے، تو آپ اس میں ایک ویلیو لکھ سکتے ہیں۔ اگر کی (key) پہلے سے لکھی ہوئی ہے، تو آپ کو ایک ریورٹ ملتا ہے۔ + +### کنٹریکٹ {#the-contract} + +[یہ کنٹریکٹ ہے](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol)۔ یہ زیادہ تر وہی دہراتا ہے جو ہم نے `Cache` اور `CacheTest` کے ساتھ پہلے ہی کیا ہے، لہذا ہم صرف ان حصوں کا احاطہ کرتے ہیں جو دلچسپ ہیں۔ + +```solidity +import "./Cache.sol"; + +contract WORM is Cache { +``` + +`Cache` استعمال کرنے کا سب سے آسان طریقہ یہ ہے کہ اسے اپنے کنٹریکٹ میں وراثت میں حاصل کریں۔ + +```solidity + function writeEntryCached() external { + uint[] memory params = _readParams(2); + writeEntry(params[0], params[1]); + } // writeEntryCached +``` + +یہ فنکشن اوپر `CacheTest` میں `fourParam` سے ملتا جلتا ہے۔ چونکہ ہم ABI کی تفصیلات پر عمل نہیں کرتے ہیں، اس لیے بہتر ہے کہ فنکشن میں کوئی پیرامیٹر نہ ڈکلیئر کریں۔ + +```solidity + // ہمیں کال کرنا آسان بنائیں + // writeEntryCached() کے لیے فنکشن کا دستخط، بشکریہ + // https://www.4byte.directory/signatures/?bytes4_signature=0xe4e4f2d3 + bytes4 constant public WRITE_ENTRY_CACHED = 0xe4e4f2d3; +``` + +بیرونی کوڈ جو `writeEntryCached` کو کال کرتا ہے، اسے دستی طور پر کال ڈیٹا بنانا ہوگا، بجائے اس کے کہ `worm.writeEntryCached` استعمال کیا جائے، کیونکہ ہم ABI کی تفصیلات پر عمل نہیں کرتے ہیں۔ اس مستقل ویلیو کا ہونا اسے لکھنا آسان بنا دیتا ہے۔ + +نوٹ کریں کہ اگرچہ ہم `WRITE_ENTRY_CACHED` کو ایک اسٹیٹ ویری ایبل کے طور پر بیان کرتے ہیں، اسے بیرونی طور پر پڑھنے کے لیے اس کے لیے گیٹر فنکشن، `worm.WRITE_ENTRY_CACHED()` کا استعمال کرنا ضروری ہے۔ + +```solidity + function readEntry(uint key) public view + returns (uint _value, address _writtenBy, uint _writtenAtBlock) +``` + +ریڈ فنکشن ایک `view` ہے، لہذا اسے ٹرانزیکشن کی ضرورت نہیں ہے اور اس پر کوئی گیس لاگت نہیں آتی ہے۔ نتیجے کے طور پر، پیرامیٹر کے لیے کیش استعمال کرنے کا کوئی فائدہ نہیں ہے۔ ویو فنکشنز کے ساتھ معیاری میکانزم کا استعمال کرنا بہتر ہے جو آسان ہے۔ + +### جانچ کا کوڈ {#the-testing-code} + +[یہ کنٹریکٹ کے لیے جانچ کا کوڈ ہے](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol)۔ ایک بار پھر، آئیے صرف اس پر نظر ڈالتے ہیں جو دلچسپ ہے۔ + +```solidity + function testWReadWrite() public { + worm.writeEntry(0xDEAD, 0x60A7); + + vm.expectRevert(bytes("انٹری پہلے ہی لکھی جا چکی ہے")); + worm.writeEntry(0xDEAD, 0xBEEF); +``` + +[یہ (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) ہے کہ ہم Foundry ٹیسٹ میں کیسے بتاتے ہیں کہ اگلی کال ناکام ہونی چاہیے، اور ناکامی کی اطلاع دی گئی وجہ۔ یہ اس وقت لاگو ہوتا ہے جب ہم `.` کا نحو استعمال کرتے ہیں()` بجائے اس کے کہ کال ڈیٹا بنایا جائے اور کنٹریکٹ کو نچلی سطح کے انٹرفیس (`.call()`، وغیرہ) کا استعمال کرکے کال کیا جائے۔ + +```solidity + function testReadWriteCached() public { + uint cacheGoat = worm.cacheWrite(0x60A7); +``` + +یہاں ہم اس حقیقت کا استعمال کرتے ہیں کہ `cacheWrite` کیش کی (key) واپس کرتا ہے۔ یہ ایسی چیز نہیں ہے جس کی ہم پیداوار میں استعمال کی توقع کریں گے، کیونکہ `cacheWrite` اسٹیٹ کو تبدیل کرتا ہے، اور اس لیے اسے صرف ٹرانزیکشن کے دوران ہی کال کیا جا سکتا ہے۔ ٹرانزیکشنز میں واپسی کی ویلیوز نہیں ہوتی ہیں، اگر ان کے نتائج ہوتے ہیں تو ان نتائج کو ایونٹس کے طور پر خارج کیا جانا چاہیے۔ لہذا `cacheWrite` کی واپسی کی ویلیو صرف آن چین کوڈ سے قابل رسائی ہے، اور آن چین کوڈ کو پیرامیٹر کیشنگ کی ضرورت نہیں ہے۔ + +```solidity + (_success,) = address(worm).call(_callInput); +``` + +یہ ہے کہ ہم Solidity کو کیسے بتاتے ہیں کہ جب کہ `.call()` کی دو واپسی کی ویلیوز ہیں، ہم صرف پہلی کی پرواہ کرتے ہیں۔ + +```solidity + (_success,) = address(worm).call(_callInput); + assertEq(_success, false); +``` + +چونکہ ہم نچلی سطح کے `
.call()` فنکشن کا استعمال کرتے ہیں، اس لیے ہم `vm.expectRevert()` کا استعمال نہیں کر سکتے اور ہمیں کال سے ملنے والی بولین کامیابی کی ویلیو کو دیکھنا ہوگا۔ + +```solidity + event EntryWritten(uint indexed key, uint indexed value); + + . + . + . + + _callInput = bytes.concat( + worm.WRITE_ENTRY_CACHED(), worm.encodeVal(a), worm.encodeVal(b)); + vm.expectEmit(true, true, false, false); + emit EntryWritten(a, b); + (_success,) = address(worm).call(_callInput); +``` + +یہ وہ طریقہ ہے جس سے ہم تصدیق کرتے ہیں کہ کوڈ Foundry میں [ایک ایونٹ کو صحیح طریقے سے خارج کرتا ہے](https://getfoundry.sh/reference/cheatcodes/expect-emit/)۔ + +### کلائنٹ {#the-client} + +ایک چیز جو آپ کو Solidity ٹیسٹوں کے ساتھ نہیں ملتی ہے وہ ہے JavaScript کوڈ جسے آپ اپنی ایپلی کیشن میں کاٹ اور پیسٹ کر سکتے ہیں۔ اس کوڈ کو لکھنے کے لیے میں نے WORM کو [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli) پر تعینات کیا، [Optimism](https://www.optimism.io/) کا نیا ٹیسٹ نیٹ۔ یہ ایڈریس [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a) پر ہے۔ + +[آپ یہاں کلائنٹ کے لیے JavaScript کوڈ دیکھ سکتے ہیں](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js)۔ اسے استعمال کرنے کے لیے: + +1. گٹ ریپوزٹری کو کلون کریں: + + ```sh + git clone https://github.com/qbzzt/20220915-all-you-can-cache.git + ``` + +2. ضروری پیکیجز انسٹال کریں: + + ```sh + cd javascript + yarn + ``` + +3. کنفیگریشن فائل کاپی کریں: + + ```sh + cp .env.example .env + ``` + +4. اپنی کنفیگریشن کے لیے `.env` میں ترمیم کریں: + + | پیرامیٹر | قدر | + | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | + | MNEMONIC | ایک اکاؤنٹ کے لیے یادداشت جس میں ٹرانزیکشن کی ادائیگی کے لیے کافی ETH ہو۔ [آپ یہاں Optimism Goerli نیٹ ورک کے لیے مفت ETH حاصل کر سکتے ہیں](https://optimismfaucet.xyz/)۔ | + | OPTIMISM_GOERLI_URL | Optimism Goerli کا URL۔ عوامی اینڈ پوائنٹ، `https://goerli.optimism.io`، شرح محدود ہے لیکن یہاں ہماری ضرورت کے لیے کافی ہے | + +5. `index.js` چلائیں۔ + + ```sh + node index.js + ``` + + یہ نمونہ ایپلی کیشن پہلے WORM میں ایک انٹری لکھتی ہے، کال ڈیٹا اور Etherscan پر ٹرانزیکشن کا لنک دکھاتی ہے۔ پھر یہ اس انٹری کو واپس پڑھتا ہے، اور اس کی استعمال کردہ کی (key) اور انٹری میں ویلیوز (ویلیو، بلاک نمبر، اور مصنف) دکھاتا ہے۔ + +زیادہ تر کلائنٹ عام Dapp JavaScript ہے۔ تو ایک بار پھر ہم صرف دلچسپ حصوں پر جائیں گے۔ + +```javascript +. +. +. +const main = async () => { + const func = await worm.WRITE_ENTRY_CACHED() + + // ہر بار ایک نئی کی (key) کی ضرورت ہے + const key = await worm.encodeVal(Number(new Date())) +``` + +ایک دیئے گئے سلاٹ میں صرف ایک بار لکھا جا سکتا ہے، لہذا ہم ٹائم اسٹیمپ کا استعمال کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ ہم سلاٹس کو دوبارہ استعمال نہ کریں۔ + +```javascript +const val = await worm.encodeVal("0x600D") + +// ایک انٹری لکھیں +const calldata = func + key.slice(2) + val.slice(2) +``` + +Ethers توقع کرتا ہے کہ کال ڈیٹا ایک ہیکس سٹرنگ ہوگا، `0x` کے بعد ہیکساڈیسیمل ہندسوں کی ایک جفت تعداد۔ چونکہ `key` اور `val` دونوں `0x` سے شروع ہوتے ہیں، ہمیں ان ہیڈرز کو ہٹانے کی ضرورت ہے۔ + +```javascript +const tx = await worm.populateTransaction.writeEntryCached() +tx.data = calldata + +sentTx = await wallet.sendTransaction(tx) +``` + +جیسا کہ Solidity ٹیسٹنگ کوڈ کے ساتھ ہے، ہم عام طور پر کیشڈ فنکشن کو کال نہیں کر سکتے۔ اس کے بجائے، ہمیں نچلی سطح کے میکانزم کا استعمال کرنے کی ضرورت ہے۔ + +```javascript + . + . + . + // ابھی لکھی گئی انٹری کو پڑھیں + const realKey = '0x' + key.slice(4) // FF فلیگ کو ہٹائیں + const entryRead = await worm.readEntry(realKey) + . + . + . +``` + +انٹریز پڑھنے کے لیے ہم عام میکانزم کا استعمال کر سکتے ہیں۔ `view` فنکشنز کے ساتھ پیرامیٹر کیشنگ استعمال کرنے کی ضرورت نہیں ہے۔ + +## نتیجہ {#conclusion} + +اس مضمون میں کوڈ تصور کا ثبوت ہے، مقصد اس خیال کو سمجھنے میں آسان بنانا ہے۔ پیداوار کے لیے تیار نظام کے لیے آپ کو کچھ اضافی فعالیت نافذ کرنے کی ضرورت پڑ سکتی ہے: + +- ان ویلیوز کو ہینڈل کریں جو `uint256` نہیں ہیں۔ مثال کے طور پر، سٹرنگز۔ +- عالمی کیش کے بجائے، شاید صارفین اور کیشز کے درمیان ایک میپنگ ہو۔ مختلف صارفین مختلف ویلیوز استعمال کرتے ہیں۔ +- ایڈریسز کے لیے استعمال ہونے والی ویلیوز دیگر مقاصد کے لیے استعمال ہونے والی ویلیوز سے الگ ہیں۔ صرف ایڈریسز کے لیے ایک علیحدہ کیش رکھنا سمجھ میں آ سکتا ہے۔ +- فی الحال، کیش کیز (keys) "پہلے آؤ، سب سے چھوٹی کی (key)" الگورتھم پر ہیں۔ پہلی سولہ ویلیوز کو ایک بائٹ کے طور پر بھیجا جا سکتا ہے۔ اگلی 4080 ویلیوز کو دو بائٹس کے طور پر بھیجا جا سکتا ہے۔ اگلی تقریباً ملین ویلیوز تین بائٹس ہیں، وغیرہ۔ ایک پروڈکشن سسٹم کو کیش اندراجات پر استعمال کے کاؤنٹرز رکھنے چاہئیں اور انہیں دوبارہ منظم کرنا چاہیے تاکہ سولہ _سب سے عام_ ویلیوز ایک بائٹ ہوں، اگلی 4080 سب سے عام ویلیوز دو بائٹس ہوں، وغیرہ۔ + + تاہم، یہ ایک ممکنہ طور پر خطرناک آپریشن ہے۔ مندرجہ ذیل واقعات کی ترتیب کا تصور کریں: + + 1. نوآم نائیو ٹوکن بھیجنے کے لیے ایڈریس کو انکوڈ کرنے کے لیے `encodeVal` کو کال کرتا ہے۔ وہ ایڈریس ایپلی کیشن پر استعمال ہونے والے پہلے ایڈریسز میں سے ایک ہے، اس لیے انکوڈ شدہ ویلیو 0x06 ہے۔ یہ ایک `view` فنکشن ہے، ٹرانزیکشن نہیں، اس لیے یہ نوآم اور اس کے استعمال کردہ نوڈ کے درمیان ہے، اور کوئی اور اس کے بارے میں نہیں جانتا + + 2. اوون اونر کیش ری آرڈرنگ آپریشن چلاتا ہے۔ بہت کم لوگ اصل میں اس ایڈریس کا استعمال کرتے ہیں، لہذا اب اسے 0x201122 کے طور پر انکوڈ کیا گیا ہے۔ ایک مختلف ویلیو، 1018، کو 0x06 تفویض کیا گیا ہے۔ + + 3. نوآم نائیو اپنے ٹوکنز 0x06 پر بھیجتا ہے۔ وہ ایڈریس `0x0000000000000000000000000de0b6b3a7640000` پر جاتے ہیں، اور چونکہ کوئی بھی اس ایڈریس کی پرائیویٹ کی (key) نہیں جانتا، وہ وہیں پھنس جاتے ہیں۔ نوآم _خوش نہیں_ ہے۔ + + اس مسئلے کو حل کرنے کے طریقے ہیں، اور کیش کی دوبارہ ترتیب کے دوران میم پول میں موجود ٹرانزیکشنز کے متعلقہ مسئلے کو بھی، لیکن آپ کو اس سے آگاہ ہونا چاہیے۔ + +میں نے یہاں Optimism کے ساتھ کیشنگ کا مظاہرہ کیا، کیونکہ میں ایک Optimism ملازم ہوں اور یہ وہ رول اپ ہے جسے میں سب سے بہتر جانتا ہوں۔ لیکن اسے کسی بھی ایسے رول اپ کے ساتھ کام کرنا چاہیے جو اندرونی پروسیسنگ کے لیے کم سے کم لاگت وصول کرتا ہو، تاکہ اس کے مقابلے میں L1 پر ٹرانزیکشن ڈیٹا لکھنا بڑا خرچ ہو۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ + diff --git a/public/content/translations/ur/developers/tutorials/app-plasma/index.md b/public/content/translations/ur/developers/tutorials/app-plasma/index.md new file mode 100644 index 00000000000..a76e13b43ce --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/app-plasma/index.md @@ -0,0 +1,1255 @@ +--- +title: "ایک ایپ کے لیے مخصوص پلازما لکھیں جو پرائیویسی کو محفوظ رکھتا ہے" +description: "اس ٹیوٹوریل میں، ہم ڈپازٹس کے لیے ایک نیم خفیہ بینک بناتے ہیں۔ بینک ایک مرکزی جزو ہے؛ یہ ہر صارف کا بیلنس جانتا ہے۔ تاہم، یہ معلومات آن چین ذخیرہ نہیں کی جاتی ہے۔ اس کے بجائے، بینک اسٹیٹ کا ایک ہیش پوسٹ کرتا ہے۔ جب بھی کوئی ٹرانزیکشن ہوتا ہے، بینک نیا ہیش پوسٹ کرتا ہے، ساتھ ہی ایک زیرو-نالج پروف بھی کہ اس کے پاس ایک دستخط شدہ ٹرانزیکشن ہے جو ہیش اسٹیٹ کو نئے میں بدل دیتا ہے۔ اس ٹیوٹوریل کو پڑھنے کے بعد، آپ نہ صرف یہ سمجھیں گے کہ زیرو-نالج پروف کا استعمال کیسے کریں، بلکہ یہ بھی کہ آپ انہیں کیوں استعمال کرتے ہیں اور اسے محفوظ طریقے سے کیسے کریں۔" +author: Ori Pomerantz +tags: [ "زیرو-نالج", "سرور", "آف چین", "رازداری" ] +skill: advanced +lang: ur-in +published: 2025-10-15 +--- + +## تعارف {#introduction} + +[رول اپس](/developers/docs/scaling/zk-rollups/) کے برعکس، [پلازما](/developers/docs/scaling/plasma) انٹیگریٹی کے لیے Ethereum مین نیٹ کا استعمال کرتے ہیں، لیکن دستیابی کے لیے نہیں۔ اس مضمون میں، ہم ایک ایسی ایپلیکیشن لکھتے ہیں جو پلازما کی طرح برتاؤ کرتی ہے، جس میں Ethereum انٹیگریٹی (کوئی غیر مجاز تبدیلیاں نہیں) کی ضمانت دیتا ہے لیکن دستیابی کی نہیں (ایک مرکزی جزو ڈاؤن ہو سکتا ہے اور پورے سسٹم کو غیر فعال کر سکتا ہے)۔ + +جو ایپلیکیشن ہم یہاں لکھتے ہیں وہ ایک پرائیویسی کو محفوظ رکھنے والا بینک ہے۔ مختلف پتوں کے پاس بیلنس والے اکاؤنٹس ہوتے ہیں، اور وہ دوسرے اکاؤنٹس میں رقم (ETH) بھیج سکتے ہیں۔ بینک اسٹیٹ (اکاؤنٹس اور ان کے بیلنس) اور ٹرانزیکشنز کے ہیش پوسٹ کرتا ہے، لیکن اصل بیلنس کو آف چین رکھتا ہے جہاں وہ نجی رہ سکتے ہیں۔ + +## ڈیزائن {#design} + +یہ پروڈکشن کے لیے تیار سسٹم نہیں ہے، بلکہ ایک تدریسی ٹول ہے۔ اس طرح، اسے کئی آسان بنانے والے مفروضوں کے ساتھ لکھا گیا ہے۔ + +- فکسڈ اکاؤنٹ پول۔ اکاؤنٹس کی ایک مخصوص تعداد ہے، اور ہر اکاؤنٹ ایک پہلے سے طے شدہ پتے سے تعلق رکھتا ہے۔ یہ ایک بہت آسان نظام بناتا ہے کیونکہ زیرو-نالج پروف میں متغیر سائز کے ڈیٹا ڈھانچے کو سنبھالنا مشکل ہے۔ پروڈکشن کے لیے تیار سسٹم کے لیے، ہم [مرکل روٹ](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) کو اسٹیٹ ہیش کے طور پر استعمال کر سکتے ہیں اور مطلوبہ بیلنس کے لیے مرکل پروف فراہم کر سکتے ہیں۔ + +- میموری اسٹوریج۔ پروڈکشن سسٹم پر، ہمیں تمام اکاؤنٹ بیلنس کو ڈسک پر لکھنے کی ضرورت ہے تاکہ انہیں دوبارہ شروع ہونے کی صورت میں محفوظ رکھا جا سکے۔ یہاں، یہ ٹھیک ہے اگر معلومات آسانی سے ضائع ہو جائیں۔ + +- صرف ٹرانسفرز۔ ایک پروڈکشن سسٹم کو بینک میں اثاثے جمع کرنے اور انہیں نکالنے کے ایک طریقے کی ضرورت ہوگی۔ لیکن یہاں مقصد صرف تصور کی وضاحت کرنا ہے، اس لیے یہ بینک صرف ٹرانسفرز تک محدود ہے۔ + +### زیرو-نالج پروفس {#zero-knowledge-proofs} + +بنیادی سطح پر، ایک زیرو-نالج پروف یہ ظاہر کرتا ہے کہ پروور کچھ ڈیٹا، _Dataprivate_ کو جانتا ہے، اس طرح کہ کچھ عوامی ڈیٹا، _Datapublic_، اور _Dataprivate_ کے درمیان ایک رشتہ _Relationship_ موجود ہے۔ تصدیق کنندہ _Relationship_ اور _Datapublic_ کو جانتا ہے۔ + +پرائیویسی کو محفوظ رکھنے کے لیے، ہمیں اسٹیٹس اور ٹرانزیکشنز کو نجی رکھنے کی ضرورت ہے۔ لیکن انٹیگریٹی کو یقینی بنانے کے لیے، ہمیں اسٹیٹس کے [کرپٹوگرافک ہیش](https://en.wikipedia.org/wiki/Cryptographic_hash_function) کو عوامی رکھنے کی ضرورت ہے۔ ان لوگوں کو ثابت کرنے کے لیے جو ٹرانزیکشنز جمع کرتے ہیں کہ وہ ٹرانزیکشنز واقعی ہوئے، ہمیں ٹرانزیکشن ہیش بھی پوسٹ کرنے کی ضرورت ہے۔ + +زیادہ تر معاملات میں، _Dataprivate_ زیرو-نالج پروف پروگرام کا ان پٹ ہے، اور _Datapublic_ آؤٹ پٹ ہے۔ + +_Dataprivate_ میں یہ فیلڈز: + +- _اسٹیٹn_، پرانی اسٹیٹ +- _اسٹیٹn+1_، نئی اسٹیٹ +- _ٹرانزیکشن_، ایک ٹرانزیکشن جو پرانی اسٹیٹ سے نئی میں بدلتا ہے۔ اس ٹرانزیکشن میں یہ فیلڈز شامل ہونے چاہئیں: + - _منزل کا پتہ_ جو ٹرانسفر وصول کرتا ہے + - ٹرانسفر کی جانے والی _رقم_ + - _نونس_ یہ یقینی بنانے کے لیے کہ ہر ٹرانزیکشن پر صرف ایک بار کارروائی کی جا سکتی ہے۔ + سورس ایڈریس کو ٹرانزیکشن میں ہونے کی ضرورت نہیں ہے، کیونکہ اسے دستخط سے بازیافت کیا جا سکتا ہے۔ +- _دستخط_، ایک دستخط جو ٹرانزیکشن انجام دینے کے لیے مجاز ہے۔ ہمارے معاملے میں، ٹرانزیکشن انجام دینے کے لیے مجاز واحد پتہ سورس ایڈریس ہے۔ چونکہ ہمارا زیرو-نالج سسٹم جس طرح سے کام کرتا ہے، ہمیں Ethereum دستخط کے علاوہ، اکاؤنٹ کی پبلک کی بھی ضرورت ہے۔ + +یہ _Datapublic_ میں فیلڈز ہیں: + +- _ہیش(اسٹیٹn)_ پرانی اسٹیٹ کا ہیش +- _ہیش(اسٹیٹn+1)_ نئی اسٹیٹ کا ہیش +- _ہیش(ٹرانزیکشن)_ اس ٹرانزیکشن کا ہیش جو اسٹیٹ کو _اسٹیٹn_ سے _اسٹیٹn+1_ میں بدلتا ہے۔ + +یہ رشتہ کئی شرائط کی جانچ کرتا ہے: + +- عوامی ہیش واقعی نجی فیلڈز کے لیے درست ہیش ہیں۔ +- ٹرانزیکشن، جب پرانی اسٹیٹ پر لاگو ہوتا ہے، تو نئی اسٹیٹ کا نتیجہ نکلتا ہے۔ +- دستخط ٹرانزیکشن کے سورس ایڈریس سے آتا ہے۔ + +کرپٹوگرافک ہیش فنکشنز کی خصوصیات کی وجہ سے، ان شرائط کو ثابت کرنا انٹیگریٹی کو یقینی بنانے کے لیے کافی ہے۔ + +### ڈیٹا کی ساختیں {#data-structures} + +بنیادی ڈیٹا ڈھانچہ سرور کے زیر اہتمام اسٹیٹ ہے۔ ہر اکاؤنٹ کے لیے، سرور اکاؤنٹ بیلنس اور ایک [نونس](https://en.wikipedia.org/wiki/Cryptographic_nonce) کا ٹریک رکھتا ہے، جو [ری پلے حملوں](https://en.wikipedia.org/wiki/Replay_attack) کو روکنے کے لیے استعمال ہوتا ہے۔ + +### اجزاء {#components} + +اس سسٹم کو دو اجزاء کی ضرورت ہے: + +- _سرور_ جو ٹرانزیکشنز وصول کرتا ہے، ان پر کارروائی کرتا ہے، اور زیرو-نالج پروفس کے ساتھ چین پر ہیش پوسٹ کرتا ہے۔ +- ایک _اسمارٹ کنٹریکٹ_ جو ہیش کو ذخیرہ کرتا ہے اور یہ یقینی بنانے کے لیے کہ اسٹیٹ کی منتقلی جائز ہے، زیرو-نالج پروفس کی تصدیق کرتا ہے۔ + +### ڈیٹا اور کنٹرول فلو {#flows} + +یہ وہ طریقے ہیں جن سے مختلف اجزاء ایک اکاؤنٹ سے دوسرے میں ٹرانسفر کرنے کے لیے مواصلت کرتے ہیں۔ + +1. ایک ویب براؤزر ایک دستخط شدہ ٹرانزیکشن جمع کرتا ہے جس میں دستخط کنندہ کے اکاؤنٹ سے ایک مختلف اکاؤنٹ میں ٹرانسفر کی درخواست کی جاتی ہے۔ + +2. سرور تصدیق کرتا ہے کہ ٹرانزیکشن درست ہے: + + - دستخط کنندہ کے پاس بینک میں کافی بیلنس والا ایک اکاؤنٹ ہے۔ + - وصول کنندہ کا بینک میں ایک اکاؤنٹ ہے۔ + +3. سرور دستخط کنندہ کے بیلنس سے منتقل کی گئی رقم کو گھٹا کر اور اسے وصول کنندہ کے بیلنس میں شامل کرکے نئی اسٹیٹ کا حساب لگاتا ہے۔ + +4. سرور ایک زیرو-نالج پروف کا حساب لگاتا ہے کہ اسٹیٹ کی تبدیلی ایک درست ہے۔ + +5. سرور Ethereum کو ایک ٹرانزیکشن جمع کرتا ہے جس میں شامل ہیں: + + - نئی اسٹیٹ ہیش + - ٹرانزیکشن ہیش (تاکہ ٹرانزیکشن بھیجنے والے کو معلوم ہو کہ اس پر کارروائی ہو چکی ہے) + - زیرو-نالج پروف جو یہ ثابت کرتا ہے کہ نئی اسٹیٹ میں منتقلی درست ہے + +6. اسمارٹ کنٹریکٹ زیرو-نالج پروف کی تصدیق کرتا ہے۔ + +7. اگر زیرو-نالج پروف چیک آؤٹ ہو جاتا ہے، تو اسمارٹ کنٹریکٹ یہ کارروائیاں کرتا ہے: + - موجودہ اسٹیٹ ہیش کو نئی اسٹیٹ ہیش میں اپ ڈیٹ کریں + - نئی اسٹیٹ ہیش اور ٹرانزیکشن ہیش کے ساتھ ایک لاگ انٹری جاری کریں + +### ٹولز {#tools} + +کلائنٹ سائڈ کوڈ کے لیے، ہم [Vite](https://vite.dev/)، [React](https://react.dev/)، [Viem](https://viem.sh/)، اور [Wagmi](https://wagmi.sh/) کا استعمال کرنے جا رہے ہیں۔ یہ انڈسٹری کے معیاری ٹولز ہیں؛ اگر آپ ان سے واقف نہیں ہیں، تو آپ [یہ ٹیوٹوریل](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) استعمال کر سکتے ہیں۔ + +سرور کا زیادہ تر حصہ [Node](https://nodejs.org/en) کا استعمال کرتے ہوئے JavaScript میں لکھا گیا ہے۔ زیرو-نالج کا حصہ [Noir](https://noir-lang.org/) میں لکھا گیا ہے۔ ہمیں ورژن `1.0.0-beta.10` کی ضرورت ہے، لہذا [ہدایت کے مطابق Noir انسٹال کرنے](https://noir-lang.org/docs/getting_started/quick_start) کے بعد، چلائیں: + +``` +noirup -v 1.0.0-beta.10 +``` + +جو بلاک چین ہم استعمال کرتے ہیں وہ `anvil` ہے، جو ایک مقامی ٹیسٹنگ بلاک چین ہے جو [Foundry](https://getfoundry.sh/introduction/installation) کا حصہ ہے۔ + +## عمل درآمد {#implementation} + +چونکہ یہ ایک پیچیدہ نظام ہے، ہم اسے مراحل میں نافذ کریں گے۔ + +### مرحلہ 1 - دستی زیرو نالج {#stage-1} + +پہلے مرحلے کے لیے، ہم براؤزر میں ایک ٹرانزیکشن پر دستخط کریں گے اور پھر دستی طور پر زیرو-نالج پروف کو معلومات فراہم کریں گے۔ زیرو-نالج کوڈ کو یہ معلومات `server/noir/Prover.toml` میں ملنے کی توقع ہے (جس کی دستاویزات [یہاں](https://noir-lang.org/docs/getting_started/project_breakdown#provertoml-1) ہیں)۔ + +اسے عمل میں دیکھنے کے لیے: + +1. یقینی بنائیں کہ آپ کے پاس [Node](https://nodejs.org/en/download) اور [Noir](https://noir-lang.org/install) انسٹال ہیں۔ ترجیحاً، انہیں UNIX سسٹم جیسے macOS، Linux، یا [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) پر انسٹال کریں۔ + +2. مرحلہ 1 کا کوڈ ڈاؤن لوڈ کریں اور کلائنٹ کوڈ کی خدمت کے لیے ویب سرور شروع کریں۔ + + ```sh + git clone https://github.com/qbzzt/250911-zk-bank.git -b 01-manual-zk + cd 250911-zk-bank + cd client + npm install + npm run dev + ``` + + آپ کو یہاں ویب سرور کی ضرورت اس لیے ہے کہ، کچھ قسم کے فراڈ کو روکنے کے لیے، بہت سے والیٹس (جیسے MetaMask) براہ راست ڈسک سے پیش کی گئی فائلوں کو قبول نہیں کرتے ہیں۔ + +3. ایک والیٹ کے ساتھ ایک براؤزر کھولیں۔ + +4. والیٹ میں، ایک نیا پاس فریز درج کریں۔ نوٹ کریں کہ یہ آپ کے موجودہ پاس فریز کو حذف کر دے گا، اس لیے _یقینی بنائیں کہ آپ کے پاس بیک اپ ہے_۔ + + پاس فریز `test test test test test test test test test test test junk` ہے، جو anvil کے لیے ڈیفالٹ ٹیسٹنگ پاس فریز ہے۔ + +5. [کلائنٹ سائڈ کوڈ](http://localhost:5173/) پر براؤز کریں۔ + +6. والیٹ سے جڑیں اور اپنا منزل کا اکاؤنٹ اور رقم منتخب کریں۔ + +7. **دستخط کریں** پر کلک کریں اور ٹرانزیکشن پر دستخط کریں۔ + +8. **Prover.toml** ہیڈنگ کے تحت، آپ کو متن ملے گا۔ `server/noir/Prover.toml` کو اس متن سے تبدیل کریں۔ + +9. زیرو-نالج پروف کو انجام دیں۔ + + ```sh + cd ../server/noir + nargo execute + ``` + + آؤٹ پٹ اس سے ملتا جلتا ہونا چاہیے + + ``` + ori@CryptoDocGuy:~/noir/250911-zk-bank/server/noir$ nargo execute + + [zkBank] Circuit witness successfully solved + [zkBank] Witness saved to target/zkBank.gz + [zkBank] Circuit output: (0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b, 0x0cfc0a67cb7308e4e9b254026b54204e34f6c8b041be207e64c5db77d95dd82d, 0x450cf9da6e180d6159290554ae3d8787, 0x6d8bc5a15b9037e52fb59b6b98722a85) + ``` + +10. آخری دو اقدار کا موازنہ اس ہیش سے کریں جو آپ ویب براؤزر پر دیکھتے ہیں یہ دیکھنے کے لیے کہ آیا پیغام درست طریقے سے ہیش کیا گیا ہے۔ + +#### `server/noir/Prover.toml` {#server-noir-prover-toml} + +[یہ فائل](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) Noir کی طرف سے متوقع معلومات کی شکل دکھاتی ہے۔ + +```toml +message="send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 500 finney (milliEth) 0 " +``` + +پیغام ٹیکسٹ فارمیٹ میں ہے، جو صارف کے لیے سمجھنا آسان بناتا ہے (جو دستخط کرتے وقت ضروری ہے) اور Noir کوڈ کے لیے پارس کرنا۔ رقم فننی میں بتائی گئی ہے تاکہ ایک طرف فریکشنل ٹرانسفرز کو فعال کیا جا سکے، اور دوسری طرف آسانی سے پڑھنے کے قابل ہو۔ آخری نمبر [نونس](https://en.wikipedia.org/wiki/Cryptographic_nonce) ہے۔ + +سٹرنگ 100 حروف طویل ہے۔ زیرو-نالج پروف متغیر سائز کے ڈیٹا کو اچھی طرح سے نہیں سنبھالتے ہیں، اس لیے اکثر ڈیٹا کو پیڈ کرنا ضروری ہوتا ہے۔ + +```toml +pubKeyX=["0x83",...,"0x75"] +pubKeyY=["0x35",...,"0xa5"] +signature=["0xb1",...,"0x0d"] +``` + +یہ تینوں پیرامیٹرز فکسڈ سائز بائٹ ارے ہیں۔ + +```toml +[[accounts]] +address="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" +balance=100_000 +nonce=0 + +[[accounts]] +address="0x70997970C51812dc3A010C7d01b50e0d17dc79C8" +balance=100_000 +nonce=0 +``` + +یہ ڈھانچوں کی ایک صف کی وضاحت کرنے کا طریقہ ہے۔ ہر اندراج کے لیے، ہم پتہ، بیلنس (ملی ETH عرف میں) بتاتے ہیں۔ [فننی](https://cryptovalleyjournal.com/glossary/finney/))، اور اگلی نونس ویلیو۔ + +#### `client/src/Transfer.tsx` {#client-src-transfer-tsx} + +[یہ فائل](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/client/src/Transfer.tsx) کلائنٹ سائڈ پروسیسنگ کو نافذ کرتی ہے اور `server/noir/Prover.toml` فائل بناتی ہے (جس میں زیرو-نالج پیرامیٹرز شامل ہیں)۔ + +یہاں زیادہ دلچسپ حصوں کی وضاحت ہے۔ + +```tsx +export default attrs => { +``` + +یہ فنکشن `Transfer` React جزو بناتا ہے، جسے دوسری فائلیں امپورٹ کر سکتی ہیں۔ + +```tsx + const accounts = [ + "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + "0x70997970C51812dc3A010C7d01b50e0d17dc79C8", + "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC", + "0x90F79bf6EB2c4f870365E785982E1f101E93b906", + "0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65", + ] +``` + +یہ اکاؤنٹ کے پتے ہیں، وہ پتے جو `test ...` سے بنائے گئے ہیں۔ ٹیسٹ جنک` پاس فریز۔ اگر آپ اپنے پتے استعمال کرنا چاہتے ہیں، تو صرف اس تعریف میں ترمیم کریں۔ + +```tsx + const account = useAccount() + const wallet = createWalletClient({ + transport: custom(window.ethereum!) + }) +``` + +یہ [Wagmi ہکس](https://wagmi.sh/react/api/hooks) ہمیں [viem](https://viem.sh/) لائبریری اور والیٹ تک رسائی کی اجازت دیتے ہیں۔ + +```tsx + const message = `send ${toAccount} ${ethAmount*1000} finney (milliEth) ${nonce}`.padEnd(100, " ") +``` + +یہ پیغام ہے، جسے اسپیس سے پیڈ کیا گیا ہے۔ جب بھی [`useState`](https://react.dev/reference/react/useState) متغیرات میں سے کوئی ایک تبدیل ہوتا ہے، تو جزو دوبارہ تیار ہوتا ہے اور `message` اپ ڈیٹ ہو جاتا ہے۔ + +```tsx + const sign = async () => { +``` + +یہ فنکشن اس وقت کال ہوتا ہے جب صارف **دستخط کریں** بٹن پر کلک کرتا ہے۔ پیغام خود بخود اپ ڈیٹ ہو جاتا ہے، لیکن دستخط کے لیے والیٹ میں صارف کی منظوری کی ضرورت ہوتی ہے، اور ہم اسے اس وقت تک نہیں مانگنا چاہتے جب تک ضرورت نہ ہو۔ + +```tsx + const signature = await wallet.signMessage({ + account: fromAccount, + message, + }) +``` + +والیٹ سے [پیغام پر دستخط کرنے](https://viem.sh/docs/accounts/local/signMessage) کے لیے کہیں۔ + +```tsx + const hash = hashMessage(message) +``` + +پیغام کا ہیش حاصل کریں۔ صارف کو ڈیبگنگ (Noir کوڈ کی) کے لیے فراہم کرنا مددگار ہے۔ + +```tsx + const pubKey = await recoverPublicKey({ + hash, + signature + }) +``` + +[پبلک کی حاصل کریں](https://viem.sh/docs/utilities/recoverPublicKey)۔ یہ [Noir `ecrecover`](https://github.com/colinnielsen/ecrecover-noir) فنکشن کے لیے ضروری ہے۔ + +```tsx + setSignature(signature) + setHash(hash) + setPubKey(pubKey) +``` + +اسٹیٹ متغیرات سیٹ کریں۔ ایسا کرنے سے جزو دوبارہ تیار ہوتا ہے (جب `sign` فنکشن ختم ہوتا ہے) اور صارف کو اپ ڈیٹ شدہ اقدار دکھاتا ہے۔ + +```tsx + let proverToml = ` +``` + +`Prover.toml` کے لیے متن۔ + +```tsx +message="${message}" + +pubKeyX=${hexToArray(pubKey.slice(4,4+2*32))} +pubKeyY=${hexToArray(pubKey.slice(4+2*32))} +``` + +Viem ہمیں پبلک کی کو 65 بائٹ کی ہیکساڈیسیمل سٹرنگ کے طور پر فراہم کرتا ہے۔ پہلا بائٹ `0x04` ہے، جو ایک ورژن مارکر ہے۔ اس کے بعد پبلک کی کے `x` کے لیے 32 بائٹس اور پھر پبلک کی کے `y` کے لیے 32 بائٹس آتے ہیں۔ + +تاہم، Noir کو یہ معلومات دو بائٹ ارے کے طور پر حاصل کرنے کی توقع ہے، ایک `x` کے لیے اور ایک `y` کے لیے۔ اسے یہاں کلائنٹ پر پارس کرنا زیرو-نالج پروف کے حصے کے طور پر پارس کرنے سے زیادہ آسان ہے۔ + +نوٹ کریں کہ یہ عام طور پر زیرو-نالج میں ایک اچھی پریکٹس ہے۔ زیرو-نالج پروف کے اندر کا کوڈ مہنگا ہوتا ہے، اس لیے کوئی بھی پروسیسنگ جو زیرو-نالج پروف سے باہر کی جا سکتی ہے _چاہیے_ کہ وہ زیرو-نالج پروف سے باہر کی جائے۔ + +```tsx +signature=${hexToArray(signature.slice(2,-2))} +``` + +دستخط بھی 65 بائٹ کی ہیکساڈیسیمل سٹرنگ کے طور پر فراہم کیا جاتا ہے۔ تاہم، آخری بائٹ صرف پبلک کی کو بازیافت کرنے کے لیے ضروری ہے۔ چونکہ پبلک کی پہلے ہی Noir کوڈ کو فراہم کر دی جائے گی، ہمیں دستخط کی تصدیق کے لیے اس کی ضرورت نہیں ہے، اور Noir کوڈ کو اس کی ضرورت نہیں ہے۔ + +```tsx +${accounts.map(accountInProverToml).reduce((a,b) => a+b, "")} +` +``` + +اکاؤنٹس فراہم کریں۔ + +```tsx + setProverToml(proverToml) + } + + return ( + <> +

Transfer

+``` + +یہ جزو کا HTML (زیادہ درست طور پر، [JSX](https://react.dev/learn/writing-markup-with-jsx)) فارمیٹ ہے۔ + +#### `server/noir/src/main.nr` {#server-noir-src-main-nr} + +[یہ فائل](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/src/main.nr) اصل زیرو-نالج کوڈ ہے۔ + +``` +use std::hash::pedersen_hash; +``` + +[پیڈرسن ہیش](https://rya-sge.github.io/access-denied/2024/05/07/pedersen-hash-function/) [Noir اسٹینڈرڈ لائبریری](https://noir-lang.org/docs/noir/standard_library/cryptographic_primitives/hashes#pedersen_hash) کے ساتھ فراہم کیا گیا ہے۔ زیرو-نالج پروف عام طور پر اس ہیش فنکشن کا استعمال کرتے ہیں۔ اسٹینڈرڈ ہیش فنکشنز کے مقابلے میں [ارتھمیٹک سرکٹس](https://rareskills.io/post/arithmetic-circuit) کے اندر اس کا حساب لگانا بہت آسان ہے۔ + +``` +use keccak256::keccak256; +use dep::ecrecover; +``` + +یہ دو فنکشنز بیرونی لائبریریاں ہیں، جو [`Nargo.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Nargo.toml) میں بیان کی گئی ہیں۔ یہ بالکل وہی ہیں جن کے لیے ان کا نام رکھا گیا ہے، ایک فنکشن جو [keccak256 ہیش](https://emn178.github.io/online-tools/keccak_256.html) کا حساب لگاتا ہے اور ایک فنکشن جو Ethereum دستخطوں کی تصدیق کرتا ہے اور دستخط کنندہ کا Ethereum پتہ بازیافت کرتا ہے۔ + +``` +global ACCOUNT_NUMBER : u32 = 5; +``` + +Noir [Rust](https://www.rust-lang.org/) سے متاثر ہے۔ متغیرات، بطور ڈیفالٹ، مستقل ہوتے ہیں۔ اس طرح ہم عالمی کنفیگریشن مستقلات کی تعریف کرتے ہیں۔ خاص طور پر، `ACCOUNT_NUMBER` ان اکاؤنٹس کی تعداد ہے جنہیں ہم اسٹور کرتے ہیں۔ + +`u` نامی ڈیٹا کی اقسام اس تعداد کے بٹس ہیں، جو غیر دستخط شدہ ہیں۔ صرف معاون اقسام `u8`، `u16`، `u32`، `u64`، اور `u128` ہیں۔ + +``` +global FLAT_ACCOUNT_FIELDS : u32 = 2; +``` + +یہ متغیر اکاؤنٹس کے پیڈرسن ہیش کے لیے استعمال ہوتا ہے، جیسا کہ ذیل میں بیان کیا گیا ہے۔ + +``` +global MESSAGE_LENGTH : u32 = 100; +``` + +جیسا کہ اوپر بیان کیا گیا ہے، پیغام کی لمبائی مقرر ہے۔ یہاں اس کی وضاحت کی گئی ہے۔ + +``` +global ASCII_MESSAGE_LENGTH : [u8; 3] = [0x31, 0x30, 0x30]; +global HASH_BUFFER_SIZE : u32 = 26+3+MESSAGE_LENGTH; +``` + +[EIP-191 دستخط](https://eips.ethereum.org/EIPS/eip-191) کے لیے 26-بائٹ کے سابقے والا ایک بفر درکار ہوتا ہے، اس کے بعد ASCII میں پیغام کی لمبائی، اور آخر میں خود پیغام۔ + +``` +struct Account { + balance: u128, + address: Field, + nonce: u32, +} +``` + +وہ معلومات جو ہم ایک اکاؤنٹ کے بارے میں اسٹور کرتے ہیں۔ [`Field`](https://noir-lang.org/docs/noir/concepts/data_types/fields) ایک نمبر ہے، عام طور پر 253 بٹس تک، جسے براہ راست [ارتھمیٹک سرکٹ](https://rareskills.io/post/arithmetic-circuit) میں استعمال کیا جا سکتا ہے جو زیرو-نالج پروف کو نافذ کرتا ہے۔ یہاں ہم 160 بٹ Ethereum ایڈریس کو اسٹور کرنے کے لیے `Field` کا استعمال کرتے ہیں۔ + +``` +struct TransferTxn { + from: Field, + to: Field, + amount: u128, + nonce: u32 +} +``` + +وہ معلومات جو ہم ٹرانسفر ٹرانزیکشن کے لیے اسٹور کرتے ہیں۔ + +``` +fn flatten_account(account: Account) -> [Field; FLAT_ACCOUNT_FIELDS] { +``` + +ایک فنکشن کی تعریف۔ پیرامیٹر `Account` کی معلومات ہے۔ نتیجہ `Field` متغیرات کی ایک صف ہے، جس کی لمبائی `FLAT_ACCOUNT_FIELDS` ہے + +``` + let flat = [ + account.address, + ((account.balance << 32) + account.nonce.into()).into(), + ]; +``` + +صف میں پہلی قدر اکاؤنٹ کا پتہ ہے۔ دوسرے میں بیلنس اور نونس دونوں شامل ہیں۔ `.into()` کالز ایک نمبر کو اس ڈیٹا کی قسم میں تبدیل کرتی ہیں جس کی اسے ضرورت ہوتی ہے۔ `account.nonce` ایک `u32` قدر ہے، لیکن اسے `account.balance « 32` میں شامل کرنے کے لیے، جو ایک `u128` قدر ہے، اسے `u128` ہونا چاہیے۔ یہ پہلا `.into()` ہے۔ دوسرا `u128` نتیجے کو ایک `Field` میں تبدیل کرتا ہے تاکہ یہ صف میں فٹ ہو سکے۔ + +``` + flat +} +``` + +Noir میں، فنکشنز صرف آخر میں ایک قدر واپس کر سکتے ہیں (کوئی ابتدائی واپسی نہیں ہے)۔ واپسی کی قدر کی وضاحت کرنے کے لیے، آپ اسے فنکشن کے اختتامی بریکٹ سے ٹھیک پہلے جانچتے ہیں۔ + +``` +fn flatten_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] { +``` + +یہ فنکشن اکاؤنٹس کی صف کو ایک `Field` صف میں بدل دیتا ہے، جسے پیٹرسن ہیش کے ان پٹ کے طور پر استعمال کیا جا سکتا ہے۔ + +``` + let mut flat: [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] = [0; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER]; +``` + +یہ ایک قابل تغیر متغیر کی وضاحت کرنے کا طریقہ ہے، یعنی _نہ کہ_ ایک مستقل۔ Noir میں متغیرات کی ہمیشہ ایک قدر ہونی چاہیے، اس لیے ہم اس متغیر کو تمام صفر پر شروع کرتے ہیں۔ + +``` + for i in 0..ACCOUNT_NUMBER { +``` + +یہ ایک `for` لوپ ہے۔ نوٹ کریں کہ حدود مستقل ہیں۔ Noir لوپس کی حدود کمپائل ٹائم پر معلوم ہونی چاہئیں۔ وجہ یہ ہے کہ ارتھمیٹک سرکٹس فلو کنٹرول کو سپورٹ نہیں کرتے ہیں۔ `for` لوپ پر کارروائی کرتے وقت، کمپائلر صرف اس کے اندر کا کوڈ متعدد بار رکھتا ہے، ہر تکرار کے لیے ایک بار۔ + +``` + let fields = flatten_account(accounts[i]); + for j in 0..FLAT_ACCOUNT_FIELDS { + flat[i*FLAT_ACCOUNT_FIELDS + j] = fields[j]; + } + } + + flat +} + +fn hash_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> Field { + pedersen_hash(flatten_accounts(accounts)) +} +``` + +آخر میں، ہم اس فنکشن پر پہنچ گئے جو اکاؤنٹس کی صف کو ہیش کرتا ہے۔ + +``` +fn find_account(accounts: [Account; ACCOUNT_NUMBER], address: Field) -> u32 { + let mut account : u32 = ACCOUNT_NUMBER; + + for i in 0..ACCOUNT_NUMBER { + if accounts[i].address == address { + account = i; + } + } +``` + +یہ فنکشن ایک مخصوص پتے والا اکاؤنٹ ڈھونڈتا ہے۔ یہ فنکشن معیاری کوڈ میں بہت غیر موثر ہوگا کیونکہ یہ تمام اکاؤنٹس پر تکرار کرتا ہے، یہاں تک کہ جب اسے پتہ مل جاتا ہے۔ + +تاہم، زیرو-نالج پروف میں، کوئی فلو کنٹرول نہیں ہے۔ اگر ہمیں کبھی بھی کسی شرط کو جانچنے کی ضرورت ہوتی ہے، تو ہمیں اسے ہر بار جانچنا پڑتا ہے۔ + +اسی طرح کی چیز `if` بیانات کے ساتھ ہوتی ہے۔ اوپر کے لوپ میں `if` بیان کو ان ریاضیاتی بیانات میں ترجمہ کیا گیا ہے۔ + +_conditionresult = accounts[i].address == address_ // ایک اگر وہ برابر ہیں، ورنہ صفر + +_accountnew = conditionresult\*i + (1-conditionresult)\*accountold_ + +```rust + assert (account < ACCOUNT_NUMBER, f"{address} does not have an account"); + + account +} +``` + +[`assert`](https://noir-lang.org/docs/dev/noir/concepts/assert) فنکشن زیرو-نالج پروف کو کریش کر دیتا ہے اگر دعویٰ غلط ہو۔ اس صورت میں، اگر ہم متعلقہ پتے والا کوئی اکاؤنٹ نہیں ڈھونڈ سکتے ہیں۔ پتے کی اطلاع دینے کے لیے، ہم ایک [فارمیٹ سٹرنگ](https://noir-lang.org/docs/noir/concepts/data_types/strings#format-strings) استعمال کرتے ہیں۔ + +```rust +fn apply_transfer_txn(accounts: [Account; ACCOUNT_NUMBER], txn: TransferTxn) -> [Account; ACCOUNT_NUMBER] { +``` + +یہ فنکشن ایک ٹرانسفر ٹرانزیکشن لاگو کرتا ہے اور نئی اکاؤنٹس کی صف واپس کرتا ہے۔ + +```rust + let from = find_account(accounts, txn.from); + let to = find_account(accounts, txn.to); + + let (txnFrom, txnAmount, txnNonce, accountNonce) = + (txn.from, txn.amount, txn.nonce, accounts[from].nonce); +``` + +ہم Noir میں فارمیٹ سٹرنگ کے اندر ڈھانچے کے عناصر تک رسائی حاصل نہیں کر سکتے، اس لیے ہم ایک قابل استعمال کاپی بناتے ہیں۔ + +```rust + assert (accounts[from].balance >= txn.amount, + f"{txnFrom} does not have {txnAmount} finney"); + + assert (accounts[from].nonce == txn.nonce, + f"Transaction has nonce {txnNonce}, but the account is expected to use {accountNonce}"); +``` + +یہ دو شرائط ہیں جو کسی ٹرانزیکشن کو غلط قرار دے سکتی ہیں۔ + +```rust + let mut newAccounts = accounts; + + newAccounts[from].balance -= txn.amount; + newAccounts[from].nonce += 1; + newAccounts[to].balance += txn.amount; + + newAccounts +} +``` + +نئی اکاؤنٹس کی صف بنائیں اور پھر اسے واپس کریں۔ + +```rust +fn readAddress(messageBytes: [u8; MESSAGE_LENGTH]) -> Field +``` + +یہ فنکشن پیغام سے پتہ پڑھتا ہے۔ + +```rust +{ + let mut result : Field = 0; + + for i in 7..47 { +``` + +پتہ ہمیشہ 20 بائٹس (عرف 40 ہیکساڈیسیمل ہندسوں) لمبا ہوتا ہے، اور کریکٹر #7 سے شروع ہوتا ہے۔ 40 ہیکساڈیسیمل ہندسے) لمبا، اور کریکٹر #7 سے شروع ہوتا ہے۔ + +```rust + result *= 0x10; + if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9 + result += (messageBytes[i]-48).into(); + } + if messageBytes[i] >= 65 & messageBytes[i] <= 70 { // A-F + result += (messageBytes[i]-65+10).into() + } + if messageBytes[i] >= 97 & messageBytes[i] <= 102 { // a-f + result += (messageBytes[i]-97+10).into() + } + } + + result +} + +fn readAmountAndNonce(messageBytes: [u8; MESSAGE_LENGTH]) -> (u128, u32) +``` + +پیغام سے رقم اور نونس پڑھیں۔ + +```rust +{ + let mut amount : u128 = 0; + let mut nonce: u32 = 0; + let mut stillReadingAmount: bool = true; + let mut lookingForNonce: bool = false; + let mut stillReadingNonce: bool = false; +``` + +پیغام میں، پتے کے بعد پہلا نمبر فننی (عرف ہزارواں ETH) کی رقم ہے جسے ٹرانسفر کرنا ہے۔ ETH کا ہزارواں حصہ) ٹرانسفر کرنا ہے۔ دوسرا نمبر نونس ہے۔ ان کے درمیان کوئی بھی متن نظر انداز کر دیا جاتا ہے۔ + +```rust + for i in 48..MESSAGE_LENGTH { + if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9 + let digit = (messageBytes[i]-48); + + if stillReadingAmount { + amount = amount*10 + digit.into(); + } + + if lookingForNonce { // We just found it + stillReadingNonce = true; + lookingForNonce = false; + } + + if stillReadingNonce { + nonce = nonce*10 + digit.into(); + } + } else { + if stillReadingAmount { + stillReadingAmount = false; + lookingForNonce = true; + } + if stillReadingNonce { + stillReadingNonce = false; + } + } + } + + (amount, nonce) +} +``` + +[ٹیوپل](https://noir-lang.org/docs/noir/concepts/data_types/tuples) واپس کرنا Noir میں ایک فنکشن سے متعدد قدریں واپس کرنے کا طریقہ ہے۔ + +```rust +fn readTransferTxn(message: str) -> TransferTxn +{ + let mut txn: TransferTxn = TransferTxn { from: 0, to: 0, amount:0, nonce:0 }; + let messageBytes = message.as_bytes(); + + txn.to = readAddress(messageBytes); + let (amount, nonce) = readAmountAndNonce(messageBytes); + txn.amount = amount; + txn.nonce = nonce; + + txn +} +``` + +یہ فنکشن پیغام کو بائٹس میں تبدیل کرتا ہے، پھر رقم کو ایک `TransferTxn` میں تبدیل کرتا ہے۔ + +```rust +// Viem کے hashMessage کے برابر +// https://viem.sh/docs/utilities/hashMessage#hashmessage +fn hashMessage(message: str) -> [u8;32] { +``` + +ہم اکاؤنٹس کے لیے پیڈرسن ہیش کا استعمال کرنے کے قابل تھے کیونکہ وہ صرف زیرو-نالج پروف کے اندر ہیش کیے جاتے ہیں۔ تاہم، اس کوڈ میں ہمیں پیغام کے دستخط کی جانچ کرنے کی ضرورت ہے، جو براؤزر کے ذریعے تیار کیا جاتا ہے۔ اس کے لیے، ہمیں [EIP 191](https://eips.ethereum.org/EIPS/eip-191) میں Ethereum دستخطی فارمیٹ کی پیروی کرنے کی ضرورت ہے۔ اس کا مطلب ہے کہ ہمیں ایک معیاری سابقے کے ساتھ ایک مشترکہ بفر بنانے کی ضرورت ہے، ASCII میں پیغام کی لمبائی، اور خود پیغام، اور اسے ہیش کرنے کے لیے Ethereum کے معیاری keccak256 کا استعمال کرنا ہوگا۔ + +```rust + // ASCII prefix + let prefix_bytes = [ + 0x19, // \x19 + 0x45, // 'E' + 0x74, // 't' + 0x68, // 'h' + 0x65, // 'e' + 0x72, // 'r' + 0x65, // 'e' + 0x75, // 'u' + 0x6D, // 'm' + 0x20, // ' ' + 0x53, // 'S' + 0x69, // 'i' + 0x67, // 'g' + 0x6E, // 'n' + 0x65, // 'e' + 0x64, // 'd' + 0x20, // ' ' + 0x4D, // 'M' + 0x65, // 'e' + 0x73, // 's' + 0x73, // 's' + 0x61, // 'a' + 0x67, // 'g' + 0x65, // 'e' + 0x3A, // ':' + 0x0A // '\n' + ]; +``` + +ان صورتوں سے بچنے کے لیے جہاں کوئی ایپلیکیشن صارف سے کسی ایسے پیغام پر دستخط کرنے کو کہتی ہے جسے ٹرانزیکشن کے طور پر یا کسی اور مقصد کے لیے استعمال کیا جا سکتا ہے، EIP 191 یہ بتاتا ہے کہ تمام دستخط شدہ پیغامات کریکٹر 0x19 (ایک درست ASCII کریکٹر نہیں) سے شروع ہوتے ہیں جس کے بعد `Ethereum Signed Message:` اور ایک نئی لائن آتی ہے۔ + +```rust + let mut buffer: [u8; HASH_BUFFER_SIZE] = [0u8; HASH_BUFFER_SIZE]; + for i in 0..26 { + buffer[i] = prefix_bytes[i]; + } + + let messageBytes : [u8; MESSAGE_LENGTH] = message.as_bytes(); + + if MESSAGE_LENGTH <= 9 { + for i in 0..1 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+1] = messageBytes[i]; + } + } + + if MESSAGE_LENGTH >= 10 & MESSAGE_LENGTH <= 99 { + for i in 0..2 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+2] = messageBytes[i]; + } + } + + if MESSAGE_LENGTH >= 100 { + for i in 0..3 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+3] = messageBytes[i]; + } + } + + assert(MESSAGE_LENGTH < 1000, "Messages whose length is over three digits are not supported"); +``` + +999 تک کی پیغام کی لمبائی کو سنبھالیں اور اگر یہ اس سے زیادہ ہو تو ناکام ہو جائیں۔ میں نے یہ کوڈ شامل کیا، حالانکہ پیغام کی لمبائی ایک مستقل ہے، کیونکہ اس سے اسے تبدیل کرنا آسان ہو جاتا ہے۔ پروڈکشن سسٹم پر، آپ شاید صرف یہ فرض کریں گے کہ `MESSAGE_LENGTH` بہتر کارکردگی کی خاطر تبدیل نہیں ہوتا ہے۔ + +```rust + keccak256::keccak256(buffer, HASH_BUFFER_SIZE) +} +``` + +Ethereum کے معیاری `keccak256` فنکشن کا استعمال کریں۔ + +```rust +fn signatureToAddressAndHash( + message: str, + pubKeyX: [u8; 32], + pubKeyY: [u8; 32], + signature: [u8; 64] + ) -> (Field, Field, Field) // address, first 16 bytes of hash, last 16 bytes of hash +{ +``` + +یہ فنکشن دستخط کی تصدیق کرتا ہے، جس کے لیے پیغام کا ہیش درکار ہوتا ہے۔ پھر یہ ہمیں وہ پتہ فراہم کرتا ہے جس نے اس پر دستخط کیا اور پیغام کا ہیش۔ پیغام کا ہیش دو `Field` اقدار میں فراہم کیا جاتا ہے کیونکہ پروگرام کے باقی حصوں میں بائٹ ارے کے مقابلے میں ان کا استعمال آسان ہے۔ + +ہمیں دو `Field` اقدار کا استعمال کرنے کی ضرورت ہے کیونکہ فیلڈ کے حسابات ایک بڑی تعداد کے [ماڈیولو](https://en.wikipedia.org/wiki/Modulo) کیے جاتے ہیں، لیکن وہ تعداد عام طور پر 256 بٹس سے کم ہوتی ہے (ورنہ EVM میں ان حسابات کو انجام دینا مشکل ہوگا)۔ + +```rust + let hash = hashMessage(message); + + let mut (hash1, hash2) = (0,0); + + for i in 0..16 { + hash1 = hash1*256 + hash[31-i].into(); + hash2 = hash2*256 + hash[15-i].into(); + } +``` + +`hash1` اور `hash2` کو قابل تغیر متغیرات کے طور پر بیان کریں، اور ہیش کو بائٹ بائٹ کر کے ان میں لکھیں۔ + +```rust + ( + ecrecover::ecrecover(pubKeyX, pubKeyY, signature, hash), +``` + +یہ [سولیڈٹی کے `ecrecover`](https://docs.soliditylang.org/en/v0.8.30/cheatsheet.html#mathematical-and-cryptographic-functions) سے ملتا جلتا ہے، دو اہم فرقوں کے ساتھ: + +- اگر دستخط درست نہیں ہے، تو کال ایک `assert` ناکام ہو جاتی ہے اور پروگرام ختم ہو جاتا ہے۔ +- جبکہ پبلک کی کو دستخط اور ہیش سے بازیافت کیا جا سکتا ہے، یہ ایک ایسی پروسیسنگ ہے جو بیرونی طور پر کی جا سکتی ہے اور، اس لیے، زیرو-نالج پروف کے اندر کرنے کے قابل نہیں ہے۔ اگر کوئی یہاں ہمیں دھوکہ دینے کی کوشش کرتا ہے، تو دستخط کی تصدیق ناکام ہو جائے گی۔ + +```rust + hash1, + hash2 + ) +} + +fn main( + accounts: [Account; ACCOUNT_NUMBER], + message: str, + pubKeyX: [u8; 32], + pubKeyY: [u8; 32], + signature: [u8; 64], + ) -> pub ( + Field, // Hash of old accounts array + Field, // Hash of new accounts array + Field, // First 16 bytes of message hash + Field, // Last 16 bytes of message hash + ) +``` + +آخر میں، ہم `main` فنکشن تک پہنچتے ہیں۔ ہمیں یہ ثابت کرنے کی ضرورت ہے کہ ہمارے پاس ایک ٹرانزیکشن ہے جو اکاؤنٹس کے ہیش کو پرانی قدر سے نئی میں درست طریقے سے تبدیل کرتا ہے۔ ہمیں یہ بھی ثابت کرنے کی ضرورت ہے کہ اس کا یہ مخصوص ٹرانزیکشن ہیش ہے تاکہ جس شخص نے اسے بھیجا ہے اسے معلوم ہو کہ اس کے ٹرانزیکشن پر کارروائی ہو چکی ہے۔ + +```rust +{ + let mut txn = readTransferTxn(message); +``` + +ہمیں `txn` کو قابل تغیر ہونے کی ضرورت ہے کیونکہ ہم پیغام سے سے پتہ نہیں پڑھتے ہیں، ہم اسے دستخط سے پڑھتے ہیں۔ + +```rust + let (fromAddress, txnHash1, txnHash2) = signatureToAddressAndHash( + message, + pubKeyX, + pubKeyY, + signature); + + txn.from = fromAddress; + + let newAccounts = apply_transfer_txn(accounts, txn); + + ( + hash_accounts(accounts), + hash_accounts(newAccounts), + txnHash1, + txnHash2 + ) +} +``` + +### مرحلہ 2 - ایک سرور شامل کرنا {#stage-2} + +دوسرے مرحلے میں، ہم ایک سرور شامل کرتے ہیں جو براؤزر سے ٹرانسفر ٹرانزیکشنز وصول کرتا ہے اور ان کو نافذ کرتا ہے۔ + +اسے عمل میں دیکھنے کے لیے: + +1. اگر Vite چل رہا ہے تو اسے روک دیں۔ + +2. وہ برانچ ڈاؤن لوڈ کریں جس میں سرور شامل ہے اور یقینی بنائیں کہ آپ کے پاس تمام ضروری ماڈیولز ہیں۔ + + ```sh + git checkout 02-add-server + cd client + npm install + cd ../server + npm install + ``` + + Noir کوڈ کو کمپائل کرنے کی ضرورت نہیں ہے، یہ وہی کوڈ ہے جو آپ نے مرحلہ 1 کے لیے استعمال کیا تھا۔ + +3. سرور شروع کریں۔ + + ```sh + npm run start + ``` + +4. ایک الگ کمانڈ لائن ونڈو میں، براؤزر کوڈ کی خدمت کے لیے Vite چلائیں۔ + + ```sh + cd client + npm run dev + ``` + +5. کلائنٹ کوڈ پر براؤز کریں [http://localhost:5173](http://localhost:5173) پر + +6. کسی ٹرانزیکشن کو جاری کرنے سے پہلے، آپ کو نونس کے ساتھ ساتھ وہ رقم بھی جاننے کی ضرورت ہے جو آپ بھیج سکتے ہیں۔ یہ معلومات حاصل کرنے کے لیے، **اکاؤنٹ ڈیٹا اپ ڈیٹ کریں** پر کلک کریں اور پیغام پر دستخط کریں۔ + + ہمارے پاس یہاں ایک مخمصہ ہے۔ ایک طرف، ہم کسی ایسے پیغام پر دستخط نہیں کرنا چاہتے جسے دوبارہ استعمال کیا جا سکے ([ری پلے حملہ](https://en.wikipedia.org/wiki/Replay_attack))، یہی وجہ ہے کہ ہم سب سے پہلے ایک نونس چاہتے ہیں۔ تاہم، ہمارے پاس ابھی تک کوئی نونس نہیں ہے۔ حل یہ ہے کہ ایک ایسا نونس منتخب کیا جائے جسے صرف ایک بار استعمال کیا جا سکے اور جو ہمارے پاس دونوں طرف پہلے سے موجود ہو، جیسے کہ موجودہ وقت۔ + + اس حل کے ساتھ مسئلہ یہ ہے کہ وقت بالکل ہم آہنگ نہیں ہو سکتا ہے۔ اس کے بجائے، ہم ایک ایسی قدر پر دستخط کرتے ہیں جو ہر منٹ بدلتی ہے۔ اس کا مطلب ہے کہ ری پلے حملوں کے لیے ہماری کمزوری کی کھڑکی زیادہ سے زیادہ ایک منٹ ہے۔ یہ دیکھتے ہوئے کہ پروڈکشن میں دستخط شدہ درخواست TLS کے ذریعے محفوظ کی جائے گی، اور یہ کہ سرنگ کا دوسرا رخ — سرور — پہلے ہی بیلنس اور نونس کا انکشاف کر سکتا ہے (اسے کام کرنے کے لیے انہیں جاننا ہوگا)، یہ ایک قابل قبول خطرہ ہے۔ + +7. ایک بار جب براؤزر بیلنس اور نونس واپس حاصل کر لیتا ہے، تو یہ ٹرانسفر فارم دکھاتا ہے۔ منزل کا پتہ اور رقم منتخب کریں اور **ٹرانسفر کریں** پر کلک کریں۔ اس درخواست پر دستخط کریں۔ + +8. ٹرانسفر دیکھنے کے لیے، یا تو **اکاؤنٹ ڈیٹا اپ ڈیٹ کریں** یا اس ونڈو میں دیکھیں جہاں آپ سرور چلاتے ہیں۔ سرور ہر بار جب یہ تبدیل ہوتا ہے تو اسٹیٹ کو لاگ کرتا ہے۔ + + ``` + ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start + + > server@1.0.0 start + > node --experimental-json-modules index.mjs + + Listening on port 3000 + Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 36000 finney (milliEth) 0 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 64000 (1) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 100000 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + Txn send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 7200 finney (milliEth) 1 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 56800 (2) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 3000 finney (milliEth) 2 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 53800 (3) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 139000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + ``` + +#### `server/index.mjs` {#server-index-mjs-1} + +[یہ فائل](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/index.mjs) سرور کے عمل پر مشتمل ہے، اور [`main.nr`](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/noir/src/main.nr) پر Noir کوڈ کے ساتھ تعامل کرتی ہے۔ یہاں دلچسپ حصوں کی وضاحت ہے۔ + +```js +import { Noir } from '@noir-lang/noir_js' +``` + +[noir.js](https://www.npmjs.com/package/@noir-lang/noir_js) لائبریری JavaScript کوڈ اور Noir کوڈ کے درمیان انٹرفیس کرتی ہے۔ + +```js +const circuit = JSON.parse(await fs.readFile("./noir/target/zkBank.json")) +const noir = new Noir(circuit) +``` + +ارتھمیٹک سرکٹ لوڈ کریں — وہ کمپائل شدہ Noir پروگرام جو ہم نے پچھلے مرحلے میں بنایا تھا — اور اسے چلانے کے لیے تیار کریں۔ + +```js +// We only provide account information in return to a signed request +const accountInformation = async signature => { + const fromAddress = await recoverAddress({ + hash: hashMessage("Get account data " + Math.floor((new Date().getTime())/60000)), + signature + }) +``` + +اکاؤنٹ کی معلومات فراہم کرنے کے لیے، ہمیں صرف دستخط کی ضرورت ہے۔ وجہ یہ ہے کہ ہم پہلے ہی جانتے ہیں کہ پیغام کیا ہوگا، اور اس لیے پیغام کا ہیش۔ + +```js +const processMessage = async (message, signature) => { +``` + +ایک پیغام پر کارروائی کریں اور اس ٹرانزیکشن کو انجام دیں جسے یہ انکوڈ کرتا ہے۔ + +```js + // Get the public key + const pubKey = await recoverPublicKey({ + hash, + signature + }) +``` + +اب جب کہ ہم سرور پر JavaScript چلاتے ہیں، ہم کلائنٹ کے بجائے وہاں سے پبلک کی بازیافت کر سکتے ہیں۔ + +```js + let noirResult + try { + noirResult = await noir.execute({ + message, + signature: signature.slice(2,-2).match(/.{2}/g).map(x => `0x${x}`), + pubKeyX, + pubKeyY, + accounts: Accounts + }) +``` + +`noir.execute` Noir پروگرام چلاتا ہے۔ پیرامیٹرز ان کے برابر ہیں جو [`Prover.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) میں فراہم کیے گئے ہیں۔ نوٹ کریں کہ لمبی قدریں ہیکساڈیسیمل سٹرنگز کی ایک صف کے طور پر فراہم کی جاتی ہیں (`["0x60", "0xA7"]`)، نہ کہ ایک ہی ہیکساڈیسیمل قدر (`0x60A7`) کے طور پر، جس طرح Viem کرتا ہے۔ + +```js + } catch (err) { + console.log(`Noir error: ${err}`) + throw Error("Invalid transaction, not processed") + } +``` + +اگر کوئی خرابی ہو تو اسے پکڑیں اور پھر کلائنٹ کو ایک آسان ورژن ریلے کریں۔ + +```js + Accounts[fromAccountNumber].nonce++ + Accounts[fromAccountNumber].balance -= amount + Accounts[toAccountNumber].balance += amount +``` + +ٹرانزیکشن لاگو کریں۔ ہم نے اسے پہلے ہی Noir کوڈ میں کر دیا ہے، لیکن اسے یہاں دوبارہ کرنا اس سے نتیجہ نکالنے سے زیادہ آسان ہے۔ + +```js +let Accounts = [ + { + address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + balance: 5000, + nonce: 0, + }, +``` + +ابتدائی `Accounts` کی ساخت۔ + +### مرحلہ 3 - Ethereum اسمارٹ کنٹریکٹس {#stage-3} + +1. سرور اور کلائنٹ کے عمل کو روک دیں۔ + +2. اسمارٹ کنٹریکٹس کے ساتھ برانچ ڈاؤن لوڈ کریں اور یقینی بنائیں کہ آپ کے پاس تمام ضروری ماڈیولز ہیں۔ + + ```sh + git checkout 03-smart-contracts + cd client + npm install + cd ../server + npm install + ``` + +3. ایک الگ کمانڈ لائن ونڈو میں `anvil` چلائیں۔ + +4. تصدیقی کلید اور سولیڈٹی تصدیق کنندہ تیار کریں، پھر تصدیق کنندہ کوڈ کو سولیڈٹی پروجیکٹ میں کاپی کریں۔ + + ```sh + cd noir + bb write_vk -b ./target/zkBank.json -o ./target --oracle_hash keccak + bb write_solidity_verifier -k ./target/vk -o ./target/Verifier.sol + cp target/Verifier.sol ../../smart-contracts/src + ``` + +5. اسمارٹ کنٹریکٹس پر جائیں اور `anvil` بلاک چین استعمال کرنے کے لیے ماحولیاتی متغیرات سیٹ کریں۔ + + ```sh + cd ../../smart-contracts + export ETH_RPC_URL=http://localhost:8545 + ETH_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 + ``` + +6. `Verifier.sol` کو تعینات کریں اور پتے کو ایک ماحولیاتی متغیر میں ذخیرہ کریں۔ + + ```sh + VERIFIER_ADDRESS=`forge create src/Verifier.sol:HonkVerifier --private-key $ETH_PRIVATE_KEY --optimize --broadcast | awk '/Deployed to:/ {print $3}'` + echo $VERIFIER_ADDRESS + ``` + +7. `ZkBank` کنٹریکٹ کو تعینات کریں۔ + + ```sh + ZKBANK_ADDRESS=`forge create ZkBank --private-key $ETH_PRIVATE_KEY --broadcast --constructor-args $VERIFIER_ADDRESS 0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b | awk '/Deployed to:/ {print $3}'` + echo $ZKBANK_ADDRESS + ``` + + `0x199..67b` قدر `Accounts` کی ابتدائی اسٹیٹ کا پیڈرسن ہیش ہے۔ اگر آپ `server/index.mjs` میں اس ابتدائی اسٹیٹ میں ترمیم کرتے ہیں، تو آپ زیرو-نالج پروف کے ذریعے رپورٹ کردہ ابتدائی ہیش کو دیکھنے کے لیے ایک ٹرانزیکشن چلا سکتے ہیں۔ + +8. سرور چلائیں۔ + + ```sh + cd ../server + npm run start + ``` + +9. کلائنٹ کو ایک مختلف کمانڈ لائن ونڈو میں چلائیں۔ + + ```sh + cd client + npm run dev + ``` + +10. کچھ ٹرانزیکشنز چلائیں۔ + +11. یہ تصدیق کرنے کے لیے کہ اسٹیٹ آن چین تبدیل ہو گئی ہے، سرور کے عمل کو دوبارہ شروع کریں۔ دیکھیں کہ `ZkBank` اب ٹرانزیکشنز قبول نہیں کرتا ہے، کیونکہ ٹرانزیکشنز میں اصل ہیش ویلیو آن چین ذخیرہ شدہ ہیش ویلیو سے مختلف ہے۔ + + یہ متوقع غلطی کی قسم ہے۔ + + ``` + ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start + + > server@1.0.0 start + > node --experimental-json-modules index.mjs + + Listening on port 3000 + Verification error: ContractFunctionExecutionError: The contract function "processTransaction" reverted with the following reason: + Wrong old state hash + + Contract Call: + address: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 + function: processTransaction(bytes _proof, bytes32[] _publicInputs) + args: (0x0000000000000000000000000000000000000000000000042ab5d6d1986846cf00000000000000000000000000000000000000000000000b75c020998797da7800000000000000000000000000000000000000000000000 + ``` + +#### `server/index.mjs` {#server-index-mjs-2} + +اس فائل میں تبدیلیاں زیادہ تر اصل پروف بنانے اور اسے آن چین جمع کرنے سے متعلق ہیں۔ + +```js +import { exec } from 'child_process' +import util from 'util' + +const execPromise = util.promisify(exec) +``` + +ہمیں آن چین بھیجنے کے لیے اصل پروف بنانے کے لیے [Barretenberg پیکیج](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg) کا استعمال کرنے کی ضرورت ہے۔ ہم اس پیکیج کو یا تو کمانڈ لائن انٹرفیس (`bb`) چلا کر یا [JavaScript لائبریری، `bb.js`](https://www.npmjs.com/package/@aztec/bb.js) کا استعمال کر کے استعمال کر سکتے ہیں۔ JavaScript لائبریری مقامی طور پر کوڈ چلانے سے بہت سست ہے، اس لیے ہم یہاں کمانڈ لائن استعمال کرنے کے لیے [`exec`](https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback) کا استعمال کرتے ہیں۔ + +نوٹ کریں کہ اگر آپ `bb.js` استعمال کرنے کا فیصلہ کرتے ہیں، تو آپ کو ایک ایسا ورژن استعمال کرنے کی ضرورت ہے جو آپ کے استعمال کردہ Noir کے ورژن کے ساتھ مطابقت رکھتا ہو۔ لکھنے کے وقت، موجودہ Noir ورژن (1.0.0-beta.11) `bb.js` ورژن 0.87 استعمال کرتا ہے۔ + +```js +const zkBankAddress = process.env.ZKBANK_ADDRESS || "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512" +``` + +یہاں کا پتہ وہ ہے جو آپ کو ملتا ہے جب آپ ایک صاف `anvil` سے شروع کرتے ہیں اور اوپر دی گئی ہدایات پر عمل کرتے ہیں۔ + +```js +const walletClient = createWalletClient({ + chain: anvil, + transport: http(), + account: privateKeyToAccount("0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6") +}) +``` + +یہ نجی کلید `anvil` میں ڈیفالٹ پہلے سے فنڈ شدہ اکاؤنٹس میں سے ایک ہے۔ + +```js +const generateProof = async (witness, fileID) => { +``` + +`bb` قابل عمل کا استعمال کرتے ہوئے ایک پروف تیار کریں۔ + +```js + const fname = `witness-${fileID}.gz` + await fs.writeFile(fname, witness) +``` + +گواہ کو ایک فائل میں لکھیں۔ + +```js + await execPromise(`bb prove -b ./noir/target/zkBank.json -w ${fname} -o ${fileID} --oracle_hash keccak --output_format fields`) +``` + +اصل میں پروف بنائیں۔ یہ مرحلہ عوامی متغیرات کے ساتھ ایک فائل بھی بناتا ہے، لیکن ہمیں اس کی ضرورت نہیں ہے۔ ہمیں وہ متغیرات پہلے ہی `noir.execute` سے مل گئے ہیں۔ + +```js + const proof = "0x" + JSON.parse(await fs.readFile(`./${fileID}/proof_fields.json`)).reduce((a,b) => a+b, "").replace(/0x/g, "") +``` + +پروف `Field` اقدار کی ایک JSON صف ہے، ہر ایک کو ایک ہیکساڈیسیمل قدر کے طور پر پیش کیا جاتا ہے۔ تاہم، ہمیں اسے ٹرانزیکشن میں ایک ہی `bytes` قدر کے طور پر بھیجنے کی ضرورت ہے، جسے Viem ایک بڑی ہیکساڈیسیمل سٹرنگ سے ظاہر کرتا ہے۔ یہاں ہم تمام اقدار کو جوڑ کر، تمام `0x` کو ہٹا کر، اور پھر آخر میں ایک شامل کر کے فارمیٹ کو تبدیل کرتے ہیں۔ + +```js + await execPromise(`rm -r ${fname} ${fileID}`) + + return proof +} +``` + +صفائی کریں اور پروف واپس کریں۔ + +```js +const processMessage = async (message, signature) => { + . + . + . + + const publicFields = noirResult.returnValue.map(x=>'0x' + x.slice(2).padStart(64, "0")) +``` + +عوامی فیلڈز کو 32-بائٹ اقدار کی ایک صف ہونے کی ضرورت ہے۔ تاہم، چونکہ ہمیں ٹرانزیکشن ہیش کو دو `Field` اقدار کے درمیان تقسیم کرنے کی ضرورت تھی، یہ 16 بائٹ کی قدر کے طور پر ظاہر ہوتا ہے۔ یہاں ہم صفر شامل کرتے ہیں تاکہ Viem سمجھ جائے کہ یہ دراصل 32 بائٹس ہے۔ + +```js + const proof = await generateProof(noirResult.witness, `${fromAddress}-${nonce}`) +``` + +ہر پتہ ہر نونس کو صرف ایک بار استعمال کرتا ہے تاکہ ہم گواہ فائل اور آؤٹ پٹ ڈائرکٹری کے لیے ایک منفرد شناخت کنندہ کے طور پر `fromAddress` اور `nonce` کے امتزاج کا استعمال کر سکیں۔ + +```js + try { + await zkBank.write.processTransaction([ + proof, publicFields]) + } catch (err) { + console.log(`Verification error: ${err}`) + throw Error("Can't verify the transaction onchain") + } + . + . + . +} +``` + +ٹرانزیکشن کو چین پر بھیجیں۔ + +#### `smart-contracts/src/ZkBank.sol` {#smart-contracts-src-zkbank-sol} + +یہ آن چین کوڈ ہے جو ٹرانزیکشن وصول کرتا ہے۔ + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity >=0.8.21; + +import {HonkVerifier} from "./Verifier.sol"; + +contract ZkBank { + HonkVerifier immutable myVerifier; + bytes32 currentStateHash; + + constructor(address _verifierAddress, bytes32 _initialStateHash) { + currentStateHash = _initialStateHash; + myVerifier = HonkVerifier(_verifierAddress); + } +``` + +آن چین کوڈ کو دو متغیرات کا ٹریک رکھنے کی ضرورت ہے: تصدیق کنندہ (ایک الگ کنٹریکٹ جو `nargo` کے ذریعے بنایا گیا ہے) اور موجودہ اسٹیٹ ہیش۔ + +```solidity + event TransactionProcessed( + bytes32 indexed transactionHash, + bytes32 oldStateHash, + bytes32 newStateHash + ); +``` + +جب بھی اسٹیٹ تبدیل ہوتی ہے، ہم ایک `TransactionProcessed` ایونٹ جاری کرتے ہیں۔ + +```solidity + function processTransaction( + bytes calldata _proof, + bytes32[] calldata _publicFields + ) public { +``` + +یہ فنکشن ٹرانزیکشنز پر کارروائی کرتا ہے۔ یہ پروف (`bytes` کے طور پر) اور عوامی ان پٹس (`bytes32` ارے کے طور پر) حاصل کرتا ہے، اس فارمیٹ میں جس کی تصدیق کنندہ کو ضرورت ہوتی ہے (آن چین پروسیسنگ اور اس لیے گیس کے اخراجات کو کم کرنے کے لیے)۔ + +```solidity + require(_publicInputs[0] == currentStateHash, + "Wrong old state hash"); +``` + +زیرو-نالج پروف یہ ہونا چاہیے کہ ٹرانزیکشن ہمارے موجودہ ہیش سے ایک نئے میں تبدیل ہوتا ہے۔ + +```solidity + myVerifier.verify(_proof, _publicFields); +``` + +زیرو-نالج پروف کی تصدیق کے لیے تصدیق کنندہ کنٹریکٹ کو کال کریں۔ یہ مرحلہ ٹرانزیکشن کو واپس کر دیتا ہے اگر زیرو-نالج پروف غلط ہو۔ + +```solidity + currentStateHash = _publicFields[1]; + + emit TransactionProcessed( + _publicFields[2]<<128 | _publicFields[3], + _publicFields[0], + _publicFields[1] + ); + } +} +``` + +اگر سب کچھ ٹھیک ہو جاتا ہے، تو اسٹیٹ ہیش کو نئی قدر میں اپ ڈیٹ کریں اور ایک `TransactionProcessed` ایونٹ جاری کریں۔ + +## مرکزی جزو کے ذریعے بدسلوکی {#abuses} + +انفارمیشن سیکیورٹی تین خصوصیات پر مشتمل ہے: + +- _رازداری_، صارفین وہ معلومات نہیں پڑھ سکتے جو وہ پڑھنے کے مجاز نہیں ہیں۔ +- _انٹیگریٹی_، معلومات کو مجاز صارفین کے علاوہ مجاز طریقے سے تبدیل نہیں کیا جا سکتا۔ +- _دستیابی_، مجاز صارفین سسٹم کا استعمال کر سکتے ہیں۔ + +اس سسٹم پر، انٹیگریٹی زیرو-نالج پروف کے ذریعے فراہم کی جاتی ہے۔ دستیابی کی ضمانت دینا بہت مشکل ہے، اور رازداری ناممکن ہے، کیونکہ بینک کو ہر اکاؤنٹ کا بیلنس اور تمام ٹرانزیکشنز جاننے کی ضرورت ہے۔ کسی ایسی ہستی کو روکنے کا کوئی طریقہ نہیں ہے جس کے پاس معلومات ہوں وہ اس معلومات کو بانٹنے سے۔ + +[اسٹیلتھ ایڈریسز](https://vitalik.eth.limo/general/2023/01/20/stealth.html) کا استعمال کرتے ہوئے ایک حقیقی خفیہ بینک بنانا ممکن ہو سکتا ہے، لیکن یہ اس مضمون کے دائرہ کار سے باہر ہے۔ + +### غلط معلومات {#false-info} + +ایک طریقہ جس سے سرور انٹیگریٹی کی خلاف ورزی کر سکتا ہے وہ یہ ہے کہ جب [ڈیٹا کی درخواست کی جاتی ہے](https://github.com/qbzzt/250911-zk-bank/blob/03-smart-contracts/server/index.mjs#L278-L291) تو غلط معلومات فراہم کی جائیں۔ + +اسے حل کرنے کے لیے، ہم ایک دوسرا Noir پروگرام لکھ سکتے ہیں جو اکاؤنٹس کو ایک نجی ان پٹ کے طور پر اور اس پتے کو جس کے لیے معلومات کی درخواست کی گئی ہے ایک عوامی ان پٹ کے طور پر وصول کرتا ہے۔ آؤٹ پٹ اس پتے کا بیلنس اور نونس، اور اکاؤنٹس کا ہیش ہے۔ + +یقیناً، اس پروف کی تصدیق آن چین نہیں کی جا سکتی، کیونکہ ہم آن چین پر نونس اور بیلنس پوسٹ نہیں کرنا چاہتے۔ تاہم، اس کی تصدیق براؤزر میں چلنے والے کلائنٹ کوڈ کے ذریعے کی جا سکتی ہے۔ + +### جبری ٹرانزیکشنز {#forced-txns} + +L2s پر دستیابی کو یقینی بنانے اور سنسرشپ کو روکنے کا معمول کا طریقہ [جبری ٹرانزیکشنز](https://docs.optimism.io/stack/transactions/forced-transaction) ہے۔ لیکن جبری ٹرانزیکشنز زیرو-نالج پروف کے ساتھ نہیں ملتے ہیں۔ سرور وہ واحد ہستی ہے جو ٹرانزیکشنز کی تصدیق کر سکتی ہے۔ + +ہم جبری ٹرانزیکشنز کو قبول کرنے کے لیے `smart-contracts/src/ZkBank.sol` میں ترمیم کر سکتے ہیں اور سرور کو اس وقت تک اسٹیٹ کو تبدیل کرنے سے روک سکتے ہیں جب تک کہ ان پر کارروائی نہ ہو جائے۔ تاہم، یہ ہمیں ایک سادہ denial-of-service حملے کے لیے کھول دیتا ہے۔ کیا ہوگا اگر کوئی جبری ٹرانزیکشن غلط ہو اور اس لیے اس پر کارروائی کرنا ناممکن ہو؟ + +حل یہ ہے کہ ایک زیرو-نالج پروف ہو کہ ایک جبری ٹرانزیکشن غلط ہے۔ یہ سرور کو تین اختیارات دیتا ہے: + +- جبری ٹرانزیکشن پر کارروائی کریں، یہ ثابت کرنے کے لیے ایک زیرو-نالج پروف فراہم کریں کہ اس پر کارروائی ہو چکی ہے اور نئی اسٹیٹ ہیش۔ +- جبری ٹرانزیکشن کو مسترد کریں، اور کنٹریکٹ کو ایک زیرو-نالج پروف فراہم کریں کہ ٹرانزیکشن غلط ہے (نامعلوم پتہ، خراب نونس، یا ناکافی بیلنس)۔ +- جبری ٹرانزیکشن کو نظر انداز کریں۔ سرور کو اصل میں ٹرانزیکشن پر کارروائی کرنے پر مجبور کرنے کا کوئی طریقہ نہیں ہے، لیکن اس کا مطلب ہے کہ پورا نظام دستیاب نہیں ہے۔ + +#### دستیابی بانڈز {#avail-bonds} + +حقیقی زندگی کے نفاذ میں، سرور کو چلانے کے لیے شاید کسی قسم کا منافع کا محرک ہوگا۔ ہم سرور سے ایک دستیابی بانڈ پوسٹ کروا کر اس ترغیب کو مضبوط کر سکتے ہیں جسے کوئی بھی جلا سکتا ہے اگر ایک جبری ٹرانزیکشن پر ایک مخصوص مدت کے اندر کارروائی نہ کی جائے۔ + +### خراب Noir کوڈ {#bad-noir-code} + +عام طور پر، لوگوں کو ایک اسمارٹ کنٹریکٹ پر بھروسہ دلانے کے لیے ہم سورس کوڈ کو [بلاک ایکسپلورر](https://eth.blockscout.com/address/0x7D16d2c4e96BCFC8f815E15b771aC847EcbDB48b?tab=contract) پر اپ لوڈ کرتے ہیں۔ تاہم، زیرو-نالج پروف کے معاملے میں، یہ ناکافی ہے۔ + +`Verifier.sol` میں تصدیقی کلید ہوتی ہے، جو Noir پروگرام کا ایک فنکشن ہے۔ تاہم، وہ کلید ہمیں یہ نہیں بتاتی کہ Noir پروگرام کیا تھا۔ اصل میں ایک قابل اعتماد حل کے لیے، آپ کو Noir پروگرام (اور وہ ورژن جس نے اسے بنایا ہے) اپ لوڈ کرنے کی ضرورت ہے۔ ورنہ، زیرو-نالج پروف ایک مختلف پروگرام کی عکاسی کر سکتے ہیں، جس میں ایک بیک ڈور ہو۔ + +جب تک بلاک ایکسپلورر ہمیں Noir پروگرامز کو اپ لوڈ کرنے اور تصدیق کرنے کی اجازت دینا شروع نہیں کرتے، آپ کو یہ خود کرنا چاہیے (ترجیحاً [IPFS](/developers/tutorials/ipfs-decentralized-ui/) پر)۔ پھر نفیس صارفین سورس کوڈ ڈاؤن لوڈ کرنے، اسے خود کمپائل کرنے، `Verifier.sol` بنانے، اور یہ تصدیق کرنے کے قابل ہوں گے کہ یہ آن چین والے سے یکساں ہے۔ + +## نتیجہ {#conclusion} + +پلازما قسم کی ایپلی کیشنز کو معلومات کے ذخیرہ کے طور پر ایک مرکزی جزو کی ضرورت ہوتی ہے۔ یہ ممکنہ کمزوریوں کو کھولتا ہے لیکن، بدلے میں، ہمیں ان طریقوں سے رازداری کو برقرار رکھنے کی اجازت دیتا ہے جو خود بلاک چین پر دستیاب نہیں ہیں۔ زیرو-نالج پروف کے ساتھ ہم انٹیگریٹی کو یقینی بنا سکتے ہیں اور ممکنہ طور پر اسے مرکزی جزو چلانے والے کے لیے دستیابی کو برقرار رکھنے کے لیے اقتصادی طور پر فائدہ مند بنا سکتے ہیں۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ + +## اعترافات {#acknowledgements} + +- جوش کرائٹس نے اس مضمون کا ایک مسودہ پڑھا اور ایک کانٹے دار Noir مسئلے میں میری مدد کی۔ + +کوئی بھی باقی غلطیاں میری ذمہ داری ہیں۔ diff --git a/public/content/translations/ur/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/translations/ur/developers/tutorials/calling-a-smart-contract-from-javascript/index.md new file mode 100644 index 00000000000..201d7e8993b --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/calling-a-smart-contract-from-javascript/index.md @@ -0,0 +1,131 @@ +--- +title: "JavaScript سے اسمارٹ کنٹریکٹ کال کرنا" +description: "Dai ٹوکن کی مثال کا استعمال کرتے ہوئے JavaScript سے اسمارٹ کنٹریکٹ فنکشن کو کال کرنے کا طریقہ" +author: jdourlens +tags: [ "لین دین", "فرنٹ اینڈ", "JavaScript", "web3.js" ] +skill: beginner +lang: ur-in +published: 2020-04-19 +source: EthereumDev +sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/ +address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" +--- + +اس ٹیوٹوریل میں ہم دیکھیں گے کہ JavaScript سے [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) فنکشن کو کیسے کال کیا جائے۔ پہلے اسمارٹ کنٹریکٹ کی اسٹیٹ (state) کو پڑھنا ہے (مثال کے طور پر، ERC20 ہولڈر کا بیلنس)، پھر ہم ٹوکن کی منتقلی کر کے بلاک چین کی اسٹیٹ (state) میں ترمیم کریں گے۔ آپ کو [بلاک چین کے ساتھ تعامل کرنے کے لیے JS ماحول ترتیب دینے](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) سے پہلے ہی واقف ہونا چاہیے۔ + +اس مثال کے لیے ہم DAI ٹوکن کے ساتھ کھیلیں گے، جانچ کے مقصد کے لیے ہم ganache-cli کا استعمال کرتے ہوئے بلاک چین کو فورک (fork) کریں گے اور ایک ایسے ایڈریس کو غیر مقفل (unlock) کریں گے جس میں پہلے سے ہی بہت زیادہ DAI موجود ہے: + +```bash +ganache-cli -f https://mainnet.infura.io/v3/[YOUR INFURA KEY] -d -i 66 1 --unlock 0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81 +``` + +اسمارٹ کنٹریکٹ کے ساتھ تعامل کرنے کے لیے ہمیں اس کے ایڈریس اور ABI کی ضرورت ہوگی: + +```js +const ERC20TransferABI = [ + { + 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: "balanceOf", + outputs: [ + { + name: "balance", + type: "uint256", + }, + ], + payable: false, + stateMutability: "view", + type: "function", + }, +] + +const DAI_ADDRESS = "0x6b175474e89094c44da98b954eedeac495271d0f" +``` + +اس پروجیکٹ کے لیے ہم نے مکمل ERC20 ABI کو صرف `balanceOf` اور `transfer` فنکشنز رکھنے کے لیے مختصر کر دیا ہے لیکن آپ [مکمل ERC20 ABI یہاں](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/) تلاش کر سکتے ہیں۔ + +پھر ہمیں اپنے اسمارٹ کنٹریکٹ کو انسٹنٹی ایٹ (instantiate) کرنے کی ضرورت ہے: + +```js +const web3 = new Web3("http://localhost:8545") + +const daiToken = new web3.eth.Contract(ERC20TransferABI, DAI_ADDRESS) +``` + +ہم دو ایڈریس بھی سیٹ اپ کریں گے: + +- وہ جو منتقلی وصول کرے گا اور +- وہ جسے ہم نے پہلے ہی غیر مقفل کر دیا ہے جو اسے بھیجے گا: + +```js +const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81" +const receiverAddress = "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" +``` + +اگلے حصے میں ہم `balanceOf` فنکشن کو کال کریں گے تاکہ دونوں ایڈریسز کے پاس موجود ٹوکنز کی موجودہ رقم حاصل کی جا سکے۔ + +## کال: اسمارٹ کنٹریکٹ سے ویلیو پڑھنا {#call-reading-value-from-a-smart-contract} + +پہلی مثال ایک “کانسٹینٹ” (constant) میتھڈ کو کال کرے گی اور بغیر کوئی ٹرانزیکشن بھیجے EVM میں اس کے اسمارٹ کنٹریکٹ میتھڈ کو ایگزیکیوٹ کرے گی۔ اس کے لیے ہم ایک ایڈریس کا ERC20 بیلنس پڑھیں گے۔ [ERC20 ٹوکنز کے بارے میں ہمارا مضمون پڑھیں](/developers/tutorials/understand-the-erc-20-token-smart-contract/)۔ + +آپ ایک انسٹنٹی ایٹ (instantiated) کیے گئے اسمارٹ کنٹریکٹ میتھڈز تک رسائی حاصل کر سکتے ہیں جن کے لیے آپ نے ABI فراہم کیا ہے، اس طرح: `yourContract.methods.methodname`۔ `call` فنکشن کا استعمال کر کے آپ فنکشن کو ایگزیکیوٹ کرنے کا نتیجہ وصول کریں گے۔ + +```js +daiToken.methods.balanceOf(senderAddress).call(function (err, res) { + if (err) { + console.log("ایک خرابی واقع ہوئی ہے", err) + return + } + console.log("بیلنس یہ ہے: ", res) +}) +``` + +یاد رکھیں کہ DAI ERC20 میں 18 ڈیسیمل (decimals) ہوتے ہیں جس کا مطلب ہے کہ آپ کو صحیح رقم حاصل کرنے کے لیے 18 صفر ہٹانے کی ضرورت ہے۔ uint256 کو سٹرنگز کے طور پر واپس کیا جاتا ہے کیونکہ JavaScript بڑی عددی ویلیوز کو ہینڈل نہیں کرتا ہے۔ اگر آپ کو یقین نہیں ہے کہ [JS میں بڑے نمبروں سے کیسے نمٹا جائے تو bignumber.js کے بارے میں ہمارا ٹیوٹوریل دیکھیں](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/)۔ + +## بھیجیں: اسمارٹ کنٹریکٹ فنکشن میں ٹرانزیکشن بھیجنا {#send-sending-a-transaction-to-a-smart-contract-function} + +دوسری مثال کے لیے ہم DAI اسمارٹ کنٹریکٹ کے ٹرانسفر فنکشن کو کال کریں گے تاکہ اپنے دوسرے ایڈریس پر 10 DAI بھیج سکیں۔ ٹرانسفر فنکشن دو پیرامیٹرز قبول کرتا ہے: وصول کنندہ کا ایڈریس اور منتقل کیے جانے والے ٹوکن کی رقم: + +```js +daiToken.methods + .transfer(receiverAddress, "100000000000000000000") + .send({ from: senderAddress }, function (err, res) { + if (err) { + console.log("ایک خرابی واقع ہوئی ہے", err) + return + } + console.log("ٹرانزیکشن کا ہیش: " + res) + }) +``` + +کال فنکشن اس ٹرانزیکشن کا ہیش واپس کرتا ہے جسے بلاک چین میں مائن کیا جائے گا۔ Ethereum پر، ٹرانزیکشن ہیشز قابلِ قیاس ہوتے ہیں - اسی طرح ہم ٹرانزیکشن کو ایگزیکیوٹ کرنے سے پہلے اس کا ہیش حاصل کر سکتے ہیں ([یہاں جانیں کہ ہیشز کا حساب کیسے لگایا جاتا ہے](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction))۔ + +چونکہ فنکشن صرف ٹرانزیکشن کو بلاک چین میں جمع کرتا ہے، اس لیے ہم نتیجہ اس وقت تک نہیں دیکھ سکتے جب تک کہ ہمیں یہ معلوم نہ ہو جائے کہ اسے کب مائن کیا گیا ہے اور بلاک چین میں شامل کیا گیا ہے۔ اگلے ٹیوٹوریل میں ہم سیکھیں گے کہ [بلاک چین پر کسی ٹرانزیکشن کے ہیش کو جان کر اس کے ایگزیکیوٹ ہونے کا انتظار کیسے کیا جائے](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/)۔ diff --git a/public/content/translations/ur/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/ur/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md new file mode 100644 index 00000000000..875e969a19d --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md @@ -0,0 +1,584 @@ +--- +title: "آپ کے کانٹریکٹ کے لیے ایک یوزر انٹرفیس بنانا" +description: "TypeScript، React، Vite، اور Wagmi جیسے جدید اجزاء کا استعمال کرتے ہوئے، ہم ایک جدید، لیکن کم سے کم، یوزر انٹرفیس پر جائیں گے اور یہ سیکھیں گے کہ یوزر انٹرفیس سے والیٹ کو کیسے جوڑا جائے، معلومات کو پڑھنے کے لیے اسمارٹ کانٹریکٹ کو کال کریں، اسمارٹ کانٹریکٹ پر ٹرانزیکشن بھیجیں، اور تبدیلیوں کی شناخت کے لیے اسمارٹ کانٹریکٹ سے ایونٹس کی نگرانی کریں۔" +author: Ori Pomerantz +tags: [ "typescript", "react", "vite", "wagmi", "فرنٹ اینڈ" ] +skill: beginner +published: 2023-11-01 +lang: ur-in +sidebarDepth: 3 +--- + +آپ کو Ethereum ایکو سسٹم میں ایک ایسی خصوصیت ملی جس کی ہمیں ضرورت ہے۔ آپ نے اسے نافذ کرنے کے لیے اسمارٹ کانٹریکٹس لکھے، اور شاید کچھ متعلقہ کوڈ بھی جو آف چین چلتا ہے۔ یہ بہت اچھا ہے! بدقسمتی سے، یوزر انٹرفیس کے بغیر آپ کے پاس کوئی یوزر نہیں ہوگا، اور آخری بار جب آپ نے کوئی ویب سائٹ لکھی تھی تو لوگ ڈائل اپ موڈیم استعمال کرتے تھے اور JavaScript نیا تھا۔ + +یہ مضمون آپ کے لیے ہے۔ میں مانتا ہوں کہ آپ پروگرامنگ جانتے ہیں، اور شاید تھوڑا سا JavaScript اور HTML، لیکن آپ کی یوزر انٹرفیس کی مہارتیں زنگ آلود اور پرانی ہیں۔ ہم مل کر ایک سادہ جدید ایپلی کیشن کا جائزہ لیں گے تاکہ آپ دیکھ سکیں کہ آج کل یہ کیسے کیا جاتا ہے۔ + +## یہ اہم کیوں ہے {#why-important} + +نظریاتی طور پر، آپ لوگوں کو اپنے کانٹریکٹس کے ساتھ تعامل کرنے کے لیے [Etherscan](https://holesky.etherscan.io/address/0x432d810484add7454ddb3b5311f0ac2e95cecea8#writeContract) یا [Blockscout](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=write_contract) کا استعمال کروا سکتے ہیں۔ یہ تجربہ کار Ethereans کے لیے بہت اچھا ہوگا۔ لیکن ہم [ایک ارب اور لوگوں](https://blog.ethereum.org/2021/05/07/ethereum-for-the-next-billion) کی خدمت کرنے کی کوشش کر رہے ہیں۔ یہ ایک بہترین یوزر تجربے کے بغیر نہیں ہوگا، اور ایک دوستانہ یوزر انٹرفیس اس کا ایک بڑا حصہ ہے۔ + +## Greeter ایپلی کیشن {#greeter-app} + +ایک جدید UI کے کام کرنے کے پیچھے بہت زیادہ تھیوری ہے، اور [بہت سی اچھی سائٹس](https://react.dev/learn/thinking-in-react) [ہیں جو اس کی وضاحت کرتی ہیں](https://wagmi.sh/core/getting-started)۔ ان سائٹس کے ذریعے کیے گئے عمدہ کام کو دہرانے کے بجائے، میں یہ مانوں گا کہ آپ کر کے سیکھنا پسند کرتے ہیں اور ایک ایسی ایپلی کیشن سے شروعات کرتے ہیں جس کے ساتھ آپ کھیل سکتے ہیں۔ چیزوں کو انجام دینے کے لیے آپ کو اب بھی تھیوری کی ضرورت ہے، اور ہم اس پر آئیں گے - ہم صرف سورس فائل بہ سورس فائل جائیں گے، اور جیسے جیسے ہم ان تک پہنچیں گے چیزوں پر تبادلہ خیال کریں گے۔ + +### انسٹالیشن {#installation} + +1. اگر ضروری ہو تو، اپنے والیٹ میں [Holesky بلاک چین](https://chainlist.org/?search=holesky&testnets=true) شامل کریں اور [ٹیسٹ ETH حاصل کریں](https://www.holeskyfaucet.io/)۔ + +2. github ریپوزٹری کو کلون کریں۔ + + ```sh + git clone https://github.com/qbzzt/20230801-modern-ui.git + ``` + +3. ضروری پیکجز انسٹال کریں۔ + + ```sh + cd 20230801-modern-ui + pnpm install + ``` + +4. ایپلی کیشن شروع کریں۔ + + ```sh + pnpm dev + ``` + +5. ایپلی کیشن کے ذریعے دکھائے گئے URL پر براؤز کریں۔ زیادہ تر معاملات میں، یہ [http://localhost:5173/](http://localhost:5173/) ہے۔ + +6. آپ کانٹریکٹ کا سورس کوڈ، Hardhat کے Greeter کا تھوڑا سا تبدیل شدہ ورژن، [ایک بلاک چین ایکسپلورر پر](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contract) دیکھ سکتے ہیں۔ + +### فائل واک تھرو {#file-walk-through} + +#### `index.html` {#index-html} + +یہ فائل اس لائن کے علاوہ معیاری HTML بوائلرپلیٹ ہے، جو اسکرپٹ فائل کو امپورٹ کرتی ہے۔ + +```html + +``` + +#### `src/main.tsx` {#main-tsx} + +فائل ایکسٹینشن ہمیں بتاتی ہے کہ یہ فائل ایک [React کمپونینٹ](https://www.w3schools.com/react/react_components.asp) ہے جو [TypeScript](https://www.typescriptlang.org/) میں لکھی گئی ہے، یہ JavaScript کی ایک ایکسٹینشن ہے جو [ٹائپ چیکنگ](https://en.wikipedia.org/wiki/Type_system#Type_checking) کو سپورٹ کرتی ہے۔ TypeScript کو JavaScript میں کمپائل کیا جاتا ہے، لہذا ہم اسے کلائنٹ سائیڈ ایگزیکیوشن کے لیے استعمال کر سکتے ہیں۔ + +```tsx +import '@rainbow-me/rainbowkit/styles.css' +import { RainbowKitProvider } from '@rainbow-me/rainbowkit' +import * as React from 'react' +import * as ReactDOM from 'react-dom/client' +import { WagmiConfig } from 'wagmi' +import { chains, config } from './wagmi' +``` + +ہمیں درکار لائبریری کوڈ امپورٹ کریں۔ + +```tsx +import { App } from './App' +``` + +اس React کمپونینٹ کو امپورٹ کریں جو ایپلی کیشن کو نافذ کرتا ہے (نیچے دیکھیں)۔ + +```tsx +ReactDOM.createRoot(document.getElementById('root')!).render( +``` + +روٹ React کمپونینٹ بنائیں۔ `render` کا پیرامیٹر [JSX](https://www.w3schools.com/react/react_jsx.asp) ہے، ایک ایکسٹینشن زبان جو HTML اور JavaScript/TypeScript دونوں کا استعمال کرتی ہے۔ یہاں کا ایکسکلیمیشن پوائنٹ TypeScript کمپونینٹ کو بتاتا ہے: "آپ نہیں جانتے کہ `document.getElementById('root')` `ReactDOM.createRoot` کے لیے ایک درست پیرامیٹر ہوگا، لیکن فکر نہ کریں - میں ڈیولپر ہوں اور میں آپ کو بتا رہا ہوں کہ یہ ہوگا۔"۔ + +```tsx + +``` + +ایپلی کیشن [ایک `React.StrictMode` کمپونینٹ](https://react.dev/reference/react/StrictMode) کے اندر جا رہی ہے۔ یہ کمپونینٹ React لائبریری کو اضافی ڈیبگنگ چیکس داخل کرنے کے لیے کہتا ہے، جو ڈیولپمنٹ کے دوران مفید ہے۔ + +```tsx + +``` + +ایپلی کیشن [ایک `WagmiConfig` کمپونینٹ](https://wagmi.sh/react/api/WagmiProvider) کے اندر بھی ہے۔ [wagmi (we are going to make it) لائبریری](https://wagmi.sh/) React UI کی تعریفوں کو Ethereum ڈی سینٹرلائزڈ ایپلی کیشن لکھنے کے لیے [viem لائبریری](https://viem.sh/) سے جوڑتی ہے۔ + +```tsx + +``` + +اور آخر میں، [ایک `RainbowKitProvider` کمپونینٹ](https://www.rainbowkit.com/)۔ یہ کمپونینٹ لاگ آن کرنے اور والیٹ اور ایپلی کیشن کے درمیان مواصلات کو ہینڈل کرتا ہے۔ + +```tsx + +``` + +اب ہمارے پاس ایپلی کیشن کے لیے کمپونینٹ ہو سکتا ہے، جو اصل میں UI کو نافذ کرتا ہے۔ کمپونینٹ کے آخر میں `/>` React کو بتاتا ہے کہ اس کمپونینٹ کے اندر کوئی تعریف نہیں ہے، جیسا کہ XML معیار کے مطابق ہے۔ + +```tsx + + + , +) +``` + +یقیناً، ہمیں دوسرے کمپونینٹس کو بند کرنا ہوگا۔ + +#### `src/App.tsx` {#app-tsx} + +```tsx +import { ConnectButton } from '@rainbow-me/rainbowkit' +import { useAccount } from 'wagmi' +import { Greeter } from './components/Greeter' + +export function App() { +``` + +یہ React کمپونینٹ بنانے کا معیاری طریقہ ہے - ایک ایسا فنکشن بیان کریں جسے ہر بار رینڈر کرنے کی ضرورت پڑنے پر کال کیا جاتا ہے۔ اس فنکشن میں عام طور پر سب سے اوپر کچھ TypeScript یا JavaScript کوڈ ہوتا ہے، جس کے بعد ایک `return` اسٹیٹمنٹ ہوتا ہے جو JSX کوڈ کو واپس کرتا ہے۔ + +```tsx + const { isConnected } = useAccount() +``` + +یہاں ہم یہ چیک کرنے کے لیے [`useAccount`](https://wagmi.sh/react/api/hooks/useAccount) کا استعمال کرتے ہیں کہ آیا ہم والیٹ کے ذریعے بلاک چین سے جڑے ہیں یا نہیں۔ + +کنونشن کے مطابق، React میں `use...` کہلانے والے فنکشنز [ہکس](https://www.w3schools.com/react/react_hooks.asp) ہوتے ہیں جو کسی قسم کا ڈیٹا واپس کرتے ہیں۔ جب آپ اس طرح کے ہکس استعمال کرتے ہیں، تو نہ صرف آپ کا کمپونینٹ ڈیٹا حاصل کرتا ہے، بلکہ جب وہ ڈیٹا تبدیل ہوتا ہے تو کمپونینٹ کو اپ ڈیٹ شدہ معلومات کے ساتھ دوبارہ رینڈر کیا جاتا ہے۔ + +```tsx + return ( + <> +``` + +React کمپونینٹ کے JSX کو _لازماً_ ایک کمپونینٹ واپس کرنا چاہیے۔ جب ہمارے پاس متعدد کمپونینٹس ہوں اور ہمارے پاس کوئی ایسی چیز نہ ہو جو "فطری طور پر" لپیٹتی ہو تو ہم ایک خالی کمپونینٹ (`<> ...` استعمال کرتے ہیں `) تاکہ انہیں ایک ہی کمپونینٹ بنایا جا سکے۔ + +```tsx +

Greeter

+ +``` + +ہمیں RainbowKit سے [`ConnectButton` کمپونینٹ](https://www.rainbowkit.com/docs/connect-button) ملتا ہے۔ جب ہم جڑے نہیں ہوتے ہیں، تو یہ ہمیں ایک `Connect Wallet` بٹن دیتا ہے جو ایک موڈل کھولتا ہے جو والیٹس کی وضاحت کرتا ہے اور آپ کو یہ انتخاب کرنے دیتا ہے کہ آپ کون سا استعمال کرتے ہیں۔ جب ہم جڑے ہوتے ہیں، تو یہ ہمارے استعمال کردہ بلاک چین، ہمارے اکاؤنٹ کا ایڈریس، اور ہمارے ETH بیلنس کو دکھاتا ہے۔ ہم ان ڈسپلیز کو نیٹ ورک تبدیل کرنے یا منقطع کرنے کے لیے استعمال کر سکتے ہیں۔ + +```tsx + {isConnected && ( +``` + +جب ہمیں JSX میں اصل JavaScript (یا TypeScript جو JavaScript میں کمپائل کیا جائے گا) داخل کرنے کی ضرورت ہوتی ہے، تو ہم بریکٹس (`{}`) کا استعمال کرتے ہیں۔ + +سنٹیکس `a && b` [`a ?` کا مختصر ہے b : a`](https://www.w3schools.com/react/react_es6_ternary.asp)۔ یعنی، اگر `a`درست ہے تو یہ`b`کا اندازہ کرتا ہے اور بصورت دیگر یہ`a`کا اندازہ کرتا ہے (جو`false`، `0`، وغیرہ ہو سکتا ہے)۔ یہ React کو بتانے کا ایک آسان طریقہ ہے کہ ایک کمپونینٹ کو صرف تب ہی دکھایا جانا چاہیے جب کوئی خاص شرط پوری ہو۔ + +اس معاملے میں، ہم صرف یوزر کو `Greeter` دکھانا چاہتے ہیں اگر یوزر بلاک چین سے جڑا ہو۔ + +```tsx + + )} + + ) +} +``` + +#### `src/components/Greeter.tsx` {#greeter-tsx} + +اس فائل میں UI کی زیادہ تر فنکشنلٹی موجود ہے۔ اس میں ایسی تعریفیں شامل ہیں جو عام طور پر متعدد فائلوں میں ہوتی ہیں، لیکن چونکہ یہ ایک ٹیوٹوریل ہے، پروگرام کو پہلی بار سمجھنے میں آسانی کے لیے بہتر بنایا گیا ہے، نہ کہ کارکردگی یا دیکھ بھال کی آسانی کے لیے۔ + +```tsx +import { useState, ChangeEventHandler } from 'react' +import { useNetwork, + useReadContract, + usePrepareContractWrite, + useContractWrite, + useContractEvent + } from 'wagmi' +``` + +ہم ان لائبریری فنکشنز کا استعمال کرتے ہیں۔ دوبارہ، ان کی وضاحت نیچے کی گئی ہے جہاں وہ استعمال ہوتے ہیں۔ + +```tsx +import { AddressType } from 'abitype' +``` + +[`abitype` لائبریری](https://abitype.dev/) ہمیں مختلف Ethereum ڈیٹا کی اقسام کے لیے TypeScript کی تعریفیں فراہم کرتی ہے، جیسے [`AddressType`](https://abitype.dev/config#addresstype)۔ + +```tsx +let greeterABI = [ + . + . + . +] as const // greeterABI +``` + +`Greeter` کانٹریکٹ کے لیے ABI۔ +اگر آپ ایک ہی وقت میں کانٹریکٹس اور UI تیار کر رہے ہیں تو آپ عام طور پر انہیں ایک ہی ریپوزٹری میں ڈالیں گے اور Solidity کمپائلر کے ذریعہ تیار کردہ ABI کو اپنی ایپلی کیشن میں ایک فائل کے طور پر استعمال کریں گے۔ تاہم، یہاں اس کی ضرورت نہیں ہے کیونکہ کانٹریکٹ پہلے ہی تیار ہو چکا ہے اور تبدیل نہیں ہونے والا ہے۔ + +```tsx +type AddressPerBlockchainType = { + [key: number]: AddressType +} +``` + +TypeScript مضبوطی سے ٹائپ کیا گیا ہے۔ ہم اس تعریف کا استعمال اس ایڈریس کو متعین کرنے کے لیے کرتے ہیں جس میں `Greeter` کانٹریکٹ مختلف چینز پر ڈیپلائے کیا گیا ہے۔ کی (key) ایک نمبر (chainId) ہے، اور ویلیو ایک `AddressType` (ایک ایڈریس) ہے۔ + +```tsx +const contractAddrs: AddressPerBlockchainType = { + // Holesky + 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8', + + // Sepolia + 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0' +} +``` + +دو سپورٹڈ نیٹ ورکس پر کانٹریکٹ کا ایڈریس: [Holesky](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contact_code) اور [Sepolia](https://eth-sepolia.blockscout.com/address/0x7143d5c190F048C8d19fe325b748b081903E3BF0?tab=contact_code)۔ + +نوٹ: دراصل ایک تیسری تعریف ہے، Redstone Holesky کے لیے، اس کی وضاحت نیچے کی جائے گی۔ + +```tsx +type ShowObjectAttrsType = { + name: string, + object: any +} +``` + +اس قسم کا استعمال `ShowObject` کمپونینٹ (جس کی وضاحت بعد میں کی گئی ہے) کے پیرامیٹر کے طور پر کیا جاتا ہے۔ اس میں آبجیکٹ کا نام اور اس کی ویلیو شامل ہے، جو ڈیبگنگ کے مقاصد کے لیے دکھائے جاتے ہیں۔ + +```tsx +type ShowGreetingAttrsType = { + greeting: string | undefined +} +``` + +کسی بھی وقت، ہم یا تو جان سکتے ہیں کہ گریٹنگ کیا ہے (کیونکہ ہم نے اسے بلاک چین سے پڑھا ہے) یا نہیں جانتے (کیونکہ ہمیں ابھی تک یہ موصول نہیں ہوئی ہے)۔ لہذا ایک ایسی قسم کا ہونا مفید ہے جو یا تو ایک اسٹرنگ ہو یا کچھ بھی نہ ہو۔ + +##### `Greeter` کمپونینٹ {#greeter-component} + +```tsx +const Greeter = () => { +``` + +آخر کار، ہم کمپونینٹ کی وضاحت کرتے ہیں۔ + +```tsx + const { chain } = useNetwork() +``` + +اس چین کے بارے میں معلومات جسے ہم استعمال کر رہے ہیں، [wagmi](https://wagmi.sh/react/hooks/useNetwork) کی بدولت۔ +چونکہ یہ ایک ہک (`use...`) ہے، ہر بار جب یہ معلومات تبدیل ہوتی ہیں تو کمپونینٹ دوبارہ تیار ہوتا ہے۔ + +```tsx + const greeterAddr = chain && contractAddrs[chain.id] +``` + +Greeter کانٹریکٹ کا ایڈریس، جو چین کے لحاظ سے مختلف ہوتا ہے (اور جو `undefined` ہوتا ہے اگر ہمارے پاس چین کی معلومات نہ ہوں یا ہم کسی ایسی چین پر ہوں جس میں وہ کانٹریکٹ نہ ہو)۔ + +```tsx + const readResults = useReadContract({ + address: greeterAddr, + abi: greeterABI, + functionName: "greet" , // No arguments + watch: true + }) +``` + +[`useReadContract` ہک](https://wagmi.sh/react/api/hooks/useReadContract) ایک کانٹریکٹ سے معلومات پڑھتا ہے۔ آپ دیکھ سکتے ہیں کہ یہ UI میں `readResults` کو پھیلا کر کون سی معلومات واپس کرتا ہے۔ اس معاملے میں ہم چاہتے ہیں کہ یہ دیکھتا رہے تاکہ جب گریٹنگ تبدیل ہو تو ہمیں مطلع کیا جائے۔ + +**نوٹ:** ہم [`setGreeting` ایونٹس](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=logs) کو سن سکتے ہیں یہ جاننے کے لیے کہ گریٹنگ کب تبدیل ہوتی ہے اور اس طرح اپ ڈیٹ کریں۔ تاہم، جب کہ یہ زیادہ موثر ہو سکتا ہے، یہ تمام معاملات میں لاگو نہیں ہوگا۔ جب یوزر ایک مختلف چین پر سوئچ کرتا ہے تو گریٹنگ بھی تبدیل ہو جاتی ہے، لیکن اس تبدیلی کے ساتھ کوئی ایونٹ نہیں ہوتا ہے۔ ہمارے پاس کوڈ کا ایک حصہ ایونٹس کو سن رہا ہوسکتا ہے اور دوسرا چین کی تبدیلیوں کی شناخت کے لیے، لیکن یہ صرف [`watch` پیرامیٹر](https://wagmi.sh/react/api/hooks/useReadContract#watch-optional) سیٹ کرنے سے زیادہ پیچیدہ ہوگا۔ + +```tsx + const [ newGreeting, setNewGreeting ] = useState("") +``` + +React کا [`useState` ہک](https://www.w3schools.com/react/react_usestate.asp) ہمیں ایک اسٹیٹ متغیر کی وضاحت کرنے دیتا ہے، جس کی ویلیو کمپونینٹ کی ایک رینڈرنگ سے دوسری رینڈرنگ تک برقرار رہتی ہے۔ ابتدائی ویلیو پیرامیٹر ہے، اس معاملے میں خالی اسٹرنگ ہے۔ + +`useState` ہک دو ویلیوز کے ساتھ ایک لسٹ واپس کرتا ہے: + +1. اسٹیٹ متغیر کی موجودہ ویلیو۔ +2. جب ضرورت ہو تو اسٹیٹ متغیر میں ترمیم کرنے کے لیے ایک فنکشن۔ چونکہ یہ ایک ہک ہے، ہر بار جب اسے کال کیا جاتا ہے تو کمپونینٹ دوبارہ رینڈر ہوتا ہے۔ + +اس معاملے میں، ہم نئی گریٹنگ کے لیے ایک اسٹیٹ متغیر استعمال کر رہے ہیں جسے یوزر سیٹ کرنا چاہتا ہے۔ + +```tsx + const greetingChange : ChangeEventHandler = (evt) => + setNewGreeting(evt.target.value) +``` + +یہ ایونٹ ہینڈلر اس وقت کے لیے ہے جب نئی گریٹنگ ان پٹ فیلڈ تبدیل ہوتی ہے۔ ٹائپ، [`ChangeEventHandler`](https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/forms_and_events/)، یہ بتاتا ہے کہ یہ ایک HTML ان پٹ عنصر کی ویلیو کی تبدیلی کے لیے ہینڈلر ہے۔ `` حصہ استعمال کیا جاتا ہے کیونکہ یہ ایک [جینرک ٹائپ](https://www.w3schools.com/typescript/typescript_basic_generics.php) ہے۔ + +```tsx + const preparedTx = usePrepareContractWrite({ + address: greeterAddr, + abi: greeterABI, + functionName: 'setGreeting', + args: [ newGreeting ] + }) + const workingTx = useContractWrite(preparedTx.config) +``` + +یہ کلائنٹ کے نقطہ نظر سے بلاک چین ٹرانزیکشن جمع کرنے کا عمل ہے: + +1. [`eth_estimateGas`](https://docs.alchemy.com/reference/eth-estimategas) کا استعمال کرتے ہوئے بلاک چین میں ایک نوڈ کو ٹرانزیکشن بھیجیں۔ +2. نوڈ سے جواب کا انتظار کریں۔ +3. جب جواب موصول ہو جائے، تو یوزر سے والیٹ کے ذریعے ٹرانزیکشن پر دستخط کرنے کے لیے کہیں۔ یہ مرحلہ نوڈ کا جواب موصول ہونے کے بعد _ہونا_ چاہیے کیونکہ یوزر کو دستخط کرنے سے پہلے ٹرانزیکشن کی گیس کی لاگت دکھائی جاتی ہے۔ +4. یوزر کے منظور کرنے کا انتظار کریں۔ +5. ٹرانزیکشن کو دوبارہ بھیجیں، اس بار [`eth_sendRawTransaction`](https://docs.alchemy.com/reference/eth-sendrawtransaction) کا استعمال کرتے ہوئے۔ + +مرحلہ 2 میں ممکنہ طور پر قابل توجہ وقت لگے گا، جس کے دوران یوزرس سوچیں گے کہ کیا ان کا کمانڈ واقعی یوزر انٹرفیس کو موصول ہوا ہے اور ان سے ابھی تک ٹرانزیکشن پر دستخط کرنے کے لیے کیوں نہیں کہا جا رہا ہے۔ یہ خراب یوزر تجربہ (UX) بناتا ہے۔ + +اس کا حل [prepare hooks](https://wagmi.sh/react/prepare-hooks) کا استعمال کرنا ہے۔ ہر بار جب کوئی پیرامیٹر تبدیل ہوتا ہے، تو فوری طور پر نوڈ کو `eth_estimateGas` کی درخواست بھیجیں۔ پھر، جب یوزر واقعی ٹرانزیکشن بھیجنا چاہتا ہے (اس معاملے میں **گریٹنگ اپ ڈیٹ کریں** دبا کر)، تو گیس کی لاگت معلوم ہوتی ہے اور یوزر فوری طور پر والیٹ کا صفحہ دیکھ سکتا ہے۔ + +```tsx + return ( +``` + +اب ہم آخر کار واپس کرنے کے لیے اصل HTML بنا سکتے ہیں۔ + +```tsx + <> +

Greeter

+ { + !readResults.isError && !readResults.isLoading && + + } +
+``` + +ایک `ShowGreeting` کمپونینٹ بنائیں (جس کی وضاحت نیچے کی گئی ہے)، لیکن صرف اس صورت میں جب گریٹنگ بلاک چین سے کامیابی کے ساتھ پڑھی گئی ہو۔ + +```tsx + +``` + +یہ ان پٹ ٹیکسٹ فیلڈ ہے جہاں یوزر ایک نئی گریٹنگ سیٹ کر سکتا ہے۔ ہر بار جب یوزر کوئی کی (key) دباتا ہے، ہم `greetingChange` کو کال کرتے ہیں جو `setNewGreeting` کو کال کرتا ہے۔ چونکہ `setNewGreeting` `useState` ہک سے آتا ہے، یہ `Greeter` کمپونینٹ کو دوبارہ رینڈر کرنے کا سبب بنتا ہے۔ اس کا مطلب یہ ہے کہ: + +- ہمیں نئی گریٹنگ کی ویلیو رکھنے کے لیے `value` کی وضاحت کرنے کی ضرورت ہے، کیونکہ بصورت دیگر یہ ڈیفالٹ، یعنی خالی اسٹرنگ میں واپس آ جائے گی۔ +- `usePrepareContractWrite` ہر بار جب `newGreeting` تبدیل ہوتا ہے تو کال کیا جاتا ہے، جس کا مطلب ہے کہ اس کے پاس ہمیشہ تیار ٹرانزیکشن میں تازہ ترین `newGreeting` ہوگا۔ + +```tsx + +``` + +اگر `workingTx.write` نہیں ہے تو ہم ابھی بھی گریٹنگ اپ ڈیٹ بھیجنے کے لیے ضروری معلومات کا انتظار کر رہے ہیں، لہذا بٹن غیر فعال ہے۔ اگر `workingTx.write` ویلیو ہے تو یہ ٹرانزیکشن بھیجنے کے لیے کال کرنے والا فنکشن ہے۔ + +```tsx +
+ + + + + ) +``` + +آخر میں، یہ دیکھنے میں آپ کی مدد کرنے کے لیے کہ ہم کیا کر رہے ہیں، ان تین آبجیکٹس کو دکھائیں جن کا ہم استعمال کرتے ہیں: + +- `readResults` +- `preparedTx` +- `workingTx` + +##### `ShowGreeting` کمپونینٹ {#showgreeting-component} + +یہ کمپونینٹ دکھاتا ہے + +```tsx +const ShowGreeting = (attrs : ShowGreetingAttrsType) => { +``` + +ایک کمپونینٹ فنکشن کمپونینٹ کی تمام صفات کے ساتھ ایک پیرامیٹر حاصل کرتا ہے۔ + +```tsx + return {attrs.greeting} +} +``` + +##### `ShowObject` کمپونینٹ {#showobject-component} + +معلومات کے مقاصد کے لیے، ہم اہم آبجیکٹس (`readResults` گریٹنگ پڑھنے کے لیے اور `preparedTx` اور `workingTx` ہمارے بنائے ہوئے ٹرانزیکشنز کے لیے) کو دکھانے کے لیے `ShowObject` کمپونینٹ کا استعمال کرتے ہیں۔ + +```tsx +const ShowObject = (attrs: ShowObjectAttrsType ) => { + const keys = Object.keys(attrs.object) + const funs = keys.filter(k => typeof attrs.object[k] == "function") + return <> +
+``` + +ہم UI کو تمام معلومات سے بے ترتیبی نہیں کرنا چاہتے، لہذا انہیں دیکھنے یا بند کرنے کو ممکن بنانے کے لیے، ہم [`details`](https://www.w3schools.com/tags/tag_details.asp) ٹیگ کا استعمال کرتے ہیں۔ + +```tsx + {attrs.name} +
+        {JSON.stringify(attrs.object, null, 2)}
+```
+
+زیادہ تر فیلڈز [`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp) کا استعمال کرتے ہوئے دکھائے جاتے ہیں۔
+
+```tsx
+      
+ { funs.length > 0 && + <> + فنکشنز: +
    +``` + +مستثنیٰ فنکشنز ہیں، جو [JSON معیار](https://www.json.org/json-en.html) کا حصہ نہیں ہیں، لہذا انہیں الگ سے دکھانا پڑتا ہے۔ + +```tsx + {funs.map((f, i) => +``` + +JSX کے اندر، `{` کرلی بریکٹ `}` کے اندر کوڈ کو JavaScript کے طور پر سمجھا جاتا ہے۔ پھر، `(` ریگولر بریکٹ `)` کے اندر کوڈ کو دوبارہ JSX کے طور پر سمجھا جاتا ہے۔ + +```tsx + (
  • {f}
  • ) + )} +``` + +React کو [DOM ٹری](https://www.w3schools.com/js/js_htmldom.asp) میں ٹیگز کے لیے الگ شناختی نشانات کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ ایک ہی ٹیگ کے بچوں (اس معاملے میں، [غیر ترتیب شدہ فہرست](https://www.w3schools.com/tags/tag_ul.asp)) کو مختلف `key` صفات کی ضرورت ہوتی ہے۔ + +```tsx +
+ + } +
+ +} +``` + +مختلف HTML ٹیگز کو ختم کریں۔ + +##### حتمی `export` {#the-final-export} + +```tsx +export { Greeter } +``` + +`Greeter` کمپونینٹ وہ ہے جسے ہمیں ایپلی کیشن کے لیے ایکسپورٹ کرنے کی ضرورت ہے۔ + +#### `src/wagmi.ts` {#wagmi-ts} + +آخر میں، WAGMI سے متعلق مختلف تعریفیں `src/wagmi.ts` میں ہیں۔ میں یہاں ہر چیز کی وضاحت نہیں کروں گا، کیونکہ اس کا زیادہ تر حصہ بوائلرپلیٹ ہے جسے آپ کو تبدیل کرنے کی ضرورت کا امکان نہیں ہے۔ + +یہاں کا کوڈ [github پر موجود](https://github.com/qbzzt/20230801-modern-ui/blob/main/src/wagmi.ts) کوڈ جیسا بالکل نہیں ہے کیونکہ مضمون میں بعد میں ہم ایک اور چین ([Redstone Holesky](https://redstone.xyz/docs/network-info)) شامل کرتے ہیں۔ + +```ts +import { getDefaultWallets } from '@rainbow-me/rainbowkit' +import { configureChains, createConfig } from 'wagmi' +import { holesky, sepolia } from 'wagmi/chains' +``` + +ان بلاک چینز کو امپورٹ کریں جن کو ایپلی کیشن سپورٹ کرتی ہے۔ آپ سپورٹڈ چینز کی فہرست [viem github میں](https://github.com/wagmi-dev/viem/tree/main/src/chains/definitions) دیکھ سکتے ہیں۔ + +```ts +import { publicProvider } from 'wagmi/providers/public' + +const walletConnectProjectId = 'c96e690bb92b6311e8e9b2a6a22df575' +``` + +[WalletConnect](https://walletconnect.com/) استعمال کرنے کے لیے آپ کو اپنی ایپلی کیشن کے لیے ایک پروجیکٹ آئی ڈی کی ضرورت ہے۔ آپ اسے [cloud.walletconnect.com پر](https://cloud.walletconnect.com/sign-in) حاصل کر سکتے ہیں۔ + +```ts +const { chains, publicClient, webSocketPublicClient } = configureChains( + [ holesky, sepolia ], + [ + publicProvider(), + ], +) + +const { connectors } = getDefaultWallets({ + appName: 'My wagmi + RainbowKit App', + chains, + projectId: walletConnectProjectId, +}) + +export const config = createConfig({ + autoConnect: true, + connectors, + publicClient, + webSocketPublicClient, +}) + +export { chains } +``` + +### ایک اور بلاک چین شامل کرنا {#add-blockchain} + +آج کل بہت سے [L2 اسکیلنگ سلوشن](/layer-2/) ہیں، اور آپ کچھ ایسے کو سپورٹ کرنا چاہ سکتے ہیں جنہیں viem ابھی تک سپورٹ نہیں کرتا ہے۔ ایسا کرنے کے لیے، آپ `src/wagmi.ts` میں ترمیم کریں۔ یہ ہدایات وضاحت کرتی ہیں کہ [Redstone Holesky](https://redstone.xyz/docs/network-info) کو کیسے شامل کیا جائے۔ + +1. viem سے `defineChain` ٹائپ امپورٹ کریں۔ + + ```ts + import { defineChain } from 'viem' + ``` + +2. نیٹ ورک کی تعریف شامل کریں۔ + + ```ts + const redstoneHolesky = defineChain({ + id: 17_001, + name: 'Redstone Holesky', + network: 'redstone-holesky', + nativeCurrency: { + decimals: 18, + name: 'Ether', + symbol: 'ETH', + }, + rpcUrls: { + default: { + http: ['https://rpc.holesky.redstone.xyz'], + webSocket: ['wss://rpc.holesky.redstone.xyz/ws'], + }, + public: { + http: ['https://rpc.holesky.redstone.xyz'], + webSocket: ['wss://rpc.holesky.redstone.xyz/ws'], + }, + }, + blockExplorers: { + default: { name: 'Explorer', url: 'https://explorer.holesky.redstone.xyz' }, + }, + }) + ``` + +3. نئی چین کو `configureChains` کال میں شامل کریں۔ + + ```ts + const { chains, publicClient, webSocketPublicClient } = configureChains( + [ holesky, sepolia, redstoneHolesky ], + [ publicProvider(), ], + ) + ``` + +4. یقینی بنائیں کہ ایپلی کیشن نئے نیٹ ورک پر آپ کے کانٹریکٹس کے لیے ایڈریس جانتی ہے۔ اس معاملے میں، ہم `src/components/Greeter.tsx` میں ترمیم کرتے ہیں: + + ```ts + const contractAddrs : AddressPerBlockchainType = { + // Holesky + 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8', + + // Redstone Holesky + 17001: '0x4919517f82a1B89a32392E1BF72ec827ba9986D3', + + // Sepolia + 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0' + } + ``` + +## نتیجہ {#conclusion} + +یقیناً، آپ واقعی `Greeter` کے لیے یوزر انٹرفیس فراہم کرنے کی پرواہ نہیں کرتے ہیں۔ آپ اپنے کانٹریکٹس کے لیے ایک یوزر انٹرفیس بنانا چاہتے ہیں۔ اپنی ایپلی کیشن بنانے کے لیے، ان مراحل کو چلائیں: + +1. ایک wagmi ایپلی کیشن بنانے کے لیے متعین کریں۔ + + ```sh copy + pnpm create wagmi + ``` + +2. ایپلی کیشن کا نام دیں۔ + +3. **React** فریم ورک منتخب کریں۔ + +4. **Vite** ویرینٹ منتخب کریں۔ + +5. آپ [Rainbow kit شامل کر سکتے ہیں](https://www.rainbowkit.com/docs/installation#manual-setup)۔ + +اب جائیں اور اپنے کانٹریکٹس کو وسیع دنیا کے لیے قابل استعمال بنائیں۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ + diff --git a/public/content/translations/ur/developers/tutorials/deploying-your-first-smart-contract/index.md b/public/content/translations/ur/developers/tutorials/deploying-your-first-smart-contract/index.md new file mode 100644 index 00000000000..7a58026b9ba --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/deploying-your-first-smart-contract/index.md @@ -0,0 +1,95 @@ +--- +title: "اپنا پہلا سمارٹ کنٹریکٹ ڈیپلائے کرنا" +description: "ایتھیریم ٹیسٹ نیٹ ورک پر اپنا پہلا سمارٹ کنٹریکٹ ڈیپلائے کرنے کا تعارف" +author: "jdourlens" +tags: [ "اسمارٹ معاہدات", "remix", "solidity", "تعینات کرنا" ] +skill: beginner +lang: ur-in +published: 2020-04-03 +source: EthereumDev +sourceUrl: https://ethereumdev.io/deploying-your-first-smart-contract/ +address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" +--- + +میرا اندازہ ہے کہ آپ بھی ہماری طرح ایتھیریم بلاک چین پر اپنے پہلے [سمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) کو [ڈیپلائے](/developers/docs/smart-contracts/deploying/) کرنے اور اس کے ساتھ تعامل کرنے کے لیے پرجوش ہیں۔ + +پریشان نہ ہوں، چونکہ یہ ہمارا پہلا سمارٹ کنٹریکٹ ہے، ہم اسے [مقامی ٹیسٹ نیٹ ورک](/developers/docs/networks/) پر ڈیپلائے کریں گے تاکہ اسے ڈیپلائے کرنے اور اس کے ساتھ جتنا چاہیں کھیلنے میں آپ کا کوئی خرچ نہ آئے۔ + +## ہمارا کنٹریکٹ لکھنا {#writing-our-contract} + +پہلا قدم [Remix پر جانا](https://remix.ethereum.org/) اور ایک نئی فائل بنانا ہے۔ Remix انٹرفیس کے اوپری بائیں حصے میں ایک نئی فائل شامل کریں اور اپنی پسند کا فائل نام درج کریں۔ + +![Remix انٹرفیس میں ایک نئی فائل شامل کرنا](./remix.png) + +نئی فائل میں، ہم مندرجہ ذیل کوڈ پیسٹ کریں گے۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity >=0.5.17; + +contract Counter { + + // گنتی کی تعداد رکھنے کے لیے غیر دستخط شدہ int قسم کا عوامی متغیر + uint256 public count = 0; + + // فنکشن جو ہمارے کاؤنٹر میں اضافہ کرتا ہے + function increment() public { + count += 1; + } + + // گنتی کی قدر حاصل کرنے کے لیے غیر ضروری گیٹر + function getCount() public view returns (uint256) { + return count; + } + +} +``` + +اگر آپ پروگرامنگ کے عادی ہیں تو آپ آسانی سے اندازہ لگا سکتے ہیں کہ یہ پروگرام کیا کرتا ہے۔ یہاں لائن بہ لائن وضاحت دی گئی ہے: + +- لائن 4: ہم `Counter` نام کے ساتھ ایک کنٹریکٹ کی وضاحت کرتے ہیں۔ +- لائن 7: ہمارا کنٹریکٹ `count` نامی ایک غیر دستخط شدہ انٹیجر کو اسٹور کرتا ہے جو 0 سے شروع ہوتا ہے۔ +- لائن 10: پہلا فنکشن کنٹریکٹ کی حالت میں ترمیم کرے گا اور ہمارے متغیر `count` میں `increment()` کرے گا۔ +- لائن 15: دوسرا فنکشن صرف ایک گیٹر ہے تاکہ سمارٹ کنٹریکٹ کے باہر `count` متغیر کی قدر کو پڑھا جا سکے۔ نوٹ کریں کہ، چونکہ ہم نے اپنے `count` متغیر کو عوامی کے طور پر بیان کیا ہے، یہ ضروری نہیں ہے لیکن اسے ایک مثال کے طور پر دکھایا گیا ہے۔ + +یہ سب ہمارے پہلے سادہ سمارٹ کنٹریکٹ کے لیے ہے۔ جیسا کہ آپ جانتے ہوں گے، یہ جاوا یا C++ جیسی OOP (آبجیکٹ اورینٹڈ پروگرامنگ) زبانوں کی کلاس کی طرح لگتا ہے۔ اب ہمارے کنٹریکٹ کے ساتھ کھیلنے کا وقت ہے۔ + +## ہمارا کنٹریکٹ ڈیپلائے کرنا {#deploying-our-contract} + +چونکہ ہم نے اپنا پہلا سمارٹ کنٹریکٹ لکھا ہے، اب ہم اسے بلاک چین پر ڈیپلائے کریں گے تاکہ اس کے ساتھ کھیل سکیں۔ + +[بلاک چین پر سمارٹ کنٹریکٹ کو ڈیپلائے کرنا](/developers/docs/smart-contracts/deploying/) دراصل صرف ایک ٹرانزیکشن بھیجنا ہے جس میں کمپائل شدہ سمارٹ کنٹریکٹ کا کوڈ ہوتا ہے بغیر کسی وصول کنندہ کی وضاحت کیے۔ + +ہم سب سے پہلے بائیں جانب کمپائل آئیکن پر کلک کرکے [کنٹریکٹ کو کمپائل کریں گے](/developers/docs/smart-contracts/compiling/): + +![Remix ٹول بار میں کمپائل آئیکن](./remix-compile-button.png) + +پھر کمپائل بٹن پر کلک کریں: + +![Remix سولیڈیٹی کمپائلر میں کمپائل بٹن](./remix-compile.png) + +آپ "آٹو کمپائل" آپشن کو منتخب کرنے کا انتخاب کر سکتے ہیں تاکہ جب آپ ٹیکسٹ ایڈیٹر پر مواد محفوظ کریں تو کنٹریکٹ ہمیشہ کمپائل ہو جائے۔ + +پھر "ڈیپلائے اور رن ٹرانزیکشنز" اسکرین پر جائیں: + +![Remix ٹول بار میں ڈیپلائے آئیکن](./remix-deploy.png) + +ایک بار جب آپ "ڈیپلائے اور رن ٹرانزیکشنز" اسکرین پر ہوں، تو دو بار چیک کریں کہ آپ کے کنٹریکٹ کا نام ظاہر ہوتا ہے اور ڈیپلائے پر کلک کریں۔ جیسا کہ آپ صفحہ کے اوپری حصے میں دیکھ سکتے ہیں، موجودہ ماحول "JavaScript VM" ہے جس کا مطلب ہے کہ ہم اپنے سمارٹ کنٹریکٹ کو مقامی ٹیسٹ بلاک چین پر ڈیپلائے اور اس کے ساتھ تعامل کریں گے تاکہ تیزی سے اور بغیر کسی فیس کے ٹیسٹ کر سکیں۔ + +![Remix سولیڈیٹی کمپائلر میں ڈیپلائے بٹن](./remix-deploy-button.png) + +ایک بار جب آپ "ڈیپلائے" بٹن پر کلک کر لیں گے، تو آپ کو اپنا کنٹریکٹ نیچے ظاہر ہوتا نظر آئے گا۔ اسے پھیلانے کے لیے بائیں طرف کے تیر پر کلک کریں تاکہ ہم اپنے کنٹریکٹ کا مواد دیکھ سکیں۔ یہ ہمارا متغیر `counter`، ہمارا `increment()` فنکشن اور گیٹر `getCounter()` ہے۔ + +اگر آپ `count` یا `getCount` بٹن پر کلک کرتے ہیں، تو یہ دراصل کنٹریکٹ کے `count` متغیر کا مواد حاصل کرے گا اور اسے ظاہر کرے گا۔ چونکہ ہم نے ابھی تک `increment` فنکشن کو کال نہیں کیا ہے، اس لیے اسے 0 دکھانا چاہیے۔ + +![Remix سولیڈیٹی کمپائلر میں فنکشن بٹن](./remix-function-button.png) + +آئیے اب بٹن پر کلک کرکے `increment` فنکشن کو کال کریں۔ آپ کو ونڈو کے نیچے کی جانے والی ٹرانزیکشنز کے لاگز نظر آئیں گے۔ آپ دیکھیں گے کہ جب آپ `increment` بٹن کے بجائے ڈیٹا حاصل کرنے کے لیے بٹن دبا رہے ہوتے ہیں تو لاگز مختلف ہوتے ہیں۔ اس کی وجہ یہ ہے کہ بلاک چین پر ڈیٹا پڑھنے کے لیے کسی ٹرانزیکشن (لکھنے) یا فیس کی ضرورت نہیں ہوتی ہے۔ کیونکہ صرف بلاک چین کی حالت میں ترمیم کرنے کے لیے ٹرانزیکشن کرنے کی ضرورت ہوتی ہے: + +![ٹرانزیکشنز کا ایک لاگ](./transaction-log.png) + +انکریمنٹ بٹن دبانے کے بعد جو ہمارے `increment()` فنکشن کو کال کرنے کے لیے ایک ٹرانزیکشن پیدا کرے گا، اگر ہم کاؤنٹ یا گیٹ کاؤنٹ بٹنوں پر واپس کلک کرتے ہیں تو ہم اپنے سمارٹ کنٹریکٹ کی نئی اپ ڈیٹ شدہ حالت کو پڑھیں گے جس میں کاؤنٹ متغیر 0 سے بڑا ہوگا۔ + +![سمارٹ کنٹریکٹ کی نئی اپ ڈیٹ شدہ حالت](./updated-state.png) + +اگلے ٹیوٹوریل میں، ہم [آپ اپنے سمارٹ کنٹریکٹس میں ایونٹس کیسے شامل کر سکتے ہیں](/developers/tutorials/logging-events-smart-contracts/) کا احاطہ کریں گے۔ لاگنگ ایونٹس آپ کے سمارٹ کنٹریکٹ کو ڈیبگ کرنے اور یہ سمجھنے کا ایک آسان طریقہ ہے کہ فنکشن کو کال کرتے وقت کیا ہو رہا ہے۔ diff --git a/public/content/translations/ur/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md b/public/content/translations/ur/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md new file mode 100644 index 00000000000..6666440ae4b --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md @@ -0,0 +1,372 @@ +--- +title: "مقامی، ملٹی کلائنٹ ٹیسٹ نیٹ پر ایک dApp کو کیسے تیار اور ٹیسٹ کیا جائے" +description: "یہ گائیڈ پہلے آپ کو اس بارے میں بتائے گا کہ کسی dApp کو ڈیپلائے اور ٹیسٹ کرنے کے لیے ٹیسٹ نیٹ کا استعمال کرنے سے پہلے ملٹی کلائنٹ مقامی Ethereum ٹیسٹ نیٹ کو کیسے انسٹینٹیٹ اور کنفیگر کیا جائے۔" +author: "Tedi Mitiku" +tags: + [ + "کلائنٹس", + "نوڈز", + "اسمارٹ معاہدات", + "مرکبیت", + "کنسینسس لیئر", + "ایگزیکیوشن لیئر", + "testing" + ] +skill: intermediate +lang: ur-in +published: 2023-04-11 +--- + +## تعارف {#introduction} + +یہ گائیڈ آپ کو ایک قابل ترتیب مقامی Ethereum ٹیسٹ نیٹ کو انسٹینٹیٹ کرنے، اس پر ایک اسمارٹ کنٹریکٹ ڈیپلائے کرنے، اور آپ کے dApp کے خلاف ٹیسٹ چلانے کے لیے ٹیسٹ نیٹ کا استعمال کرنے کے عمل کے بارے میں بتاتا ہے۔ یہ گائیڈ ان dApp ڈیولپرز کے لیے ڈیزائن کیا گیا ہے جو لائیو ٹیسٹ نیٹ یا مین نیٹ پر ڈیپلائے کرنے سے پہلے اپنے dApps کو مقامی طور پر مختلف نیٹ ورک کنفیگریشنز کے خلاف تیار اور ٹیسٹ کرنا چاہتے ہیں۔ + +اس گائیڈ میں، آپ: + +- [Kurtosis](https://www.kurtosis.com/) کا استعمال کرتے ہوئے [`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) کے ساتھ ایک مقامی Ethereum ٹیسٹ نیٹ کو انسٹینٹیٹ کریں، +- اپنے Hardhat dApp ڈیولپمنٹ ماحول کو مقامی ٹیسٹ نیٹ سے جوڑیں تاکہ dApp کو کمپائل، ڈیپلائے اور ٹیسٹ کیا جا سکے، اور +- مقامی ٹیسٹ نیٹ کو کنفیگر کریں، بشمول نوڈس کی تعداد اور مخصوص EL/CL کلائنٹ جوڑی جیسے پیرامیٹرز، تاکہ مختلف نیٹ ورک کنفیگریشنز کے خلاف ڈیولپمنٹ اور ٹیسٹنگ ورک فلوز کو فعال کیا جا سکے۔ + +### Kurtosis کیا ہے؟ {#what-is-kurtosis} + +[Kurtosis](https://www.kurtosis.com/) ایک کمپوزیبل بلڈ سسٹم ہے جو ملٹی کنٹینر ٹیسٹ ماحول کو کنفیگر کرنے کے لیے ڈیزائن کیا گیا ہے۔ یہ خاص طور پر ڈیولپرز کو قابل تولید ماحول بنانے کے قابل بناتا ہے جس کے لیے ڈائنامک سیٹ اپ لاجک کی ضرورت ہوتی ہے، جیسے کہ بلاک چین ٹیسٹ نیٹس۔ + +اس گائیڈ میں، Kurtosis eth-network-package [`geth`](https://geth.ethereum.org/) ایگزیکیوشن لیئر (EL) کلائنٹ، نیز [`teku`](https://consensys.io/teku)، [`lighthouse`](https://lighthouse.sigmaprime.io/)، اور [`lodestar`](https://lodestar.chainsafe.io/) کنسینسس لیئر (CL) کلائنٹس کے لیے سپورٹ کے ساتھ ایک مقامی Ethereum ٹیسٹ نیٹ اسپن اپ کرتا ہے۔ یہ پیکیج Hardhat Network، Ganache، اور Anvil جیسے فریم ورکس میں نیٹ ورکس کے لیے ایک قابل ترتیب اور کمپوزیبل متبادل کے طور پر کام کرتا ہے۔ Kurtosis ڈیولپرز کو ان کے استعمال کردہ ٹیسٹ نیٹس پر زیادہ کنٹرول اور لچک فراہم کرتا ہے، جو ایک بڑی وجہ ہے کہ [Ethereum فاؤنڈیشن نے The Merge کو ٹیسٹ کرنے کے لیے Kurtosis کا استعمال کیا](https://www.kurtosis.com/blog/testing-the-ethereum-merge) اور نیٹ ورک اپ گریڈ کی جانچ کے لیے اس کا استعمال جاری رکھے ہوئے ہے۔ + +## Kurtosis سیٹ اپ کرنا {#setting-up-kurtosis} + +آگے بڑھنے سے پہلے، یقینی بنائیں کہ آپ کے پاس ہے: + +- اپنی مقامی مشین پر [ڈاکر انجن انسٹال اور شروع کیا](https://docs.kurtosis.com/install/#i-install--start-docker) +- [Kurtosis CLI انسٹال کیا](https://docs.kurtosis.com/install#ii-install-the-cli) (یا اگر آپ کے پاس پہلے سے ہی CLI انسٹال ہے تو اسے تازہ ترین ریلیز میں اپ گریڈ کیا) +- [Node.js](https://nodejs.org/en)، [yarn](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable)، اور [npx](https://www.npmjs.com/package/npx) انسٹال کیا (آپ کے dApp ماحول کے لیے) + +## ایک مقامی Ethereum ٹیسٹ نیٹ کو انسٹینٹیٹ کرنا {#instantiate-testnet} + +مقامی Ethereum ٹیسٹ نیٹ کو اسپن اپ کرنے کے لیے، چلائیں: + +```python +kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package +``` + +نوٹ: یہ کمانڈ `--enclave` فلیگ کا استعمال کرتے ہوئے آپ کے نیٹ ورک کا نام: \"local-eth-testnet\" رکھتا ہے۔ + +Kurtosis ان اقدامات کو پرنٹ کرے گا جو وہ ہدایات کی تشریح، توثیق، اور پھر عمل درآمد کے لیے پس پردہ اٹھا رہا ہے۔ آخر میں، آپ کو ایک آؤٹ پٹ نظر آنا چاہیے جو درج ذیل سے ملتا جلتا ہو: + +```python +INFO[2023-04-04T18:09:44-04:00] ====================================================== +INFO[2023-04-04T18:09:44-04:00] || Created enclave: local-eth-testnet || +INFO[2023-04-04T18:09:44-04:00] ====================================================== +Name: local-eth-testnet +UUID: 39372d756ae8 +Status: RUNNING +Creation Time: Tue, 04 Apr 2023 18:09:03 EDT + +========================================= Files Artifacts ========================================= +UUID Name +d4085a064230 cl-genesis-data +1c62cb792e4c el-genesis-data +bd60489b73a7 genesis-generation-config-cl +b2e593fe5228 genesis-generation-config-el +d552a54acf78 geth-prefunded-keys +5f7e661eb838 prysm-password +054e7338bb59 validator-keystore-0 + +========================================== User Services ========================================== +UUID Name Ports Status +e20f129ee0c5 cl-client-0-beacon http: 4000/tcp -> RUNNING + metrics: 5054/tcp -> + tcp-discovery: 9000/tcp -> 127.0.0.1:54263 + udp-discovery: 9000/udp -> 127.0.0.1:60470 +a8b6c926cdb4 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:54267 RUNNING + metrics: 5064/tcp -> +d7b802f623e8 el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:54253 RUNNING + rpc: 8545/tcp -> 127.0.0.1:54251 + tcp-discovery: 30303/tcp -> 127.0.0.1:54254 + udp-discovery: 30303/udp -> 127.0.0.1:53834 + ws: 8546/tcp -> 127.0.0.1:54252 +514a829c0a84 prelaunch-data-generator-1680646157905431468 STOPPED +62bd62d0aa7a prelaunch-data-generator-1680646157915424301 STOPPED +05e9619e0e90 prelaunch-data-generator-1680646157922872635 STOPPED + +``` + +مبارک ہو! آپ نے Docker پر ایک مقامی Ethereum ٹیسٹ نیٹ کو انسٹینٹیٹ کرنے کے لیے Kurtosis کا استعمال کیا، جس میں ایک CL (`lighthouse`) اور EL کلائنٹ (`geth`) ہے۔ + +### جائزہ {#review-instantiate-testnet} + +اس سیکشن میں، آپ نے ایک کمانڈ چلائی جس نے Kurtosis کو ہدایت دی کہ وہ Kurtosis [Enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/) کے اندر ایک مقامی Ethereum ٹیسٹ نیٹ کو اسپن اپ کرنے کے لیے GitHub پر دور سے میزبان [`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) کا استعمال کرے۔ اپنے انکلیو کے اندر، آپ کو \"فائل آرٹفیکٹس\" اور \"یوزر سروسز\" دونوں ملیں گے۔ + +آپ کے انکلیو میں موجود [فائل آرٹفیکٹس](https://docs.kurtosis.com/advanced-concepts/files-artifacts/) میں EL اور CL کلائنٹس کو بوٹسٹریپ کرنے کے لیے تیار اور استعمال ہونے والا تمام ڈیٹا شامل ہے۔ یہ ڈیٹا `prelaunch-data-generator` سروس کا استعمال کرتے ہوئے بنایا گیا تھا جو اس [ڈاکر امیج](https://github.com/ethpandaops/ethereum-genesis-generator) سے بنائی گئی ہے۔ + +یوزر سروسز آپ کے انکلیو میں کام کرنے والی تمام کنٹینرائزڈ سروسز کو ظاہر کرتی ہیں۔ آپ دیکھیں گے کہ ایک واحد نوڈ بنایا گیا ہے، جس میں ایک EL کلائنٹ اور ایک CL کلائنٹ دونوں شامل ہیں۔ + +## اپنے dApp ڈیولپمنٹ ماحول کو مقامی Ethereum ٹیسٹ نیٹ سے جوڑیں {#connect-your-dapp} + +### dApp ڈیولپمنٹ ماحول سیٹ اپ کریں {#set-up-dapp-env} + +اب جب کہ آپ کے پاس ایک چلتا ہوا مقامی ٹیسٹ نیٹ ہے، آپ اپنے dApp ڈیولپمنٹ ماحول کو اپنے مقامی ٹیسٹ نیٹ کو استعمال کرنے کے لیے جوڑ سکتے ہیں۔ اس گائیڈ میں آپ کے مقامی ٹیسٹ نیٹ پر بلیک جیک dApp کو ڈیپلائے کرنے کے لیے Hardhat فریم ورک کا استعمال کیا جائے گا۔ + +اپنے dApp ڈیولپمنٹ ماحول کو سیٹ اپ کرنے کے لیے، اس ریپوزٹری کو کلون کریں جس میں ہمارا نمونہ dApp ہے اور اس کی انحصاریوں کو انسٹال کریں، چلائیں: + +```python +git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn +``` + +یہاں استعمال ہونے والا [smart-contract-example](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example) فولڈر [Hardhat](https://hardhat.org/) فریم ورک استعمال کرنے والے dApp ڈیولپر کے لیے عام سیٹ اپ پر مشتمل ہے: + +- [`contracts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/contracts) میں بلیک جیک dApp کے لیے کچھ سادہ اسمارٹ کنٹریکٹس شامل ہیں۔ +- [`scripts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/scripts) میں آپ کے مقامی Ethereum نیٹ ورک پر ٹوکن کنٹریکٹ ڈیپلائے کرنے کے لیے ایک اسکرپٹ شامل ہے۔ +- [`test/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/test) میں آپ کے ٹوکن کنٹریکٹ کے لیے ایک سادہ .js ٹیسٹ شامل ہے تاکہ اس بات کی تصدیق کی جا سکے کہ ہمارے بلیک جیک dApp میں ہر کھلاڑی کے لیے 1000 منٹ کیے گئے ہیں۔ +- [`hardhat.config.ts`](https://github.com/kurtosis-tech/awesome-kurtosis/blob/main/smart-contract-example/hardhat.config.ts) آپ کے Hardhat سیٹ اپ کو کنفیگر کرتا ہے + +### مقامی ٹیسٹ نیٹ استعمال کرنے کے لیے Hardhat کو کنفیگر کریں {#configure-hardhat} + +اپنے dApp ڈیولپمنٹ ماحول کے سیٹ اپ کے ساتھ، اب آپ Kurtosis کا استعمال کرتے ہوئے تیار کردہ مقامی Ethereum ٹیسٹ نیٹ کو استعمال کرنے کے لیے Hardhat کو جوڑیں گے۔ اسے پورا کرنے کے لیے، اپنی `hardhat.config.ts` کنفیگ فائل میں `localnet` سٹرکٹ میں `<$YOUR_PORT>` کو کسی بھی `el-client-` سروس سے rpc uri آؤٹ پٹ کے پورٹ سے بدل دیں۔ اس نمونہ کیس میں، پورٹ `64248` ہوگا۔ آپ کا پورٹ مختلف ہوگا۔ + +`hardhat.config.ts` میں مثال: + +```js +localnet: { +url: 'http://127.0.0.1:<$YOUR_PORT>',// TODO: $YOUR_PORT کو ETH نیٹ ورک KURTOSIS پیکیج کے ذریعہ تیار کردہ نوڈ URI کے پورٹ سے تبدیل کریں + +// یہ eth-network-package کے ذریعہ بنائے گئے پہلے سے فنڈ شدہ ٹیسٹ اکاؤنٹس سے وابستہ پرائیویٹ کیز ہیں +// +accounts: [ + "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2", + "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567", + "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31", + "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35", + "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f", + "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6", + ], +}, +``` + +ایک بار جب آپ اپنی فائل محفوظ کر لیتے ہیں، تو آپ کا Hardhat dApp ڈیولپمنٹ ماحول اب آپ کے مقامی Ethereum ٹیسٹ نیٹ سے جڑ جاتا ہے! آپ یہ چلا کر تصدیق کر سکتے ہیں کہ آپ کا ٹیسٹ نیٹ کام کر رہا ہے: + +```python +npx hardhat balances --network localnet +``` + +آؤٹ پٹ کچھ اس طرح نظر آنا چاہئے: + +```python +0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000 +0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000 +0xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000 +0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000 +0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000 +0x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000 +``` + +اس سے تصدیق ہوتی ہے کہ Hardhat آپ کے مقامی ٹیسٹ نیٹ کا استعمال کر رہا ہے اور `eth-network-package` کے ذریعہ بنائے گئے پہلے سے فنڈ شدہ اکاؤنٹس کا پتہ لگاتا ہے۔ + +### مقامی طور پر اپنے dApp کو ڈیپلائے اور ٹیسٹ کریں {#deploy-and-test-dapp} + +dApp ڈیولپمنٹ ماحول کے مقامی Ethereum ٹیسٹ نیٹ سے مکمل طور پر منسلک ہونے کے ساتھ، اب آپ مقامی ٹیسٹ نیٹ کا استعمال کرتے ہوئے اپنے dApp کے خلاف ڈیولپمنٹ اور ٹیسٹنگ ورک فلو چلا سکتے ہیں۔ + +`ChipToken.sol` اسمارٹ کنٹریکٹ کو مقامی پروٹو ٹائپنگ اور ڈیولپمنٹ کے لیے کمپائل اور ڈیپلائے کرنے کے لیے، چلائیں: + +```python +npx hardhat compile +npx hardhat run scripts/deploy.ts --network localnet +``` + +آؤٹ پٹ کچھ اس طرح نظر آنا چاہئے: + +```python +ChipToken ڈیپلائے کیا گیا: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d +``` + +اب اپنے مقامی dApp کے خلاف `simple.js` ٹیسٹ چلانے کی کوشش کریں تاکہ اس بات کی تصدیق کی جا سکے کہ ہمارے بلیک جیک dApp میں ہر کھلاڑی کے لیے 1000 منٹ کیے گئے ہیں: + +آؤٹ پٹ کچھ اس طرح نظر آنا چاہئے: + +```python +npx hardhat test --network localnet +``` + +آؤٹ پٹ کچھ اس طرح نظر آنا چاہئے: + +```python +ChipToken + mint + ✔ should mint 1000 chips for PLAYER ONE + + 1 passing (654ms) +``` + +### جائزہ {#review-dapp-workflows} + +اس مقام پر، آپ نے اب ایک dApp ڈیولپمنٹ ماحول سیٹ اپ کیا ہے، اسے Kurtosis کے ذریعہ بنائے گئے مقامی Ethereum نیٹ ورک سے جوڑا ہے، اور اپنے dApp کے خلاف ایک سادہ ٹیسٹ کمپائل، ڈیپلائے، اور چلایا ہے۔ + +اب آئیے دریافت کریں کہ آپ مختلف نیٹ ورک کنفیگریشنز کے تحت ہمارے dApps کی جانچ کے لیے بنیادی نیٹ ورک کو کیسے کنفیگر کر سکتے ہیں۔ + +## مقامی Ethereum ٹیسٹ نیٹ کو کنفیگر کرنا {#configure-testnet} + +### کلائنٹ کنفیگریشنز اور نوڈس کی تعداد کو تبدیل کرنا {#configure-client-config-and-num-nodes} + +آپ کا مقامی Ethereum ٹیسٹ نیٹ مختلف EL اور CL کلائنٹ جوڑوں کے ساتھ ساتھ نوڈس کی مختلف تعداد کو استعمال کرنے کے لیے کنفیگر کیا جا سکتا ہے، اس منظر نامے اور مخصوص نیٹ ورک کنفیگریشن پر منحصر ہے جسے آپ تیار یا ٹیسٹ کرنا چاہتے ہیں۔ اس کا مطلب ہے کہ، ایک بار سیٹ اپ ہونے کے بعد، آپ ایک حسب ضرورت مقامی ٹیسٹ نیٹ کو اسپن اپ کر سکتے ہیں اور اسے وہی ورک فلو (ڈیپلائمنٹ، ٹیسٹ، وغیرہ) چلانے کے لیے استعمال کر سکتے ہیں۔ مختلف نیٹ ورک کنفیگریشنز کے تحت یہ یقینی بنانے کے لیے کہ سب کچھ توقع کے مطابق کام کرتا ہے۔ دیگر پیرامیٹرز کے بارے میں مزید جاننے کے لیے جن میں آپ ترمیم کر سکتے ہیں، اس لنک پر جائیں۔ + +اسے آزمائیں! آپ JSON فائل کے ذریعے `eth-network-package` کو مختلف کنفیگریشن آپشنز پاس کر سکتے ہیں۔ یہ نیٹ ورک پیرامیٹرز JSON فائل وہ مخصوص کنفیگریشنز فراہم کرتی ہے جو Kurtosis مقامی Ethereum نیٹ ورک کو سیٹ اپ کرنے کے لیے استعمال کرے گا۔ + +ڈیفالٹ کنفیگریشن فائل لیں اور اسے مختلف EL/CL جوڑوں کے ساتھ دو نوڈس کو اسپن اپ کرنے کے لیے ترمیم کریں: + +- نوڈ 1 `geth`/`lighthouse` کے ساتھ +- نوڈ 2 `geth`/`lodestar` کے ساتھ +- نوڈ 3 `geth`/`teku` کے ساتھ + +یہ کنفیگریشن آپ کے dApp کی جانچ کے لیے Ethereum نوڈ کے نفاذ کا ایک متضاد نیٹ ورک بناتی ہے۔ آپ کی کنفیگریشن فائل اب اس طرح نظر آنی چاہئے: + +```yaml +{ + "participants": + [ + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "lighthouse", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "lodestar", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "teku", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + ], + "network_params": + { + "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete", + "num_validator_keys_per_node": 64, + "network_id": "3151908", + "deposit_contract_address": "0x4242424242424242424242424242424242424242", + "seconds_per_slot": 12, + "genesis_delay": 120, + "capella_fork_epoch": 5, + }, +} +``` + +ہر `participants` سٹرکٹ نیٹ ورک میں ایک نوڈ سے مطابقت رکھتا ہے، لہذا 3 `participants` سٹرکٹس Kurtosis کو آپ کے نیٹ ورک میں 3 نوڈس کو اسپن اپ کرنے کے لیے کہیں گے۔ ہر `participants` سٹرکٹ آپ کو اس مخصوص نوڈ کے لیے استعمال ہونے والے EL اور CL جوڑے کی وضاحت کرنے کی اجازت دے گا۔ + +`network_params` سٹرکٹ نیٹ ورک کی ترتیبات کو کنفیگر کرتا ہے جو ہر نوڈ کے لیے جینیسس فائلیں بنانے کے ساتھ ساتھ دیگر ترتیبات جیسے نیٹ ورک کے فی سلاٹ سیکنڈز کے لیے استعمال ہوتی ہیں۔ + +اپنی ترمیم شدہ پیرامیٹرز فائل کو کسی بھی ڈائرکٹری میں محفوظ کریں جس میں آپ چاہیں (نیچے دی گئی مثال میں، اسے ڈیسک ٹاپ پر محفوظ کیا گیا ہے) اور پھر اسے چلا کر اپنا Kurtosis پیکیج چلائیں: + +```python +kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package "$(cat ~/eth-network-params.json)" +``` + +نوٹ: `kurtosis clean -a` کمانڈ یہاں Kurtosis کو ہدایت دینے کے لیے استعمال کی جاتی ہے کہ وہ پرانے ٹیسٹ نیٹ اور اس کے مواد کو نیا شروع کرنے سے پہلے تباہ کر دے۔ + +ایک بار پھر، Kurtosis تھوڑی دیر کے لیے کام کرے گا اور انفرادی اقدامات کو پرنٹ کرے گا جو ہو رہے ہیں۔ آخر کار، آؤٹ پٹ کچھ اس طرح نظر آنا چاہئے: + +```python +Starlark code successfully run. No output was returned. +INFO[2023-04-07T11:43:16-04:00] ========================================================== +INFO[2023-04-07T11:43:16-04:00] || Created enclave: local-eth-testnet || +INFO[2023-04-07T11:43:16-04:00] ========================================================== +Name: local-eth-testnet +UUID: bef8c192008e +Status: RUNNING +Creation Time: Fri, 07 Apr 2023 11:41:58 EDT + +========================================= Files Artifacts ========================================= +UUID Name +cc495a8e364a cl-genesis-data +7033fcdb5471 el-genesis-data +a3aef43fc738 genesis-generation-config-cl +8e968005fc9d genesis-generation-config-el +3182cca9d3cd geth-prefunded-keys +8421166e234f prysm-password +d9e6e8d44d99 validator-keystore-0 +23f5ba517394 validator-keystore-1 +4d28dea40b5c validator-keystore-2 + +========================================== User Services ========================================== +UUID Name Ports Status +485e6fde55ae cl-client-0-beacon http: 4000/tcp -> http://127.0.0.1:65010 RUNNING + metrics: 5054/tcp -> http://127.0.0.1:65011 + tcp-discovery: 9000/tcp -> 127.0.0.1:65012 + udp-discovery: 9000/udp -> 127.0.0.1:54455 +73739bd158b2 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:65016 RUNNING + metrics: 5064/tcp -> http://127.0.0.1:65017 +1b0a233cd011 cl-client-1-beacon http: 4000/tcp -> 127.0.0.1:65021 RUNNING + metrics: 8008/tcp -> 127.0.0.1:65023 + tcp-discovery: 9000/tcp -> 127.0.0.1:65024 + udp-discovery: 9000/udp -> 127.0.0.1:56031 + validator-metrics: 5064/tcp -> 127.0.0.1:65022 +949b8220cd53 cl-client-1-validator http: 4000/tcp -> 127.0.0.1:65028 RUNNING + metrics: 8008/tcp -> 127.0.0.1:65030 + tcp-discovery: 9000/tcp -> 127.0.0.1:65031 + udp-discovery: 9000/udp -> 127.0.0.1:60784 + validator-metrics: 5064/tcp -> 127.0.0.1:65029 +c34417bea5fa cl-client-2 http: 4000/tcp -> 127.0.0.1:65037 RUNNING + metrics: 8008/tcp -> 127.0.0.1:65035 + tcp-discovery: 9000/tcp -> 127.0.0.1:65036 + udp-discovery: 9000/udp -> 127.0.0.1:63581 +e19738e6329d el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:64986 RUNNING + rpc: 8545/tcp -> 127.0.0.1:64988 + tcp-discovery: 30303/tcp -> 127.0.0.1:64987 + udp-discovery: 30303/udp -> 127.0.0.1:55706 + ws: 8546/tcp -> 127.0.0.1:64989 +e904687449d9 el-client-1 engine-rpc: 8551/tcp -> 127.0.0.1:64993 RUNNING + rpc: 8545/tcp -> 127.0.0.1:64995 + tcp-discovery: 30303/tcp -> 127.0.0.1:64994 + udp-discovery: 30303/udp -> 127.0.0.1:58096 + ws: 8546/tcp -> 127.0.0.1:64996 +ad6f401126fa el-client-2 engine-rpc: 8551/tcp -> 127.0.0.1:65003 RUNNING + rpc: 8545/tcp -> 127.0.0.1:65001 + tcp-discovery: 30303/tcp -> 127.0.0.1:65000 + udp-discovery: 30303/udp -> 127.0.0.1:57269 + ws: 8546/tcp -> 127.0.0.1:65002 +12d04a9dbb69 prelaunch-data-generator-1680882122181135513 STOPPED +5b45f9c0504b prelaunch-data-generator-1680882122192182847 STOPPED +3d4aaa75e218 prelaunch-data-generator-1680882122201668972 STOPPED +``` + +مبارک ہو! آپ نے کامیابی سے اپنے مقامی ٹیسٹ نیٹ کو 1 کے بجائے 3 نوڈس رکھنے کے لیے کنفیگر کر لیا ہے۔ اپنے dApp (ڈیپلائے اور ٹیسٹ) کے خلاف وہی ورک فلو چلانے کے لیے جو آپ نے پہلے کیے تھے، وہی آپریشنز انجام دیں جو ہم نے پہلے `<$YOUR_PORT>` کو اپنی `hardhat.config.ts` کنفیگ فائل میں `localnet` سٹرکٹ میں اپنے نئے، 3-نوڈ مقامی ٹیسٹ نیٹ میں کسی بھی `el-client-` سروس سے rpc uri آؤٹ پٹ کے پورٹ سے تبدیل کر کے کیے تھے۔ + +## نتیجہ {#conclusion} + +اور بس! اس مختصر گائیڈ کا خلاصہ کرنے کے لیے، آپ نے: + +- Kurtosis کا استعمال کرتے ہوئے Docker پر ایک مقامی Ethereum ٹیسٹ نیٹ بنایا +- اپنے مقامی dApp ڈیولپمنٹ ماحول کو مقامی Ethereum نیٹ ورک سے جوڑا +- مقامی Ethereum نیٹ ورک پر ایک dApp ڈیپلائے کیا اور اس کے خلاف ایک سادہ ٹیسٹ چلایا +- بنیادی Ethereum نیٹ ورک کو 3 نوڈس رکھنے کے لیے کنفیگر کیا + +ہم آپ سے یہ سننا پسند کریں گے کہ آپ کے لیے کیا اچھا رہا، کیا بہتر کیا جا سکتا ہے، یا آپ کے کسی بھی سوال کا جواب دینا۔ [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose) کے ذریعے رابطہ کرنے یا [ہمیں ای میل](mailto:feedback@kurtosistech.com) کرنے میں ہچکچاہٹ محسوس نہ کریں! + +### دیگر مثالیں اور گائیڈز {#other-examples-guides} + +ہم آپ کو ہمارے [کوئیک اسٹارٹ](https://docs.kurtosis.com/quickstart) (جہاں آپ سب سے اوپر ایک Postgres ڈیٹا بیس اور API بنائیں گے) اور ہماری [awesome-kurtosis ریپوزٹری](https://github.com/kurtosis-tech/awesome-kurtosis) میں ہماری دیگر مثالیں دیکھنے کی ترغیب دیتے ہیں جہاں آپ کو کچھ بہترین مثالیں ملیں گی، بشمول ان کے لیے پیکیجز: + +- [اسی مقامی Ethereum ٹیسٹ نیٹ کو اسپن اپ کرنا](https://github.com/kurtosis-tech/eth2-package)، لیکن اضافی خدمات کے ساتھ جیسے ٹرانزیکشن اسپامر (ٹرانزیکشنز کی تقلید کے لیے)، ایک فورک مانیٹر، اور ایک منسلک Grafana اور Prometheus مثال۔ +- اسی مقامی Ethereum نیٹ ورک کے خلاف [سب-نیٹ ورکنگ ٹیسٹ](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/ethereum-network-partition-test) انجام دینا۔ diff --git a/public/content/translations/ur/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md b/public/content/translations/ur/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md new file mode 100644 index 00000000000..ab602aef324 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md @@ -0,0 +1,144 @@ +--- +title: "کنٹریکٹ سائز کی حد سے نمٹنے کے لیے کنٹریکٹس کو چھوٹا کرنا" +description: "آپ اپنے اسمارٹ کنٹریکٹس کو بہت بڑا ہونے سے روکنے کے لیے کیا کر سکتے ہیں؟" +author: Markus Waas +lang: ur-in +tags: [ "solidity", "اسمارٹ معاہدات", "اسٹوریج" ] +skill: intermediate +published: 2020-06-26 +source: soliditydeveloper.com +sourceUrl: https://soliditydeveloper.com/max-contract-size +--- + +## ایک حد کیوں ہے؟ {#why-is-there-a-limit} + +[22 نومبر، 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/) کو Spurious Dragon ہارڈ-فورک نے [EIP-170](https://eips.ethereum.org/EIPS/eip-170) متعارف کرایا جس نے 24.576 kb کی اسمارٹ کنٹریکٹ سائز کی حد شامل کی۔ ایک Solidity ڈویلپر کے طور پر آپ کے لیے اس کا مطلب یہ ہے کہ جب آپ اپنے کنٹریکٹ میں زیادہ سے زیادہ فعالیت شامل کرتے ہیں، تو کسی وقت آپ حد تک پہنچ جائیں گے اور ڈیپلائے کرتے وقت آپ کو یہ خرابی نظر آئے گی: + +`انتباہ: کنٹریکٹ کوڈ کا سائز 24576 بائٹس سے زیادہ ہے (ایک حد جو Spurious Dragon میں متعارف کرائی گئی تھی)۔ یہ کنٹریکٹ شاید Mainnet پر ڈیپلائے نہ کیا جا سکے۔ آپٹیمائزر کو فعال کرنے پر غور کریں (کم "رنز" ویلیو کے ساتھ!)، ریورٹ اسٹرنگز کو بند کریں، یا لائبریریوں کا استعمال کریں۔` + +یہ حد ڈینائل-آف-سروس (DOS) حملوں کو روکنے کے لیے متعارف کرائی گئی تھی۔ گیس کے لحاظ سے کسی کنٹریکٹ پر کوئی بھی کال نسبتاً سستی ہوتی ہے۔ تاہم، ایتھیریم نوڈز کے لیے کنٹریکٹ کال کا اثر بلائے گئے کنٹریکٹ کوڈ کے سائز کے لحاظ سے غیر متناسب طور پر بڑھ جاتا ہے (ڈسک سے کوڈ پڑھنا، کوڈ کی پری-پروسیسنگ، مرکل پروف میں ڈیٹا شامل کرنا)۔ جب بھی آپ کے پاس ایسی صورتحال ہوتی ہے جہاں حملہ آور کو دوسروں کے لیے بہت زیادہ کام کرنے کے لیے کم وسائل کی ضرورت ہوتی ہے، تو آپ کو DOS حملوں کا امکان ہوتا ہے۔ + +اصل میں یہ کم مسئلہ تھا کیونکہ ایک قدرتی کنٹریکٹ سائز کی حد بلاک گیس کی حد ہے۔ ظاہر ہے، ایک کنٹریکٹ کو ایک ٹرانزیکشن کے اندر ڈیپلائے کیا جانا چاہیے جس میں کنٹریکٹ کا تمام بائٹ کوڈ موجود ہو۔ اگر آپ صرف اس ایک ٹرانزیکشن کو ایک بلاک میں شامل کرتے ہیں، تو آپ وہ تمام گیس استعمال کر سکتے ہیں، لیکن یہ لامحدود نہیں ہے۔ [London Upgrade](/ethereum-forks/#london) کے بعد سے، بلاک گیس کی حد نیٹ ورک کی طلب کے لحاظ سے 15M اور 30M یونٹس کے درمیان مختلف ہو سکتی ہے۔ + +ذیل میں ہم ان کے ممکنہ اثرات کے مطابق ترتیب دیے گئے کچھ طریقوں پر غور کریں گے۔ اسے وزن کم کرنے کی اصطلاح میں سوچیں۔ کسی کے لیے اپنے ہدف کے وزن (ہمارے معاملے میں 24kb) تک پہنچنے کے لیے بہترین حکمت عملی یہ ہے کہ پہلے بڑے اثر والے طریقوں پر توجہ دی جائے۔ زیادہ تر معاملات میں صرف اپنی خوراک کو ٹھیک کرنے سے آپ وہاں پہنچ جائیں گے، لیکن بعض اوقات آپ کو تھوڑا اور کرنے کی ضرورت ہوتی ہے۔ پھر آپ کچھ ورزش (درمیانے اثر) یا سپلیمنٹس (چھوٹا اثر) بھی شامل کر سکتے ہیں۔ + +## بڑا اثر {#big-impact} + +### اپنے کنٹریکٹس کو الگ کریں {#separate-your-contracts} + +یہ ہمیشہ آپ کا پہلا طریقہ ہونا چاہیے۔ آپ کنٹریکٹ کو متعدد چھوٹے کنٹریکٹس میں کیسے الگ کر سکتے ہیں؟ یہ عام طور پر آپ کو اپنے کنٹریکٹس کے لیے ایک اچھا آرکیٹیکچر تیار کرنے پر مجبور کرتا ہے۔ کوڈ کی پڑھنے کی اہلیت کے نقطہ نظر سے چھوٹے کنٹریکٹس کو ہمیشہ ترجیح دی جاتی ہے۔ کنٹریکٹس کو تقسیم کرنے کے لیے، اپنے آپ سے پوچھیں: + +- کون سے فنکشنز ایک ساتھ ہیں؟ فنکشنز کا ہر سیٹ اپنے کنٹریکٹ میں بہترین ہو سکتا ہے۔ +- کن فنکشنز کو کنٹریکٹ اسٹیٹ پڑھنے کی ضرورت نہیں ہے یا صرف اسٹیٹ کے ایک مخصوص سب سیٹ کی ضرورت ہے؟ +- کیا آپ اسٹوریج اور فعالیت کو تقسیم کر سکتے ہیں؟ + +### لائبریریاں {#libraries} + +فعالیت کے کوڈ کو اسٹوریج سے دور منتقل کرنے کا ایک آسان طریقہ [لائبریری](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries) کا استعمال ہے۔ لائبریری کے فنکشنز کو اندرونی قرار نہ دیں کیونکہ یہ کمپائلیشن کے دوران براہ راست [کنٹریکٹ میں شامل](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking) ہو جائیں گے۔ لیکن اگر آپ پبلک فنکشنز استعمال کرتے ہیں، تو وہ درحقیقت ایک الگ لائبریری کنٹریکٹ میں ہوں گے۔ لائبریریوں کے استعمال کو مزید آسان بنانے کے لیے [using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for) پر غور کریں۔ + +### پراکسیز {#proxies} + +ایک مزید جدید حکمت عملی پراکسی سسٹم ہوگی۔ لائبریریاں پس پردہ `DELEGATECALL` کا استعمال کرتی ہیں جو کال کرنے والے کنٹریکٹ کی اسٹیٹ کے ساتھ دوسرے کنٹریکٹ کے فنکشن کو محض انجام دیتی ہیں۔ پراکسی سسٹمز کے بارے میں مزید جاننے کے لیے [یہ بلاگ پوسٹ](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2) دیکھیں۔ وہ آپ کو مزید فعالیت فراہم کرتے ہیں، مثال کے طور پر، وہ اپ گریڈ کی اہلیت کو فعال کرتے ہیں، لیکن وہ بہت زیادہ پیچیدگی بھی شامل کرتے ہیں۔ میں انہیں صرف کنٹریکٹ کے سائز کو کم کرنے کے لیے شامل نہیں کروں گا جب تک کہ کسی بھی وجہ سے یہ آپ کا واحد آپشن نہ ہو۔ + +## درمیانہ اثر {#medium-impact} + +### فنکشنز کو ہٹائیں {#remove-functions} + +یہ تو ظاہر ہونا چاہیے۔ فنکشنز کنٹریکٹ کا سائز کافی حد تک بڑھا دیتے ہیں۔ + +- **بیرونی**: اکثر ہم سہولت کی وجوہات کی بنا پر بہت سے ویو فنکشنز شامل کرتے ہیں۔ یہ بالکل ٹھیک ہے جب تک کہ آپ سائز کی حد تک نہ پہنچ جائیں۔ پھر آپ کو واقعی ان تمام فنکشنز کو ہٹانے کے بارے میں سوچنا چاہیے سوائے ان کے جو بالکل ضروری ہیں۔ +- **اندرونی**: آپ اندرونی/پرائیویٹ فنکشنز کو بھی ہٹا سکتے ہیں اور کوڈ کو سیدھا ان لائن کر سکتے ہیں جب تک کہ فنکشن کو صرف ایک بار کال کیا جائے۔ + +### اضافی متغیرات سے بچیں {#avoid-additional-variables} + +```solidity +function get(uint id) returns (address,address) { + MyStruct memory myStruct = myStructs[id]; + return (myStruct.addr1, myStruct.addr2); +} +``` + +```solidity +function get(uint id) returns (address,address) { + return (myStructs[id].addr1, myStructs[id].addr2); +} +``` + +اس طرح کی ایک سادہ سی تبدیلی **0.28kb** کا فرق پیدا کرتی ہے۔ امکان ہے کہ آپ اپنے کنٹریکٹس میں بہت سی ملتی جلتی صورتحال تلاش کر سکتے ہیں اور وہ واقعی ایک بڑی مقدار میں اضافہ کر سکتی ہیں۔ + +### خرابی کے پیغام کو مختصر کریں {#shorten-error-message} + +طویل ریورٹ پیغامات اور خاص طور پر بہت سے مختلف ریورٹ پیغامات کنٹریکٹ کو پھلا سکتے ہیں۔ اس کے بجائے مختصر ایرر کوڈز کا استعمال کریں اور انہیں اپنے کنٹریکٹ میں ڈی کوڈ کریں۔ ایک لمبا پیغام بہت چھوٹا ہو سکتا ہے: + +```solidity +require(msg.sender == owner, "اس فنکشن کو صرف اس کنٹریکٹ کا مالک کال کر سکتا ہے"); +``` + +```solidity +require(msg.sender == owner, "OW1"); +``` + +### خرابی کے پیغامات کے بجائے کسٹم ایررز کا استعمال کریں + +کسٹم ایررز [Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/) میں متعارف کرائے گئے ہیں۔ وہ آپ کے کنٹریکٹس کا سائز کم کرنے کا ایک بہترین طریقہ ہیں، کیونکہ وہ ABI-انکوڈڈ سلیکٹرز کے طور پر ہوتے ہیں (جیسے فنکشنز ہوتے ہیں)۔ + +```solidity +error Unauthorized(); + +if (msg.sender != owner) { + revert Unauthorized(); +} +``` + +### آپٹیمائزر میں کم رن ویلیو پر غور کریں {#consider-a-low-run-value-in-the-optimizer} + +آپ آپٹیمائزر کی سیٹنگز کو بھی تبدیل کر سکتے ہیں۔ 200 کی ڈیفالٹ ویلیو کا مطلب ہے کہ یہ بائٹ کوڈ کو اس طرح آپٹیمائز کرنے کی کوشش کر رہا ہے جیسے کسی فنکشن کو 200 بار کال کیا گیا ہو۔ اگر آپ اسے 1 میں تبدیل کرتے ہیں، تو آپ بنیادی طور پر آپٹیمائزر کو ہر فنکشن کو صرف ایک بار چلانے کے معاملے کے لیے آپٹیمائز کرنے کے لیے کہتے ہیں۔ صرف ایک بار چلنے کے لیے ایک آپٹمائزڈ فنکشن کا مطلب ہے کہ یہ خود ڈیپلائمنٹ کے لیے آپٹمائزڈ ہے۔ آگاہ رہیں کہ **اس سے فنکشنز کو چلانے کے لیے [گیس کے اخراجات](/developers/docs/gas/) بڑھ جاتے ہیں**، اس لیے ہو سکتا ہے کہ آپ ایسا نہ کرنا چاہیں۔ + +## چھوٹا اثر {#small-impact} + +### فنکشنز میں اسٹرکٹس کو پاس کرنے سے گریز کریں {#avoid-passing-structs-to-functions} + +اگر آپ [ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2) استعمال کر رہے ہیں، تو یہ کسی فنکشن میں اسٹرکٹس کو پاس نہ کرنے میں مدد کر سکتا ہے۔ پیرامیٹر کو بطور اسٹرکٹ پاس کرنے کے بجائے، مطلوبہ پیرامیٹرز کو براہ راست پاس کریں۔ اس مثال میں ہم نے مزید **0.1kb** بچائے۔ + +```solidity +function get(uint id) returns (address,address) { + return _get(myStruct); +} + +function _get(MyStruct memory myStruct) private view returns(address,address) { + return (myStruct.addr1, myStruct.addr2); +} +``` + +```solidity +function get(uint id) returns(address,address) { + return _get(myStructs[id].addr1, myStructs[id].addr2); +} + +function _get(address addr1, address addr2) private view returns(address,address) { + return (addr1, addr2); +} +``` + +### فنکشنز اور متغیرات کے لیے درست مرئیت کا اعلان کریں {#declare-correct-visibility-for-functions-and-variables} + +- فنکشنز یا متغیرات جو صرف باہر سے کال کیے جاتے ہیں؟ انہیں `public` کی بجائے `external` کے طور پر اعلان کریں۔ +- فنکشنز یا متغیرات جو صرف کنٹریکٹ کے اندر سے کال کیے جاتے ہیں؟ انہیں `public` کی بجائے `private` یا `internal` کے طور پر اعلان کریں۔ + +### موڈیفائرز کو ہٹائیں {#remove-modifiers} + +موڈیفائرز، خاص طور پر جب بہت زیادہ استعمال کیے جائیں، کنٹریکٹ کے سائز پر اہم اثر ڈال سکتے ہیں۔ انہیں ہٹانے اور اس کے بجائے فنکشنز استعمال کرنے پر غور کریں۔ + +```solidity +modifier checkStuff() {} + +function doSomething() checkStuff {} +``` + +```solidity +function checkStuff() private {} + +function doSomething() { checkStuff(); } +``` + +یہ ٹپس آپ کو کنٹریکٹ کا سائز نمایاں طور پر کم کرنے میں مدد کریں گی۔ ایک بار پھر، میں اس بات پر کافی زور نہیں دے سکتا، سب سے بڑے اثر کے لیے اگر ممکن ہو تو ہمیشہ کنٹریکٹس کو تقسیم کرنے پر توجہ دیں۔ diff --git a/public/content/translations/ur/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/ur/developers/tutorials/eip-1271-smart-contract-signatures/index.md new file mode 100644 index 00000000000..c4308fd5b46 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/eip-1271-smart-contract-signatures/index.md @@ -0,0 +1,123 @@ +--- +title: "EIP-1271: اسمارٹ کنٹریکٹ دستخط پر دستخط کرنا اور ان کی توثیق کرنا" +description: "EIP-1271 کے ساتھ اسمارٹ کنٹریکٹ دستخط کی تخلیق اور توثیق کا ایک جائزہ۔ ہم اسمارٹ کنٹریکٹ ڈیولپرز کے لیے ایک ٹھوس مثال فراہم کرنے کے لیے Safe (پہلے Gnosis Safe) میں استعمال ہونے والے EIP-1271 نفاذ کا بھی جائزہ لیتے ہیں۔" +author: Nathan H. Leung +lang: ur-in +tags: [ "eip-1271", "اسمارٹ معاہدات", "توثیق", "دستخط" ] +skill: intermediate +published: 2023-01-12 +--- + +[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) معیار اسمارٹ کنٹریکٹس کو دستخطوں کی توثیق کرنے کی اجازت دیتا ہے۔ + +اس ٹیوٹوریل میں، ہم ڈیجیٹل دستخطوں، EIP-1271 کے پس منظر، اور [Safe](https://safe.global/) (پہلے Gnosis Safe) کے ذریعے استعمال ہونے والے EIP-1271 کے مخصوص نفاذ کا ایک جائزہ دیتے ہیں۔ مجموعی طور پر، یہ آپ کے اپنے کنٹریکٹس میں EIP-1271 کو نافذ کرنے کے لیے ایک نقطہ آغاز کے طور پر کام کر سکتا ہے۔ + +## دستخط کیا ہے؟ + +اس تناظر میں، ایک دستخط (زیادہ واضح طور پر، ایک "ڈیجیٹل دستخط") ایک پیغام ہے جس کے ساتھ کسی قسم کا ثبوت ہوتا ہے کہ پیغام کسی مخصوص شخص/بھیجنے والے/ایڈریس سے آیا ہے۔ + +مثال کے طور پر، ایک ڈیجیٹل دستخط اس طرح نظر آ سکتا ہے: + +1. پیغام: "میں اپنے Ethereum والیٹ کے ساتھ اس ویب سائٹ پر لاگ ان کرنا چاہتا ہوں۔" +2. دستخط کنندہ: میرا ایڈریس `0x000…` ہے +3. ثبوت: یہاں کچھ ثبوت ہے کہ میں نے، `0x000…`، درحقیقت یہ پورا پیغام بنایا ہے (یہ عام طور پر کوئی کرپٹوگرافک چیز ہوتی ہے)۔ + +یہ نوٹ کرنا ضروری ہے کہ ڈیجیٹل دستخط میں "پیغام" اور "دستخط" دونوں شامل ہیں۔ + +کیوں؟ مثال کے طور پر، اگر آپ نے مجھے دستخط کرنے کے لیے ایک کنٹریکٹ دیا، اور پھر میں نے دستخط کا صفحہ کاٹ کر باقی کنٹریکٹ کے بغیر صرف اپنے دستخط آپ کو واپس کر دیے، تو کنٹریکٹ درست نہیں ہوگا۔ + +اسی طرح، ایک ڈیجیٹل دستخط کا متعلقہ پیغام کے بغیر کوئی مطلب نہیں ہے! + +## EIP-1271 کیوں موجود ہے؟ + +Ethereum پر مبنی بلاک چینز پر استعمال کے لیے ڈیجیٹل دستخط بنانے کے لیے، آپ کو عام طور پر ایک خفیہ پرائیویٹ کلید کی ضرورت ہوتی ہے جسے کوئی اور نہیں جانتا۔ یہی چیز آپ کے دستخط کو آپ کا بناتی ہے (خفیہ کلید کے علم کے بغیر کوئی اور وہی دستخط نہیں بنا سکتا)۔ + +آپ کے Ethereum اکاؤنٹ (یعنی، آپ کا بیرونی ملکیت والا اکاؤنٹ/EOA) کے ساتھ ایک پرائیویٹ کلید منسلک ہے، اور یہ وہ پرائیویٹ کلید ہے جو عام طور پر اس وقت استعمال ہوتی ہے جب کوئی ویب سائٹ یا ڈیپ آپ سے دستخط مانگتی ہے (مثال کے طور پر، "Ethereum کے ساتھ لاگ ان کریں" کے لیے)۔ + +ایک ایپ آپ کے بنائے ہوئے [دستخط کی توثیق](https://www.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum) ethers.js جیسی تھرڈ پارٹی لائبریری کا استعمال کرتے ہوئے [آپ کی پرائیویٹ کلید کو جانے بغیر](https://en.wikipedia.org/wiki/Public-key_cryptography) کر سکتی ہے اور اس بات پر یقین رکھ سکتی ہے کہ دستخط _آپ_ نے ہی بنایا تھا۔ + +> درحقیقت، چونکہ EOA ڈیجیٹل دستخط پبلک-کی کرپٹوگرافی کا استعمال کرتے ہیں، انہیں **آف چین** بنایا اور توثیق کیا جا سکتا ہے! گیس لیس DAO ووٹنگ اسی طرح کام کرتی ہے - آن چین ووٹ جمع کروانے کے بجائے، کرپٹوگرافک لائبریریوں کا استعمال کرتے ہوئے ڈیجیٹل دستخط آف چین بنائے اور ان کی توثیق کی جا سکتی ہے۔ + +جبکہ EOA اکاؤنٹس میں ایک پرائیویٹ کلید ہوتی ہے، اسمارٹ کنٹریکٹ اکاؤنٹس میں کسی بھی قسم کی پرائیویٹ یا خفیہ کلید نہیں ہوتی ہے (لہذا "Ethereum کے ساتھ لاگ ان کریں"، وغیرہ مقامی طور پر اسمارٹ کنٹریکٹ اکاؤنٹس کے ساتھ کام نہیں کر سکتے)۔ + +EIP-1271 جس مسئلے کو حل کرنا چاہتا ہے وہ یہ ہے: ہم کیسے بتا سکتے ہیں کہ اسمارٹ کنٹریکٹ کا دستخط درست ہے اگر اسمارٹ کنٹریکٹ میں کوئی "راز" نہیں ہے جسے وہ دستخط میں شامل کر سکے؟ + +## EIP-1271 کیسے کام کرتا ہے؟ + +اسمارٹ کنٹریکٹس میں پرائیویٹ کلیدیں نہیں ہوتیں جن کا استعمال پیغامات پر دستخط کرنے کے لیے کیا جا سکے۔ تو ہم کیسے بتا سکتے ہیں کہ دستخط اصلی ہے؟ + +ٹھیک ہے، ایک خیال یہ ہے کہ ہم صرف اسمارٹ کنٹریکٹ سے _پوچھ_ سکتے ہیں کہ کیا دستخط اصلی ہے! + +EIP-1271 جو کرتا ہے وہ یہ ہے کہ یہ اس خیال کو معیاری بناتا ہے کہ کسی اسمارٹ کنٹریکٹ سے "پوچھا جائے" کہ آیا دیا گیا دستخط درست ہے۔ + +EIP-1271 کو نافذ کرنے والے کنٹریکٹ میں `isValidSignature` نامی ایک فنکشن ہونا چاہیے جو ایک پیغام اور ایک دستخط لیتا ہے۔ کنٹریکٹ پھر کچھ توثیقی منطق چلا سکتا ہے (اسپیک یہاں کسی خاص چیز کو نافذ نہیں کرتا) اور پھر ایک قدر واپس کرتا ہے جو یہ بتاتا ہے کہ دستخط درست ہے یا نہیں۔ + +اگر `isValidSignature` ایک درست نتیجہ واپس کرتا ہے، تو یہ تقریباً کنٹریکٹ کے یہ کہنے کے مترادف ہے کہ "ہاں، میں اس دستخط + پیغام کو منظور کرتا ہوں!" + +### انٹرفیس + +یہاں EIP-1271 اسپیک میں عین مطابق انٹرفیس ہے (ہم ذیل میں `_hash` پیرامیٹر کے بارے میں بات کریں گے، لیکن ابھی کے لیے، اسے وہ پیغام سمجھیں جس کی توثیق کی جا رہی ہے): + +```jsx +pragma solidity ^0.5.0; + +contract ERC1271 { + + // bytes4(keccak256("isValidSignature(bytes32,bytes)") + bytes4 constant internal MAGICVALUE = 0x1626ba7e; + + /** + * @dev یہ واپس کرنا چاہئے کہ آیا فراہم کردہ دستخط فراہم کردہ ہیش کے لئے درست ہے + * @param _hash دستخط کیے جانے والے ڈیٹا کا ہیش + * @param _signature _hash سے وابستہ دستخط بائٹ ارے + * + * فنکشن کے پاس ہونے پر بائٹس4 میجک ویلیو 0x1626ba7e واپس کرنا لازمی ہے۔ + * اسٹیٹ میں ترمیم نہیں کرنی چاہئے (solc < 0.5 کے لیے STATICCALL کا استعمال کرتے ہوئے، solc > 0.5 کے لیے ویو موڈیفائر) + * بیرونی کالز کی اجازت ہونی چاہئے + */ + function isValidSignature( + bytes32 _hash, + bytes memory _signature) + public + view + returns (bytes4 magicValue); +} +``` + +## مثال EIP-1271 نفاذ: Safe + +کنٹریکٹس `isValidSignature` کو کئی طریقوں سے نافذ کر سکتے ہیں — اسپیک صرف عین مطابق نفاذ کے بارے میں زیادہ کچھ نہیں کہتا ہے۔ + +ایک قابل ذکر کنٹریکٹ جو EIP-1271 کو نافذ کرتا ہے وہ Safe ہے (پہلے Gnosis Safe)۔ + +Safe کے کوڈ میں، `isValidSignature` کو [نافذ کیا گیا ہے](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol) تاکہ دستخطوں کو [دو طریقوں سے](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support) بنایا اور توثیق کیا جا سکے: + +1. آن چین پیغامات + 1. تخلیق: ایک سیف مالک پیغام پر "دستخط" کرنے کے لیے ایک نیا سیف ٹرانزیکشن بناتا ہے، پیغام کو ٹرانزیکشن میں ڈیٹا کے طور پر منتقل کرتا ہے۔ ایک بار جب کافی مالکان ملٹی سگ تھریشولڈ تک پہنچنے کے لیے ٹرانزیکشن پر دستخط کر دیتے ہیں، تو ٹرانزیکشن کو براڈکاسٹ کیا جاتا ہے اور چلایا جاتا ہے۔ ٹرانزیکشن میں، ایک سیف فنکشن ہے جسے (`signMessage(bytes calldata _data)`) کہا جاتا ہے جو پیغام کو "منظور شدہ" پیغامات کی فہرست میں شامل کرتا ہے۔ + 2. توثیق: Safe کنٹریکٹ پر `isValidSignature` کو کال کریں، اور توثیق کرنے کے لیے پیغام کو پیغام پیرامیٹر کے طور پر اور [دستخط پیرامیٹر کے لیے ایک خالی قدر](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (یعنی `0x`) منتقل کریں۔ Safe دیکھے گا کہ دستخط پیرامیٹر خالی ہے اور دستخط کی کرپٹوگرافک طور پر توثیق کرنے کے بجائے، یہ جان لے گا کہ آگے بڑھ کر یہ چیک کرنا ہے کہ آیا پیغام "منظور شدہ" پیغامات کی فہرست میں ہے یا نہیں۔ +2. آف چین پیغامات: + 1. تخلیق: ایک سیف مالک آف چین ایک پیغام بناتا ہے، پھر دوسرے سیف مالکان سے انفرادی طور پر پیغام پر دستخط کرواتا ہے جب تک کہ ملٹی سگ منظوری کی حد کو عبور کرنے کے لیے کافی دستخط نہ ہو جائیں۔ + 2. توثیق: `isValidSignature` کو کال کریں۔ پیغام پیرامیٹر میں، توثیق کیے جانے والے پیغام کو منتقل کریں۔ دستخط پیرامیٹر میں، ہر سیف مالک کے انفرادی دستخطوں کو ایک ساتھ جوڑ کر، آگے پیچھے منتقل کریں۔ Safe یہ چیک کرے گا کہ حد کو پورا کرنے کے لیے کافی دستخط ہیں **اور** یہ کہ ہر دستخط درست ہے۔ اگر ایسا ہے تو، یہ ایک قدر واپس کرے گا جو دستخط کی کامیاب توثیق کی نشاندہی کرتا ہے۔ + +## `_hash` پیرامیٹر بالکل کیا ہے؟ پورا پیغام کیوں نہیں منتقل کرتے؟ + +آپ نے شاید دیکھا ہوگا کہ [EIP-1271 انٹرفیس](https://eips.ethereum.org/EIPS/eip-1271) میں `isValidSignature` فنکشن خود پیغام نہیں لیتا، بلکہ اس کے بجائے ایک `_hash` پیرامیٹر لیتا ہے۔ اس کا مطلب یہ ہے کہ `isValidSignature` میں پورا صوابدیدی لمبائی کا پیغام منتقل کرنے کے بجائے، ہم اس کے بجائے پیغام کا 32-بائٹ ہیش (عام طور پر keccak256) منتقل کرتے ہیں۔ + +کال ڈیٹا کا ہر بائٹ — یعنی، اسمارٹ کنٹریکٹ فنکشن میں منتقل کیا گیا فنکشن پیرامیٹر ڈیٹا — کی [لاگت 16 گیس (4 گیس اگر صفر بائٹ ہے)](https://eips.ethereum.org/EIPS/eip-2028) ہوتی ہے، لہذا اگر پیغام لمبا ہو تو یہ بہت زیادہ گیس بچا سکتا ہے۔ + +### پچھلی EIP-1271 تفصیلات + +عام استعمال میں EIP-1271 کی ایسی تفصیلات ہیں جن میں `isValidSignature` فنکشن ہے جس کا پہلا پیرامیٹر `bytes` قسم کا (صوابدیدی لمبائی، بجائے مقررہ لمبائی `bytes32` کے) اور پیرامیٹر کا نام `message` ہے۔ یہ EIP-1271 معیار کا ایک [پرانا ورژن](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206) ہے۔ + +## میرے اپنے کنٹریکٹس میں EIP-1271 کو کیسے نافذ کیا جانا چاہئے؟ + +اسپیک یہاں بہت کھلا ہے۔ Safe نفاذ میں کچھ اچھے خیالات ہیں: + +- آپ کنٹریکٹ کے "مالک" کے EOA دستخطوں کو درست سمجھ سکتے ہیں۔ +- آپ منظور شدہ پیغامات کی ایک فہرست محفوظ کر سکتے ہیں اور صرف انہیں ہی درست سمجھ سکتے ہیں۔ + +آخر میں، یہ کنٹریکٹ ڈیولپر کے طور پر آپ پر منحصر ہے! + +## نتیجہ + +[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) ایک ہمہ جہت معیار ہے جو اسمارٹ کنٹریکٹس کو دستخطوں کی توثیق کرنے کی اجازت دیتا ہے۔ یہ اسمارٹ کنٹریکٹس کے لیے EOAs کی طرح زیادہ کام کرنے کا دروازہ کھولتا ہے — مثال کے طور پر "Ethereum کے ساتھ لاگ ان کریں" کو اسمارٹ کنٹریکٹس کے ساتھ کام کرنے کا ایک طریقہ فراہم کرتا ہے — اور اسے کئی طریقوں سے نافذ کیا جا سکتا ہے (Safe کا ایک غیر معمولی، دلچسپ نفاذ قابل غور ہے)۔ diff --git a/public/content/translations/ur/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/ur/developers/tutorials/erc-721-vyper-annotated-code/index.md new file mode 100644 index 00000000000..ffbfe173ec7 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/erc-721-vyper-annotated-code/index.md @@ -0,0 +1,643 @@ +--- +title: "Vyper ERC-721 کنٹریکٹ واک تھرو" +description: "Ryuya Nakamura کا ERC-721 کنٹریکٹ اور یہ کیسے کام کرتا ہے" +author: Ori Pomerantz +lang: ur-in +tags: [ "vyper", "erc-721", "python" ] +skill: beginner +published: 2021-04-01 +--- + +## تعارف {#introduction} + +[ERC-721](/developers/docs/standards/tokens/erc-721/) معیار نان فنجیبل ٹوکن (NFT) کی ملکیت رکھنے کے لیے استعمال کیا جاتا ہے۔ +[ERC-20](/developers/docs/standards/tokens/erc-20/) ٹوکن ایک کموڈیٹی کی طرح برتاؤ کرتے ہیں، کیونکہ انفرادی ٹوکن کے درمیان کوئی فرق نہیں ہے۔ +اس کے برعکس، ERC-721 ٹوکن ایسے اثاثوں کے لیے ڈیزائن کیے گئے ہیں جو ملتے جلتے تو ہیں لیکن ایک جیسے نہیں، جیسے کہ مختلف [بلی کے کارٹونز](https://www.cryptokitties.co/) یا رئیل اسٹیٹ کے مختلف ٹکڑوں کے ٹائٹلز۔ + +اس مضمون میں ہم [Ryuya Nakamura کے ERC-721 کنٹریکٹ](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) کا تجزیہ کریں گے۔ +یہ کنٹریکٹ [Vyper](https://vyper.readthedocs.io/en/latest/index.html) میں لکھا گیا ہے، جو ایک پائتھن جیسی کنٹریکٹ زبان ہے جسے Solidity کے مقابلے میں غیر محفوظ کوڈ لکھنا زیادہ مشکل بنانے کے لیے ڈیزائن کیا گیا ہے۔ + +## کنٹریکٹ {#contract} + +```python +# @dev ERC-721 نان فنجیبل ٹوکن معیار کا نفاذ۔ +# @author Ryuya Nakamura (@nrryuya) +# یہاں سے ترمیم شدہ: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy +``` + +Vyper میں، جیسا کہ Python میں ہے، کمنٹس ایک ہیش (`#`) سے شروع ہوتے ہیں اور لائن کے آخر تک جاری رہتے ہیں۔ وہ کمنٹس جن میں `@` شامل ہوتا ہے [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) کے ذریعے انسان کے پڑھنے کے قابل دستاویزات تیار کرنے کے لیے استعمال ہوتے ہیں۔ + +```python +from vyper.interfaces import ERC721 + +implements: ERC721 +``` + +ERC-721 انٹرفیس Vyper زبان میں پہلے سے موجود ہے۔ +[آپ کوڈ کی تعریف یہاں دیکھ سکتے ہیں](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py)۔ +انٹرفیس کی تعریف Vyper کے بجائے Python میں لکھی گئی ہے، کیونکہ انٹرفیس نہ صرف بلاک چین کے اندر استعمال ہوتے ہیں، بلکہ کسی بیرونی کلائنٹ سے بلاک چین کو ٹرانزیکشن بھیجتے وقت بھی استعمال ہوتے ہیں، جو Python میں لکھا ہو سکتا ہے۔ + +پہلی لائن انٹرفیس کو امپورٹ کرتی ہے، اور دوسری لائن یہ بتاتی ہے کہ ہم اسے یہاں نافذ کر رہے ہیں۔ + +### ERC721Receiver انٹرفیس {#receiver-interface} + +```python +# safeTransferFrom() کے ذریعے کال کیے جانے والے کنٹریکٹ کے لیے انٹرفیس +interface ERC721Receiver: + def onERC721Received( +``` + +ERC-721 دو قسم کی منتقلی کو سپورٹ کرتا ہے: + +- `transferFrom`، جو بھیجنے والے کو کسی بھی منزل کے پتے کی وضاحت کرنے دیتا ہے اور منتقلی کی ذمہ داری بھیجنے والے پر ڈالتا ہے۔ اس کا مطلب ہے کہ آپ کسی غلط پتے پر منتقل کر سکتے ہیں، ایسی صورت میں NFT ہمیشہ کے لیے ضائع ہو جاتا ہے۔ +- `safeTransferFrom`، جو یہ چیک کرتا ہے کہ منزل کا پتہ کنٹریکٹ ہے یا نہیں۔ اگر ایسا ہے تو، ERC-721 کنٹریکٹ وصول کرنے والے کنٹریکٹ سے پوچھتا ہے کہ کیا وہ NFT وصول کرنا چاہتا ہے۔ + +`safeTransferFrom` کی درخواستوں کا جواب دینے کے لیے ایک وصول کرنے والے کنٹریکٹ کو `ERC721Receiver` نافذ کرنا ہوتا ہے۔ + +```python + _operator: address, + _from: address, +``` + +`_from` پتہ ٹوکن کا موجودہ مالک ہے۔ `_operator` پتہ وہ ہے جس نے منتقلی کی درخواست کی ہے (یہ دونوں ایک جیسے نہیں ہو سکتے، الاؤنسز کی وجہ سے)۔ + +```python + _tokenId: uint256, +``` + +ERC-721 ٹوکن IDs 256 بٹس کی ہوتی ہیں۔ عام طور پر وہ ٹوکن کی نمائندگی کرنے والی کسی بھی چیز کی تفصیل کو ہیش کرکے بنائے جاتے ہیں۔ + +```python + _data: Bytes[1024] +``` + +درخواست میں 1024 بائٹس تک کا صارف کا ڈیٹا ہو سکتا ہے۔ + +```python + ) -> bytes32: view +``` + +ایسے معاملات کو روکنے کے لیے جن میں کوئی کنٹریکٹ غلطی سے منتقلی قبول کر لیتا ہے، واپسی کی قیمت بولین نہیں ہوتی، بلکہ ایک مخصوص قیمت کے ساتھ 256 بٹس ہوتی ہے۔ + +یہ فنکشن ایک `view` ہے، جس کا مطلب ہے کہ یہ بلاک چین کی حالت کو پڑھ سکتا ہے، لیکن اسے تبدیل نہیں کر سکتا۔ + +### ایونٹس {#events} + +[Events](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e) بلاک چین کے باہر صارفین اور سرورز کو واقعات سے آگاہ کرنے کے لیے جاری کیے جاتے ہیں۔ نوٹ کریں کہ ایونٹس کا مواد بلاک چین پر موجود کنٹریکٹس کے لیے دستیاب نہیں ہوتا ہے۔ + +```python +# @dev کسی بھی میکانزم کے ذریعے کسی بھی NFT کی ملکیت تبدیل ہونے پر جاری ہوتا ہے۔ یہ ایونٹ اس وقت جاری ہوتا ہے جب NFTs بنائے جاتے ہیں +# (`from` == 0) اور تباہ کیے جاتے ہیں (`to` == 0)۔ استثناء: کنٹریکٹ کی تخلیق کے دوران، کسی بھی +# تعداد میں NFTs ٹرانسفر جاری کیے بغیر بنائے اور تفویض کیے جا سکتے ہیں۔ کسی بھی +# منتقلی کے وقت، اس NFT کے لیے منظور شدہ پتہ (اگر کوئی ہو) کو none پر ری سیٹ کر دیا جاتا ہے۔ +# @param _from NFT کا بھیجنے والا (اگر پتہ صفر ہے تو یہ ٹوکن کی تخلیق کی نشاندہی کرتا ہے)۔ +# @param _to NFT کا وصول کنندہ (اگر پتہ صفر ہے تو یہ ٹوکن کی تباہی کی نشاندہی کرتا ہے)۔ +# @param _tokenId وہ NFT جو منتقل کیا گیا۔ +event Transfer: + sender: indexed(address) + receiver: indexed(address) + tokenId: indexed(uint256) +``` + +یہ ERC-20 ٹرانسفر ایونٹ کی طرح ہے، سوائے اس کے کہ ہم رقم کے بجائے `tokenId` کی اطلاع دیتے ہیں۔ +صفر پتے کا کوئی مالک نہیں ہے، لہذا روایت کے مطابق ہم اسے ٹوکنز کی تخلیق اور تباہی کی اطلاع دینے کے لیے استعمال کرتے ہیں۔ + +```python +# @dev یہ اس وقت جاری ہوتا ہے جب کسی NFT کے لیے منظور شدہ پتہ تبدیل کیا جاتا ہے یا اس کی دوبارہ تصدیق کی جاتی ہے۔ صفر +# پتہ اس بات کی نشاندہی کرتا ہے کہ کوئی منظور شدہ پتہ نہیں ہے۔ جب ٹرانسفر ایونٹ جاری ہوتا ہے، تو یہ بھی +# اشارہ کرتا ہے کہ اس NFT کے لیے منظور شدہ پتہ (اگر کوئی ہو) کو none پر ری سیٹ کر دیا گیا ہے۔ +# @param _owner NFT کا مالک۔ +# @param _approved وہ پتہ جسے ہم منظور کر رہے ہیں۔ +# @param _tokenId وہ NFT جسے ہم منظور کر رہے ہیں۔ +event Approval: + owner: indexed(address) + approved: indexed(address) + tokenId: indexed(uint256) +``` + +ایک ERC-721 کی منظوری ایک ERC-20 الاؤنس کی طرح ہے۔ ایک مخصوص پتے کو ایک مخصوص ٹوکن منتقل کرنے کی اجازت ہے۔ یہ کنٹریکٹس کو اس وقت جواب دینے کے لیے ایک میکانزم فراہم کرتا ہے جب وہ کوئی ٹوکن قبول کرتے ہیں۔ کنٹریکٹس ایونٹس کو نہیں سن سکتے، لہذا اگر آپ صرف ٹوکن ان کو منتقل کر دیتے ہیں تو وہ اس کے بارے میں "جانتے" نہیں ہیں۔ اس طرح مالک پہلے ایک منظوری جمع کرتا ہے اور پھر کنٹریکٹ کو ایک درخواست بھیجتا ہے: "میں نے آپ کو ٹوکن X منتقل کرنے کی منظوری دی ہے، براہ کرم کریں..."۔ + +یہ ERC-721 معیار کو ERC-20 معیار کی طرح بنانے کے لیے ایک ڈیزائن کا انتخاب ہے۔ چونکہ ERC-721 ٹوکنز فنجیبل نہیں ہیں، ایک کنٹریکٹ ٹوکن کی ملکیت کو دیکھ کر یہ بھی شناخت کر سکتا ہے کہ اسے ایک مخصوص ٹوکن ملا ہے۔ + +```python +# @dev یہ اس وقت جاری ہوتا ہے جب کسی مالک کے لیے آپریٹر کو فعال یا غیر فعال کیا جاتا ہے۔ آپریٹر مالک کے +# تمام NFTs کا انتظام کر سکتا ہے۔ +# @param _owner NFT کا مالک۔ +# @param _operator وہ پتہ جس پر ہم آپریٹر کے حقوق سیٹ کر رہے ہیں۔ +# @param _approved آپریٹر کے حقوق کی حیثیت (اگر آپریٹر کے حقوق دیے گئے ہیں تو true اور اگر +# منسوخ کیے گئے ہیں تو false)۔ +event ApprovalForAll: + owner: indexed(address) + operator: indexed(address) + approved: bool +``` + +کبھی کبھی ایک _آپریٹر_ کا ہونا مفید ہوتا ہے جو کسی مخصوص قسم کے اکاؤنٹ کے تمام ٹوکنز کا انتظام کر سکے (وہ جو ایک مخصوص کنٹریکٹ کے ذریعے منظم ہوتے ہیں)، جو کہ پاور آف اٹارنی کی طرح ہے۔ مثال کے طور پر، میں ایسی طاقت ایک ایسے کنٹریکٹ کو دینا چاہ سکتا ہوں جو یہ چیک کرے کہ کیا میں نے چھ ماہ سے اس سے رابطہ نہیں کیا ہے، اور اگر ایسا ہے تو میرے اثاثے میرے وارثوں میں تقسیم کر دے (اگر ان میں سے کوئی اس کا مطالبہ کرتا ہے، تو کنٹریکٹس ٹرانزیکشن کے ذریعے کال کیے بغیر کچھ نہیں کر سکتے)۔ ERC-20 میں ہم وراثت کے کنٹریکٹ کو ایک بڑا الاؤنس دے سکتے ہیں، لیکن یہ ERC-721 کے لیے کام نہیں کرتا کیونکہ ٹوکنز فنجیبل نہیں ہیں۔ یہ اس کے مساوی ہے۔ + +`approved` کی قیمت ہمیں بتاتی ہے کہ آیا ایونٹ منظوری کے لیے ہے، یا منظوری کی واپسی کے لیے۔ + +### اسٹیٹ متغیرات {#state-vars} + +ان متغیرات میں ٹوکنز کی موجودہ حالت ہوتی ہے: کون سے دستیاب ہیں اور ان کا مالک کون ہے۔ ان میں سے زیادہ تر `HashMap` آبجیکٹس ہیں، [یک سمتی میپنگز جو دو اقسام کے درمیان موجود ہیں](https://vyper.readthedocs.io/en/latest/types.html#mappings)۔ + +```python +# @dev NFT ID سے اس پتے تک میپنگ جو اس کا مالک ہے۔ +idToOwner: HashMap[uint256, address] + +# @dev NFT ID سے منظور شدہ پتے تک میپنگ۔ +idToApprovals: HashMap[uint256, address] +``` + +Ethereum میں صارف اور کنٹریکٹ کی شناخت 160 بٹ کے پتوں سے ظاہر ہوتی ہے۔ یہ دو متغیرات ٹوکن آئی ڈیز سے ان کے مالکان اور ان لوگوں تک میپ کرتے ہیں جنہیں انہیں منتقل کرنے کی منظوری دی گئی ہے (ہر ایک کے لیے زیادہ سے زیادہ ایک)۔ Ethereum میں، غیر شروع شدہ ڈیٹا ہمیشہ صفر ہوتا ہے، لہذا اگر کوئی مالک یا منظور شدہ ٹرانسفرر نہیں ہے تو اس ٹوکن کی قیمت صفر ہے۔ + +```python +# @dev مالک کے پتے سے اس کے ٹوکنز کی گنتی تک میپنگ۔ +ownerToNFTokenCount: HashMap[address, uint256] +``` + +یہ متغیر ہر مالک کے ٹوکنز کی گنتی رکھتا ہے۔ مالکان سے ٹوکنز تک کوئی میپنگ نہیں ہے، لہذا کسی مخصوص مالک کے ٹوکنز کی شناخت کا واحد طریقہ بلاک چین کی ایونٹ ہسٹری میں پیچھے دیکھنا اور مناسب `ٹرانسفر` ایونٹس کو دیکھنا ہے۔ ہم اس متغیر کا استعمال یہ جاننے کے لیے کر سکتے ہیں کہ جب ہمارے پاس تمام NFTs ہوں اور ہمیں وقت میں مزید پیچھے دیکھنے کی ضرورت نہ ہو۔ + +نوٹ کریں کہ یہ الگورتھم صرف یوزر انٹرفیس اور بیرونی سرورز کے لیے کام کرتا ہے۔ بلاک چین پر چلنے والا کوڈ ماضی کے ایونٹس کو نہیں پڑھ سکتا۔ + +```python +# @dev مالک کے پتے سے آپریٹر کے پتوں کی میپنگ تک میپنگ۔ +ownerToOperators: HashMap[address, HashMap[address, bool]] +``` + +ایک اکاؤنٹ میں ایک سے زیادہ آپریٹر ہو سکتے ہیں۔ ایک سادہ `HashMap` ان پر نظر رکھنے کے لیے ناکافی ہے، کیونکہ ہر کلید ایک واحد قدر کی طرف لے جاتی ہے۔ اس کے بجائے، آپ قدر کے طور پر `HashMap[address, bool]` استعمال کر سکتے ہیں۔ پہلے سے طے شدہ طور پر ہر پتے کی قدر `False` ہے، جس کا مطلب ہے کہ یہ آپریٹر نہیں ہے۔ آپ ضرورت کے مطابق قدروں کو `True` پر سیٹ کر سکتے ہیں۔ + +```python +# @dev منٹر کا پتہ، جو ٹوکن منٹ کر سکتا ہے +minter: address +``` + +نئے ٹوکن کسی نہ کسی طرح بنائے جانے چاہئیں۔ اس کنٹریکٹ میں ایک واحد ادارہ ہے جسے ایسا کرنے کی اجازت ہے، یعنی `minter`۔ یہ مثال کے طور پر ایک گیم کے لیے کافی ہونے کا امکان ہے۔ دیگر مقاصد کے لیے، زیادہ پیچیدہ کاروباری منطق بنانے کی ضرورت پڑ سکتی ہے۔ + +```python +# @dev انٹرفیس آئی ڈی سے bool تک میپنگ اس بارے میں کہ آیا یہ سپورٹڈ ہے یا نہیں +supportedInterfaces: HashMap[bytes32, bool] + +# @dev ERC165 کا ERC165 انٹرفیس آئی ڈی +ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7 + +# @dev ERC721 کا ERC165 انٹرفیس آئی ڈی +ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd +``` + +[ERC-165](https://eips.ethereum.org/EIPS/eip-165) ایک کنٹریکٹ کے لیے ایک میکانزم کی وضاحت کرتا ہے تاکہ یہ ظاہر کیا جا سکے کہ ایپلیکیشنز اس کے ساتھ کیسے بات چیت کر سکتی ہیں، اور یہ کن ERCs کے مطابق ہے۔ اس صورت میں، کنٹریکٹ ERC-165 اور ERC-721 کے مطابق ہے۔ + +### فنکشنز {#functions} + +یہ وہ فنکشنز ہیں جو دراصل ERC-721 کو نافذ کرتے ہیں۔ + +#### کنسٹرکٹر {#constructor} + +```python +@external +def __init__(): +``` + +Vyper میں، جیسا کہ Python میں ہے، کنسٹرکٹر فنکشن کو `__init__` کہا جاتا ہے۔ + +```python + """ + @dev کنٹریکٹ کنسٹرکٹر۔ + """ +``` + +Python میں، اور Vyper میں، آپ ایک ملٹی لائن اسٹرنگ کی وضاحت کرکے بھی ایک کمنٹ بنا سکتے ہیں (جو `"""` سے شروع اور ختم ہوتا ہے)، اور اسے کسی بھی طرح سے استعمال نہیں کرتے ہیں۔ ان کمنٹس میں [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) بھی شامل ہو سکتا ہے۔ + +```python + self.supportedInterfaces[ERC165_INTERFACE_ID] = True + self.supportedInterfaces[ERC721_INTERFACE_ID] = True + self.minter = msg.sender +``` + +اسٹیٹ متغیرات تک رسائی کے لیے آپ `self.` استعمال کرتے ہیں۔` (دوبارہ، جیسا کہ پائتھن میں ہے)۔ + +#### فنکشنز دیکھیں {#views} + +یہ وہ فنکشنز ہیں جو بلاک چین کی حالت میں ترمیم نہیں کرتے ہیں، اور اس لیے اگر انہیں بیرونی طور پر کال کیا جائے تو مفت میں عمل میں لایا جا سکتا ہے۔ اگر ویو فنکشنز کو کسی کنٹریکٹ کے ذریعے کال کیا جاتا ہے تو انہیں اب بھی ہر نوڈ پر عمل میں لانا پڑتا ہے اور اس لیے گیس کی لاگت آتی ہے۔ + +```python +@view +@external +``` + +فنکشن کی تعریف سے پہلے یہ کلیدی الفاظ جو ایٹ سائن (`@`) سے شروع ہوتے ہیں، _ڈیکوریشنز_ کہلاتے ہیں۔ وہ ان حالات کی وضاحت کرتے ہیں جن میں ایک فنکشن کو کال کیا جا سکتا ہے۔ + +- `@view` اس بات کی وضاحت کرتا ہے کہ یہ فنکشن ایک ویو ہے۔ +- `@external` اس بات کی وضاحت کرتا ہے کہ اس مخصوص فنکشن کو ٹرانزیکشنز اور دیگر کنٹریکٹس کے ذریعے کال کیا جا سکتا ہے۔ + +```python +def supportsInterface(_interfaceID: bytes32) -> bool: +``` + +Python کے برعکس، Vyper ایک [اسٹیٹک ٹائپڈ زبان](https://wikipedia.org/wiki/Type_system#Static_type_checking) ہے۔ +آپ [ڈیٹا ٹائپ](https://vyper.readthedocs.io/en/latest/types.html) کی شناخت کیے بغیر کسی متغیر، یا فنکشن پیرامیٹر کا اعلان نہیں کر سکتے۔ اس صورت میں ان پٹ پیرامیٹر `bytes32` ہے، ایک 256 بٹ کی قدر ([ایتھیریم ورچوئل مشین](/developers/docs/evm/) کا مقامی لفظ سائز 256 بٹس ہے)۔ آؤٹ پٹ ایک بولین قدر ہے۔ روایت کے مطابق، فنکشن پیرامیٹرز کے نام انڈر اسکور (`_`) سے شروع ہوتے ہیں۔ + +```python + """ + @dev انٹرفیس کی شناخت ERC-165 میں بیان کی گئی ہے۔ + @param _interfaceID انٹرفیس کا آئی ڈی + """ + return self.supportedInterfaces[_interfaceID] +``` + +`self.supportedInterfaces` HashMap سے قدر واپس کریں، جو کنسٹرکٹر (`__init__`) میں سیٹ کی گئی ہے۔ + +```python +### فنکشنز دیکھیں ### + +``` + +یہ وہ ویو فنکشنز ہیں جو ٹوکنز کے بارے میں معلومات صارفین اور دیگر کنٹریکٹس کو دستیاب کراتے ہیں۔ + +```python +@view +@external +def balanceOf(_owner: address) -> uint256: + """ + @dev `_owner` کے زیر ملکیت NFTs کی تعداد واپس کرتا ہے۔ + اگر `_owner` صفر کا پتہ ہے تو تھرو کرتا ہے۔ صفر پتے کو تفویض کردہ NFTs کو غلط سمجھا جاتا ہے۔ + @param _owner وہ پتہ جس کے لیے بیلنس کی دریافت کرنی ہے۔ + """ + assert _owner != ZERO_ADDRESS +``` + +یہ لائن [asserts](https://vyper.readthedocs.io/en/latest/statements.html#assert) کرتی ہے کہ `_owner` صفر نہیں ہے۔ اگر ایسا ہے تو، ایک خرابی ہے اور آپریشن کو واپس کر دیا جاتا ہے۔ + +```python + return self.ownerToNFTokenCount[_owner] + +@view +@external +def ownerOf(_tokenId: uint256) -> address: + """ + @dev NFT کے مالک کا پتہ واپس کرتا ہے۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ + @param _tokenId ایک NFT کے لیے شناخت کنندہ۔ + """ + owner: address = self.idToOwner[_tokenId] + # اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے + assert owner != ZERO_ADDRESS + return owner +``` + +ایتھیریم ورچوئل مشین (evm) میں کوئی بھی اسٹوریج جس میں کوئی قدر ذخیرہ نہیں کی گئی ہے وہ صفر ہوتا ہے۔ +اگر `_tokenId` پر کوئی ٹوکن نہیں ہے تو `self.idToOwner[_tokenId]` کی قدر صفر ہے۔ اس صورت میں فنکشن واپس ہوجاتا ہے۔ + +```python +@view +@external +def getApproved(_tokenId: uint256) -> address: + """ + @dev ایک واحد NFT کے لیے منظور شدہ پتہ حاصل کریں۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ + @param _tokenId اس NFT کا آئی ڈی جس کی منظوری کی دریافت کرنی ہے۔ + """ + # اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے + assert self.idToOwner[_tokenId] != ZERO_ADDRESS + return self.idToApprovals[_tokenId] +``` + +نوٹ کریں کہ `getApproved` صفر واپس _کر سکتا_ ہے۔ اگر ٹوکن درست ہے تو یہ `self.idToApprovals[_tokenId]` واپس کرتا ہے۔ +اگر کوئی منظور کنندہ نہیں ہے تو وہ قدر صفر ہے۔ + +```python +@view +@external +def isApprovedForAll(_owner: address, _operator: address) -> bool: + """ + @dev چیک کرتا ہے کہ آیا `_operator` `_owner` کے لیے ایک منظور شدہ آپریٹر ہے۔ + @param _owner وہ پتہ جو NFTs کا مالک ہے۔ + @param _operator وہ پتہ جو مالک کی جانب سے کام کرتا ہے۔ + """ + return (self.ownerToOperators[_owner])[_operator] +``` + +یہ فنکشن چیک کرتا ہے کہ آیا `_operator` کو اس کنٹریکٹ میں `_owner` کے تمام ٹوکنز کا انتظام کرنے کی اجازت ہے۔ +چونکہ متعدد آپریٹرز ہو سکتے ہیں، یہ ایک دو سطحی HashMap ہے۔ + +#### ٹرانسفر ہیلپر فنکشنز {#transfer-helpers} + +یہ فنکشنز ان آپریشنز کو نافذ کرتے ہیں جو ٹوکنز کی منتقلی یا انتظام کا حصہ ہیں۔ + +```python + +### ٹرانسفر فنکشن ہیلپرز ### + +@view +@internal +``` + +یہ ڈیکوریشن، `@internal`، کا مطلب ہے کہ فنکشن صرف اسی کنٹریکٹ کے اندر دیگر فنکشنز سے قابل رسائی ہے۔ روایت کے مطابق، ان فنکشنز کے نام بھی انڈر اسکور (`_`) سے شروع ہوتے ہیں۔ + +```python +def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool: + """ + @dev واپس کرتا ہے کہ آیا دیا گیا خرچ کنندہ ایک دیا گیا ٹوکن آئی ڈی منتقل کر سکتا ہے + @param spender خرچ کنندہ کا پتہ جس کی دریافت کرنی ہے + @param tokenId منتقل کیے جانے والے ٹوکن کا uint256 آئی ڈی + @return bool کہ آیا msg.sender دیے گئے ٹوکن آئی ڈی کے لیے منظور شدہ ہے، + مالک کا آپریٹر ہے، یا ٹوکن کا مالک ہے + """ + owner: address = self.idToOwner[_tokenId] + spenderIsOwner: bool = owner == _spender + spenderIsApproved: bool = _spender == self.idToApprovals[_tokenId] + spenderIsApprovedForAll: bool = (self.ownerToOperators[owner])[_spender] + return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAll +``` + +کسی پتے کو ٹوکن منتقل کرنے کی اجازت دینے کے تین طریقے ہیں: + +1. پتہ ٹوکن کا مالک ہے +2. اس پتے کو وہ ٹوکن خرچ کرنے کی منظوری دی گئی ہے +3. پتہ ٹوکن کے مالک کے لیے آپریٹر ہے + +اوپر والا فنکشن ایک ویو ہو سکتا ہے کیونکہ یہ حالت کو تبدیل نہیں کرتا ہے۔ آپریٹنگ اخراجات کو کم کرنے کے لیے، کوئی بھی فنکشن جو ایک ویو ہو _سکتا_ ہے وہ ایک ویو _ہونا_ چاہیے۔ + +```python +@internal +def _addTokenTo(_to: address, _tokenId: uint256): + """ + @dev ایک دیے گئے پتے پر ایک NFT شامل کریں + اگر `_tokenId` کسی کی ملکیت میں ہے تو تھرو کرتا ہے۔ + """ + # اگر `_tokenId` کسی کی ملکیت میں ہے تو تھرو کرتا ہے + assert self.idToOwner[_tokenId] == ZERO_ADDRESS + # مالک کو تبدیل کریں + self.idToOwner[_tokenId] = _to + # گنتی ٹریکنگ کو تبدیل کریں + self.ownerToNFTokenCount[_to] += 1 + + +@internal +def _removeTokenFrom(_from: address, _tokenId: uint256): + """ + @dev ایک دیے گئے پتے سے ایک NFT ہٹائیں + اگر `_from` موجودہ مالک نہیں ہے تو تھرو کرتا ہے۔ + """ + # اگر `_from` موجودہ مالک نہیں ہے تو تھرو کرتا ہے + assert self.idToOwner[_tokenId] == _from + # مالک کو تبدیل کریں + self.idToOwner[_tokenId] = ZERO_ADDRESS + # گنتی ٹریکنگ کو تبدیل کریں + self.ownerToNFTokenCount[_from] -= 1 +``` + +جب منتقلی میں کوئی مسئلہ ہوتا ہے تو ہم کال کو واپس کر دیتے ہیں۔ + +```python +@internal +def _clearApproval(_owner: address, _tokenId: uint256): + """ + @dev دیے گئے پتے کی منظوری صاف کریں + اگر `_owner` موجودہ مالک نہیں ہے تو تھرو کرتا ہے۔ + """ + # اگر `_owner` موجودہ مالک نہیں ہے تو تھرو کرتا ہے + assert self.idToOwner[_tokenId] == _owner + if self.idToApprovals[_tokenId] != ZERO_ADDRESS: + # منظوریوں کو ری سیٹ کریں + self.idToApprovals[_tokenId] = ZERO_ADDRESS +``` + +صرف ضرورت پڑنے پر ہی قدر کو تبدیل کریں۔ اسٹیٹ متغیرات اسٹوریج میں رہتے ہیں۔ اسٹوریج میں لکھنا EVM (ایتھیریم ورچوئل مشین) کے سب سے مہنگے آپریشنز میں سے ایک ہے ([گیس](/developers/docs/gas/) کے لحاظ سے)۔ لہذا، اسے کم سے کم کرنا ایک اچھا خیال ہے، یہاں تک کہ موجودہ قدر کو لکھنے کی بھی زیادہ لاگت آتی ہے۔ + +```python +@internal +def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address): + """ + @dev ایک NFT کی منتقلی پر عمل کریں۔ + جب تک `msg.sender` موجودہ مالک، ایک مجاز آپریٹر، یا اس NFT کے لیے منظور شدہ + پتہ نہ ہو، تھرو کرتا ہے۔ (نوٹ: `msg.sender` کو نجی فنکشن میں اجازت نہیں ہے لہذا `_sender` پاس کریں۔) + اگر `_to` صفر کا پتہ ہے تو تھرو کرتا ہے۔ + اگر `_from` موجودہ مالک نہیں ہے تو تھرو کرتا ہے۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ + """ +``` + +ہمارے پاس یہ اندرونی فنکشن ہے کیونکہ ٹوکن منتقل کرنے کے دو طریقے ہیں (باقاعدہ اور محفوظ)، لیکن ہم چاہتے ہیں کہ کوڈ میں صرف ایک ہی جگہ ہو جہاں ہم اسے کرتے ہیں تاکہ آڈیٹنگ آسان ہو۔ + +```python + # ضروریات چیک کریں + assert self._isApprovedOrOwner(_sender, _tokenId) + # اگر `_to` صفر کا پتہ ہے تو تھرو کرتا ہے + assert _to != ZERO_ADDRESS + # منظوری صاف کریں۔ اگر `_from` موجودہ مالک نہیں ہے تو تھرو کرتا ہے + self._clearApproval(_from, _tokenId) + # NFT ہٹائیں۔ اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے + self._removeTokenFrom(_from, _tokenId) + # NFT شامل کریں + self._addTokenTo(_to, _tokenId) + # منتقلی کو لاگ کریں + log Transfer(_from, _to, _tokenId) +``` + +Vyper میں ایک ایونٹ جاری کرنے کے لیے آپ ایک `log` اسٹیٹمنٹ استعمال کرتے ہیں ([مزید تفصیلات کے لیے یہاں دیکھیں](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging))۔ + +#### منتقلی کے فنکشنز {#transfer-funs} + +```python + +### منتقلی کے فنکشنز ### + +@external +def transferFrom(_from: address, _to: address, _tokenId: uint256): + """ + @dev جب تک `msg.sender` موجودہ مالک، ایک مجاز آپریٹر، یا اس NFT کے لیے منظور شدہ + پتہ نہ ہو، تھرو کرتا ہے۔ + اگر `_from` موجودہ مالک نہیں ہے تو تھرو کرتا ہے۔ + اگر `_to` صفر کا پتہ ہے تو تھرو کرتا ہے۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ + @notice کالر اس بات کی تصدیق کرنے کا ذمہ دار ہے کہ `_to` NFTs وصول کرنے کے قابل ہے ورنہ + وہ مستقل طور پر ضائع ہو سکتے ہیں۔ + @param _from NFT کا موجودہ مالک۔ + @param _to نیا مالک۔ + @param _tokenId منتقل کرنے کے لیے NFT۔ + """ + self._transferFrom(_from, _to, _tokenId, msg.sender) +``` + +یہ فنکشن آپ کو کسی بھی پتے پر منتقل کرنے دیتا ہے۔ جب تک کہ پتہ صارف کا نہ ہو، یا کوئی ایسا کنٹریکٹ جو ٹوکن منتقل کرنا جانتا ہو، کوئی بھی ٹوکن جو آپ منتقل کرتے ہیں وہ اس پتے میں پھنس جائے گا اور بیکار ہو جائے گا۔ + +```python +@external +def safeTransferFrom( + _from: address, + _to: address, + _tokenId: uint256, + _data: Bytes[1024]=b"" + ): + """ + @dev ایک NFT کی ملکیت ایک پتے سے دوسرے پتے پر منتقل کرتا ہے۔ + جب تک `msg.sender` موجودہ مالک، ایک مجاز آپریٹر، یا اس + NFT کے لیے منظور شدہ پتہ نہ ہو، تھرو کرتا ہے۔ + اگر `_from` موجودہ مالک نہیں ہے تو تھرو کرتا ہے۔ + اگر `_to` صفر کا پتہ ہے تو تھرو کرتا ہے۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ + اگر `_to` ایک سمارٹ کنٹریکٹ ہے، تو یہ `_to` پر `onERC721Received` کو کال کرتا ہے اور اگر + واپسی کی قدر `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))` نہ ہو تو تھرو کرتا ہے۔ + نوٹ: bytes4 کو پیڈنگ کے ساتھ bytes32 سے ظاہر کیا جاتا ہے + @param _from NFT کا موجودہ مالک۔ + @param _to نیا مالک۔ + @param _tokenId منتقل کرنے کے لیے NFT۔ + @param _data اضافی ڈیٹا بغیر کسی مخصوص فارمیٹ کے، `_to` کو کال میں بھیجا گیا۔ + """ + self._transferFrom(_from, _to, _tokenId, msg.sender) +``` + +پہلے منتقلی کرنا ٹھیک ہے کیونکہ اگر کوئی مسئلہ ہوتا ہے تو ہم ویسے بھی واپس کر دیں گے، لہذا کال میں کیا گیا سب کچھ منسوخ ہو جائے گا۔ + +```python + if _to.is_contract: # چیک کریں کہ آیا `_to` ایک کنٹریکٹ ایڈریس ہے +``` + +پہلے یہ دیکھنے کے لیے چیک کریں کہ آیا پتہ ایک کنٹریکٹ ہے (اگر اس میں کوڈ ہے)۔ اگر نہیں، تو فرض کریں کہ یہ صارف کا پتہ ہے اور صارف ٹوکن کا استعمال یا اسے منتقل کر سکے گا۔ لیکن اسے آپ کو تحفظ کے جھوٹے احساس میں مبتلا نہ ہونے دیں۔ آپ `safeTransferFrom` کے ساتھ بھی ٹوکن کھو سکتے ہیں، اگر آپ انہیں ایک ایسے پتے پر منتقل کرتے ہیں جس کی نجی کلید کسی کو معلوم نہیں ہے۔ + +```python + returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data) +``` + +ٹارگٹ کنٹریکٹ کو کال کریں تاکہ یہ دیکھا جا سکے کہ کیا وہ ERC-721 ٹوکن وصول کر سکتا ہے۔ + +```python + # اگر منتقلی کی منزل ایک کنٹریکٹ ہے جو 'onERC721Received' کو نافذ نہیں کرتا ہے تو تھرو کرتا ہے + assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32) +``` + +اگر منزل ایک کنٹریکٹ ہے، لیکن ایک ایسا جو ERC-721 ٹوکن قبول نہیں کرتا (یا جس نے اس مخصوص منتقلی کو قبول نہ کرنے کا فیصلہ کیا ہے)، تو واپس کریں۔ + +```python +@external +def approve(_approved: address, _tokenId: uint256): + """ + @dev ایک NFT کے لیے منظور شدہ پتہ سیٹ کریں یا اس کی دوبارہ تصدیق کریں۔ صفر پتہ اس بات کی نشاندہی کرتا ہے کہ کوئی منظور شدہ پتہ نہیں ہے۔ + جب تک `msg.sender` موجودہ NFT کا مالک، یا موجودہ مالک کا ایک مجاز آپریٹر نہ ہو، تھرو کرتا ہے۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ (نوٹ: یہ EIP میں نہیں لکھا گیا ہے) + اگر `_approved` موجودہ مالک ہے تو تھرو کرتا ہے۔ (نوٹ: یہ EIP میں نہیں لکھا گیا ہے) + @param _approved دیے گئے NFT آئی ڈی کے لیے منظور کیا جانے والا پتہ۔ + @param _tokenId منظور کیے جانے والے ٹوکن کا آئی ڈی۔ + """ + owner: address = self.idToOwner[_tokenId] + # اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے + assert owner != ZERO_ADDRESS + # اگر `_approved` موجودہ مالک ہے تو تھرو کرتا ہے + assert _approved != owner +``` + +روایت کے مطابق اگر آپ کوئی منظور کنندہ نہیں رکھنا چاہتے تو آپ صفر پتے کو مقرر کرتے ہیں، خود کو نہیں۔ + +```python + # ضروریات چیک کریں + senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender + senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender] + assert (senderIsOwner or senderIsApprovedForAll) +``` + +منظوری سیٹ کرنے کے لیے آپ یا تو مالک ہو سکتے ہیں، یا مالک کی طرف سے مجاز آپریٹر۔ + +```python + # منظوری سیٹ کریں + self.idToApprovals[_tokenId] = _approved + log Approval(owner, _approved, _tokenId) + + +@external +def setApprovalForAll(_operator: address, _approved: bool): + """ + @dev کسی تیسرے فریق ("آپریٹر") کے لیے `msg.sender` کے تمام اثاثوں کا انتظام کرنے کے لیے منظوری کو فعال یا غیر فعال کرتا ہے۔ + یہ ApprovalForAll ایونٹ بھی جاری کرتا ہے۔ + اگر `_operator` `msg.sender` ہے تو تھرو کرتا ہے۔ (نوٹ: یہ EIP میں نہیں لکھا گیا ہے) + @notice یہ اس وقت بھی کام کرتا ہے جب بھیجنے والے کے پاس اس وقت کوئی ٹوکن نہ ہو۔ + @param _operator مجاز آپریٹرز کے سیٹ میں شامل کرنے کے لیے پتہ۔ + @param _approved اگر آپریٹرز منظور شدہ ہیں تو True، منظوری منسوخ کرنے کے لیے false۔ + """ + # اگر `_operator` `msg.sender` ہے تو تھرو کرتا ہے + assert _operator != msg.sender + self.ownerToOperators[msg.sender][_operator] = _approved + log ApprovalForAll(msg.sender, _operator, _approved) +``` + +#### نئے ٹوکن منٹ کریں اور موجودہ کو تباہ کریں {#mint-burn} + +وہ اکاؤنٹ جس نے کنٹریکٹ بنایا ہے وہ `minter` ہے، وہ سپر یوزر جسے نئے NFTs منٹ کرنے کا اختیار ہے۔ تاہم، اسے بھی موجودہ ٹوکنز کو جلانے کی اجازت نہیں ہے۔ صرف مالک، یا مالک کی طرف سے مجاز ادارہ، ایسا کر سکتا ہے۔ + +```python +### منٹ اور برن فنکشنز ### + +@external +def mint(_to: address, _tokenId: uint256) -> bool: +``` + +یہ فنکشن ہمیشہ `True` واپس کرتا ہے، کیونکہ اگر آپریشن ناکام ہوتا ہے تو اسے واپس کر دیا جاتا ہے۔ + +```python + """ + @dev ٹوکن منٹ کرنے کا فنکشن + اگر `msg.sender` منٹر نہیں ہے تو تھرو کرتا ہے۔ + اگر `_to` صفر کا پتہ ہے تو تھرو کرتا ہے۔ + اگر `_tokenId` کسی کی ملکیت میں ہے تو تھرو کرتا ہے۔ + @param _to وہ پتہ جو منٹ کیے گئے ٹوکن وصول کرے گا۔ + @param _tokenId منٹ کیے جانے والے ٹوکن کا آئی ڈی۔ + @return ایک بولین جو اس بات کی نشاندہی کرتا ہے کہ آیا آپریشن کامیاب تھا۔ + """ + # اگر `msg.sender` منٹر نہیں ہے تو تھرو کرتا ہے + assert msg.sender == self.minter +``` + +صرف منٹر (وہ اکاؤنٹ جس نے ERC-721 کنٹریکٹ بنایا ہے) نئے ٹوکن منٹ کر سکتا ہے۔ یہ مستقبل میں ایک مسئلہ ہو سکتا ہے اگر ہم منٹر کی شناخت تبدیل کرنا چاہیں۔ ایک پروڈکشن کنٹریکٹ میں آپ شاید ایک ایسا فنکشن چاہیں گے جو منٹر کو منٹر کی مراعات کسی اور کو منتقل کرنے کی اجازت دے۔ + +```python + # اگر `_to` صفر کا پتہ ہے تو تھرو کرتا ہے + assert _to != ZERO_ADDRESS + # NFT شامل کریں۔ اگر `_tokenId` کسی کی ملکیت میں ہے تو تھرو کرتا ہے + self._addTokenTo(_to, _tokenId) + log Transfer(ZERO_ADDRESS, _to, _tokenId) + return True +``` + +روایت کے مطابق، نئے ٹوکنز کی منٹنگ صفر پتے سے منتقلی کے طور پر شمار ہوتی ہے۔ + +```python + +@external +def burn(_tokenId: uint256): + """ + @dev ایک مخصوص ERC721 ٹوکن کو جلاتا ہے۔ + جب تک `msg.sender` موجودہ مالک، ایک مجاز آپریٹر، یا اس NFT کے لیے منظور شدہ + پتہ نہ ہو، تھرو کرتا ہے۔ + اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے۔ + @param _tokenId جلائے جانے والے ERC721 ٹوکن کا uint256 آئی ڈی۔ + """ + # ضروریات چیک کریں + assert self._isApprovedOrOwner(msg.sender, _tokenId) + owner: address = self.idToOwner[_tokenId] + # اگر `_tokenId` ایک درست NFT نہیں ہے تو تھرو کرتا ہے + assert owner != ZERO_ADDRESS + self._clearApproval(owner, _tokenId) + self._removeTokenFrom(owner, _tokenId) + log Transfer(owner, ZERO_ADDRESS, _tokenId) +``` + +جو کوئی بھی ٹوکن منتقل کرنے کی اجازت رکھتا ہے اسے اسے جلانے کی اجازت ہے۔ جبکہ ایک جلانے کا عمل صفر پتے پر منتقلی کے برابر لگتا ہے، صفر پتہ دراصل ٹوکن وصول نہیں کرتا ہے۔ یہ ہمیں ٹوکن کے لیے استعمال ہونے والے تمام اسٹوریج کو آزاد کرنے کی اجازت دیتا ہے، جو ٹرانزیکشن کی گیس لاگت کو کم کر سکتا ہے۔ + +## اس کنٹریکٹ کا استعمال {#using-contract} + +Solidity کے برعکس، Vyper میں وراثت نہیں ہے۔ یہ کوڈ کو واضح اور اس لیے محفوظ بنانے کے لیے ایک دانستہ ڈیزائن کا انتخاب ہے۔ لہذا اپنا خود کا Vyper ERC-721 کنٹریکٹ بنانے کے لیے آپ [اس کنٹریکٹ](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) کو لیتے ہیں اور اپنی مطلوبہ کاروباری منطق کو نافذ کرنے کے لیے اس میں ترمیم کرتے ہیں۔ + +## نتیجہ {#conclusion} + +جائزے کے لیے، اس کنٹریکٹ میں کچھ اہم ترین خیالات یہ ہیں: + +- محفوظ منتقلی کے ساتھ ERC-721 ٹوکن وصول کرنے کے لیے، کنٹریکٹس کو `ERC721Receiver` انٹرفیس کو نافذ کرنا ہوتا ہے۔ +- یہاں تک کہ اگر آپ محفوظ منتقلی کا استعمال کرتے ہیں، تب بھی ٹوکن پھنس سکتے ہیں اگر آپ انہیں ایک ایسے پتے پر بھیجتے ہیں جس کی نجی کلید معلوم نہیں ہے۔ +- جب کسی آپریشن میں کوئی مسئلہ ہو تو صرف ناکامی کی قدر واپس کرنے کے بجائے کال کو `واپس` کرنا ایک اچھا خیال ہے۔ +- ERC-721 ٹوکن تب موجود ہوتے ہیں جب ان کا کوئی مالک ہوتا ہے۔ +- ایک NFT منتقل کرنے کے لیے مجاز ہونے کے تین طریقے ہیں۔ آپ مالک ہو سکتے ہیں، ایک مخصوص ٹوکن کے لیے منظور شدہ ہو سکتے ہیں، یا مالک کے تمام ٹوکنز کے لیے آپریٹر ہو سکتے ہیں۔ +- ماضی کے واقعات صرف بلاک چین کے باہر نظر آتے ہیں۔ بلاک چین کے اندر چلنے والا کوڈ انہیں نہیں دیکھ سکتا۔ + +اب جائیں اور محفوظ Vyper کنٹریکٹس نافذ کریں۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ + diff --git a/public/content/translations/ur/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/ur/developers/tutorials/erc20-annotated-code/index.md new file mode 100644 index 00000000000..642c8568278 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/erc20-annotated-code/index.md @@ -0,0 +1,834 @@ +--- +title: "ERC-20 کنٹریکٹ واک تھرو" +description: "OpenZeppelin ERC-20 کنٹریکٹ میں کیا ہے اور یہ وہاں کیوں ہے؟" +author: Ori Pomerantz +lang: ur-in +tags: [ "solidity", "erc-20" ] +skill: beginner +published: 2021-03-09 +--- + +## تعارف {#introduction} + +ایتھیریم کے سب سے عام استعمالات میں سے ایک یہ ہے کہ ایک گروپ ایک قابل تجارت ٹوکن بنائے، ایک طرح سے ان کی اپنی کرنسی۔ یہ ٹوکنز عام طور پر ایک معیار کی پیروی کرتے ہیں، +[ERC-20](/developers/docs/standards/tokens/erc-20/)۔ یہ معیار ایسے ٹولز لکھنا ممکن بناتا ہے، جیسے لیکویڈیٹی پولز اور والیٹس، جو تمام ERC-20 +ٹوکنز کے ساتھ کام کرتے ہیں۔ اس مضمون میں ہم +[OpenZeppelin Solidity ERC20 امپلیمینٹیشن](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) کے ساتھ ساتھ +[انٹرفیس ڈیفینیشن](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) کا تجزیہ کریں گے۔ + +یہ اینوٹیٹیڈ سورس کوڈ ہے۔ اگر آپ ERC-20 کو امپلیمنٹ کرنا چاہتے ہیں، +[یہ ٹیوٹوریل پڑھیں](https://docs.openzeppelin.com/contracts/2.x/erc20-supply)۔ + +## انٹرفیس {#the-interface} + +ERC-20 جیسے معیار کا مقصد بہت سے ٹوکنز امپلیمینٹیشنز کی اجازت دینا ہے جو والیٹس اور ڈی سینٹرلائزڈ ایکسچینجز جیسی ایپلیکیشنز میں انٹرآپریبل ہیں۔ اسے حاصل کرنے کے لیے، ہم ایک +[انٹرفیس](https://www.geeksforgeeks.org/solidity/solidity-basics-of-interface/) بناتے ہیں۔ کوئی بھی کوڈ جسے ٹوکن کنٹریکٹ استعمال کرنے کی ضرورت ہے وہ انٹرفیس میں وہی ڈیفینیشنز استعمال کر سکتا ہے اور اسے استعمال کرنے والے تمام ٹوکن کنٹریکٹس کے ساتھ ہم آہنگ ہو سکتا ہے، چاہے وہ MetaMask جیسا والیٹ ہو، etherscan.io جیسا dapp ہو، یا لیکویڈیٹی پول جیسا کوئی مختلف کنٹریکٹ ہو۔ + +![ERC-20 انٹرفیس کی مثال](erc20_interface.png) + +اگر آپ ایک تجربہ کار پروگرامر ہیں، تو آپ کو شاید [Java](https://www.w3schools.com/java/java_interface.asp) یا یہاں تک کہ [C ہیڈر فائلز](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html) میں بھی اسی طرح کی کنسٹرکٹس دیکھنا یاد ہوگا۔ + +یہ OpenZeppelin سے [ERC-20 انٹرفیس](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) کی ایک ڈیفینیشن ہے۔ یہ [انسانی پڑھنے کے قابل معیار](https://eips.ethereum.org/EIPS/eip-20) کا Solidity کوڈ میں ترجمہ ہے۔ یقیناً، انٹرفیس خود یہ وضاحت نہیں کرتا ہے کہ _کیسے_ کچھ کرنا ہے۔ اس کی وضاحت نیچے کنٹریکٹ سورس کوڈ میں کی گئی ہے۔ + +  + +```solidity +// SPDX-License-Identifier: MIT +``` + +Solidity فائلوں میں لائسنس شناخت کنندہ شامل ہونا چاہیے۔ [آپ یہاں لائسنسوں کی فہرست دیکھ سکتے ہیں](https://spdx.org/licenses/)۔ اگر آپ کو کسی مختلف لائسنس کی ضرورت ہے تو تبصروں میں اس کی وضاحت کریں۔ + +  + +```solidity +pragma solidity >=0.6.0 <0.8.0; +``` + +Solidity زبان اب بھی تیزی سے ترقی کر رہی ہے، اور نئے ورژنز پرانے کوڈ کے ساتھ ہم آہنگ نہیں ہو سکتے ہیں +([یہاں دیکھیں](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html))۔ لہذا، یہ ایک اچھا خیال ہے کہ نہ صرف زبان کا کم از کم ورژن، بلکہ ایک زیادہ سے زیادہ ورژن بھی بیان کیا جائے، جس کے ساتھ آپ نے کوڈ کی جانچ کی ہے۔ + +  + +```solidity +/** + * @dev EIP میں بیان کردہ ERC20 معیار کا انٹرفیس۔ + */ +``` + +تبصرے میں `@dev` [NatSpec فارمیٹ](https://docs.soliditylang.org/en/develop/natspec-format.html) کا حصہ ہے، جو سورس کوڈ سے +ڈاکیومینٹیشن تیار کرنے کے لیے استعمال ہوتا ہے۔ + +  + +```solidity +interface IERC20 { +``` + +روایت کے مطابق، انٹرفیس کے نام `I` سے شروع ہوتے ہیں۔ + +  + +```solidity + /** + * @dev وجود میں موجود ٹوکنز کی مقدار واپس کرتا ہے۔ + */ + function totalSupply() external view returns (uint256); +``` + +یہ فنکشن `external` ہے، جس کا مطلب ہے [اسے صرف کنٹریکٹ کے باہر سے کال کیا جا سکتا ہے](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2)۔ +یہ کنٹریکٹ میں ٹوکنز کی کل سپلائی واپس کرتا ہے۔ یہ قدر Ethereum میں سب سے عام قسم، غیر دستخط شدہ 256 بٹس کا استعمال کرتے ہوئے واپس کی جاتی ہے (256 بٹس EVM کا +نیٹیو ورڈ سائز ہے)۔ یہ فنکشن ایک `view` بھی ہے، جس کا مطلب ہے کہ یہ اسٹیٹ کو تبدیل نہیں کرتا ہے، لہذا اسے بلاک چین کے ہر نوڈ پر چلانے کے بجائے ایک ہی نوڈ پر عمل میں لایا جا سکتا ہے۔ اس قسم کا فنکشن ٹرانزیکشن پیدا نہیں کرتا اور اس پر [گیس](/developers/docs/gas/) کی لاگت نہیں آتی۔ + +**نوٹ:** نظریاتی طور پر یہ ظاہر ہو سکتا ہے کہ کنٹریکٹ کا تخلیق کار اصل قدر سے کم کل سپلائی واپس کر کے دھوکہ دے سکتا ہے، جس سے ہر ٹوکن +اس کی اصل قیمت سے زیادہ قیمتی نظر آتا ہے۔ تاہم، یہ خوف بلاک چین کی حقیقی نوعیت کو نظر انداز کرتا ہے۔ بلاک چین پر ہونے والی ہر چیز کی تصدیق ہر نوڈ سے کی جا سکتی ہے۔ اسے حاصل کرنے کے لیے، ہر کنٹریکٹ کا مشین لینگویج کوڈ اور اسٹوریج ہر نوڈ پر دستیاب ہے۔ جبکہ آپ کو اپنے کنٹریکٹ کے لیے Solidity +کوڈ شائع کرنے کی ضرورت نہیں ہے، کوئی بھی آپ کو سنجیدگی سے نہیں لے گا جب تک کہ آپ سورس کوڈ اور Solidity کا وہ ورژن شائع نہ کریں جس کے ساتھ اسے کمپائل کیا گیا تھا، تاکہ اس کی آپ کے فراہم کردہ مشین لینگویج کوڈ سے تصدیق کی جا سکے۔ +مثال کے طور پر، [یہ کنٹریکٹ](https://eth.blockscout.com/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD?tab=contract) دیکھیں۔ + +  + +```solidity + /** + * @dev `account` کی ملکیت والے ٹوکنز کی مقدار واپس کرتا ہے۔ + */ + function balanceOf(address account) external view returns (uint256); +``` + +جیسا کہ نام سے ظاہر ہے، `balanceOf` ایک اکاؤنٹ کا بیلنس واپس کرتا ہے۔ Ethereum اکاؤنٹس کو Solidity میں `address` قسم کا استعمال کرتے ہوئے شناخت کیا جاتا ہے، جس میں 160 بٹس ہوتے ہیں۔ +یہ `external` اور `view` بھی ہے۔ + +  + +```solidity + /** + * @dev کالر کے اکاؤنٹ سے `recipient` کو `amount` ٹوکنز منتقل کرتا ہے۔ + * + * ایک بولین قدر واپس کرتا ہے جو یہ بتاتا ہے کہ آیا آپریشن کامیاب ہوا۔ + * + * ایک {Transfer} ایونٹ ایمٹ کرتا ہے۔ + */ + function transfer(address recipient, uint256 amount) external returns (bool); +``` + +`transfer` فنکشن کالر سے ٹوکنز کو ایک مختلف ایڈریس پر منتقل کرتا ہے۔ اس میں اسٹیٹ کی تبدیلی شامل ہے، لہذا یہ `view` نہیں ہے۔ +جب کوئی صارف اس فنکشن کو کال کرتا ہے تو یہ ایک ٹرانزیکشن بناتا ہے اور گیس کی لاگت آتی ہے۔ یہ ایک ایونٹ، `Transfer` بھی ایمٹ کرتا ہے، تاکہ بلاک چین پر ہر کسی کو ایونٹ کے بارے میں مطلع کیا جا سکے۔ + +فنکشن میں دو مختلف قسم کے کالرز کے لیے دو قسم کے آؤٹ پٹ ہیں: + +- صارفین جو فنکشن کو براہ راست صارف انٹرفیس سے کال کرتے ہیں۔ عام طور پر صارف ایک ٹرانزیکشن جمع کرتا ہے اور جواب کا انتظار نہیں کرتا، جس میں غیر معینہ مدت لگ سکتی ہے۔ صارف یہ دیکھ سکتا ہے کہ کیا ہوا ہے + ٹرانزیکشن کی رسید (جس کی شناخت ٹرانزیکشن ہیش سے ہوتی ہے) یا `Transfer` ایونٹ کو دیکھ کر۔ +- دوسرے کنٹریکٹس، جو فنکشن کو مجموعی ٹرانزیکشن کے حصے کے طور پر کال کرتے ہیں۔ ان کنٹریکٹس کو نتیجہ فوری طور پر مل جاتا ہے، + کیونکہ وہ اسی ٹرانزیکشن میں چلتے ہیں، لہذا وہ فنکشن کی واپسی کی قدر استعمال کر سکتے ہیں۔ + +اسی قسم کا آؤٹ پٹ دوسرے فنکشنز کے ذریعے بنایا جاتا ہے جو کنٹریکٹ کی اسٹیٹ کو تبدیل کرتے ہیں۔ + +  + +الاؤنسز ایک اکاؤنٹ کو کچھ ٹوکنز خرچ کرنے کی اجازت دیتے ہیں جو ایک مختلف مالک سے تعلق رکھتے ہیں۔ +یہ مفید ہے، مثال کے طور پر، ان کنٹریکٹس کے لیے جو بیچنے والے کے طور پر کام کرتے ہیں۔ کنٹریکٹس +ایونٹس کی نگرانی نہیں کر سکتے، لہذا اگر کوئی خریدار براہ راست بیچنے والے کنٹریکٹ کو ٹوکنز منتقل کرتا +ہے تو اس کنٹریکٹ کو معلوم نہیں ہوگا کہ اسے ادائیگی کی گئی ہے۔ اس کے بجائے، خریدار بیچنے والے کنٹریکٹ کو ایک مخصوص رقم خرچ کرنے کی اجازت دیتا ہے، اور بیچنے والا اس رقم کو منتقل کرتا ہے۔ +یہ ایک فنکشن کے ذریعے کیا جاتا ہے جسے بیچنے والا کنٹریکٹ کال کرتا ہے، تاکہ بیچنے والا کنٹریکٹ +جان سکے کہ آیا یہ کامیاب تھا۔ + +```solidity + /** + * @dev باقی ٹوکنز کی تعداد واپس کرتا ہے جو `spender` کو {transferFrom} کے ذریعے `owner` کی جانب سے خرچ کرنے کی اجازت ہوگی۔ یہ + * بطور ڈیفالٹ صفر ہے۔ + * + * یہ قدر اس وقت تبدیل ہوتی ہے جب {approve} یا {transferFrom} کو کال کیا جاتا ہے۔ + */ + function allowance(address owner, address spender) external view returns (uint256); +``` + +`allowance` فنکشن کسی کو بھی یہ دیکھنے کے لیے استفسار کرنے دیتا ہے کہ ایک +ایڈریس (`owner`) دوسرے ایڈریس (`spender`) کو خرچ کرنے کی کیا الاؤنس دیتا ہے۔ + +  + +```solidity + /** + * @dev کالر کے ٹوکنز پر `spender` کے الاؤنس کے طور پر `amount` سیٹ کرتا ہے۔ + * + * ایک بولین قدر واپس کرتا ہے جو یہ بتاتا ہے کہ آیا آپریشن کامیاب ہوا۔ + * + * اہم: خبردار رہیں کہ اس طریقے سے الاؤنس تبدیل کرنے سے یہ خطرہ لاحق ہوتا ہے + * کہ کوئی بدقسمت ٹرانزیکشن آرڈرنگ کے ذریعے پرانے اور نئے دونوں الاؤنس استعمال کر سکتا ہے۔ اس ریس + * کی حالت کو کم کرنے کا ایک ممکنہ حل یہ ہے کہ پہلے خرچ کرنے والے کے الاؤنس کو 0 تک کم کریں اور اس کے بعد + * مطلوبہ قدر سیٹ کریں: + * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 + * + * ایک {Approval} ایونٹ ایمٹ کرتا ہے۔ + */ + function approve(address spender, uint256 amount) external returns (bool); +``` + +`approve` فنکشن ایک الاؤنس بناتا ہے۔ اس کے بارے میں پیغام کو ضرور پڑھیں کہ اسے کیسے غلط استعمال کیا جا سکتا ہے۔ Ethereum میں آپ اپنی ٹرانزیکشنز کی ترتیب کو کنٹرول کرتے ہیں، +لیکن آپ اس ترتیب کو کنٹرول نہیں کر سکتے جس میں دوسرے لوگوں کی ٹرانزیکشنز پر عمل درآمد کیا جائے گا، +جب تک کہ آپ اپنی ٹرانزیکشن اس وقت تک جمع نہ کریں جب تک کہ آپ دوسری طرف کی ٹرانزیکشن کو نہ دیکھ لیں۔ + +  + +```solidity + /** + * @dev الاؤنس میکانزم کا استعمال کرتے ہوئے `sender` سے `recipient` کو `amount` ٹوکنز منتقل کرتا ہے۔ + * `amount` پھر کالر کے الاؤنس سے کاٹا جاتا ہے۔ + * + * ایک بولین قدر واپس کرتا ہے جو یہ بتاتا ہے کہ آیا آپریشن کامیاب ہوا۔ + * + * ایک {Transfer} ایونٹ ایمٹ کرتا ہے۔ + */ + function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); +``` + +آخر میں، `transferFrom` خرچ کرنے والے کے ذریعے الاؤنس کو حقیقت میں خرچ کرنے کے لیے استعمال کیا جاتا ہے۔ + +  + +```solidity + + /** + * @dev اس وقت ایمٹ ہوتا ہے جب `value` ٹوکنز ایک اکاؤنٹ (`from`) سے دوسرے (`to`) میں منتقل ہوتے ہیں۔ + * + * نوٹ کریں کہ `value` صفر ہو سکتا ہے۔ + */ + event Transfer(address indexed from, address indexed to, uint256 value); + + /** + * @dev اس وقت ایمٹ ہوتا ہے جب {approve} پر کال کے ذریعے ایک `owner` کے لیے `spender` کا الاؤنس سیٹ کیا جاتا ہے۔ `value` نیا الاؤنس ہے۔ + */ + event Approval(address indexed owner, address indexed spender, uint256 value); +} +``` + +یہ ایونٹس اس وقت ایمٹ ہوتے ہیں جب ERC-20 کنٹریکٹ کی اسٹیٹ تبدیل ہوتی ہے۔ + +## اصل کنٹریکٹ {#the-actual-contract} + +یہ اصل کنٹریکٹ ہے جو ERC-20 معیار کو لاگو کرتا ہے، +[یہاں سے لیا گیا ہے](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)۔ +اس کا مقصد جیسا ہے ویسا استعمال کرنا نہیں ہے، لیکن آپ اس سے +[انہیریٹ](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm) کر کے اسے کسی قابل استعمال چیز تک بڑھا سکتے ہیں۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity >=0.6.0 <0.8.0; +``` + +  + +### امپورٹ اسٹیٹمنٹس {#import-statements} + +اوپر دی گئی انٹرفیس ڈیفینیشنز کے علاوہ، کنٹریکٹ ڈیفینیشن دو دیگر فائلوں کو امپورٹ کرتی ہے: + +```solidity + +import "../../GSN/Context.sol"; +import "./IERC20.sol"; +import "../../math/SafeMath.sol"; +``` + +- `GSN/Context.sol` [OpenGSN](https://www.opengsn.org/) کو استعمال کرنے کے لیے درکار ڈیفینیشنز ہیں، ایک ایسا نظام جو ایتھر کے بغیر صارفین کو + بلاک چین استعمال کرنے کی اجازت دیتا ہے۔ نوٹ کریں کہ یہ ایک پرانا ورژن ہے، اگر آپ OpenGSN کے ساتھ انٹیگریٹ کرنا چاہتے ہیں تو + [یہ ٹیوٹوریل استعمال کریں](https://docs.opengsn.org/javascript-client/tutorial.html)۔ +- [SafeMath لائبریری](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/)، جو Solidity ورژنز **<0.8.0** کے لیے + اریتھمیٹک اوور فلو/انڈر فلو کو روکتی ہے۔ Solidity ≥0.8.0 میں، اریتھمیٹک آپریشنز خود بخود + اوور فلو/انڈر فلو پر ریورٹ ہو جاتے ہیں، جس سے SafeMath غیر ضروری ہو جاتا ہے۔ یہ کنٹریکٹ پرانے کمپائلر ورژنز کے ساتھ بیک ورڈ کمپیٹیبلٹی کے لیے SafeMath کا استعمال کرتا ہے۔ + +  + +یہ تبصرہ کنٹریکٹ کے مقصد کی وضاحت کرتا ہے۔ + +```solidity +/** + * @dev {IERC20} انٹرفیس کا امپلیمینٹیشن۔ + * + * یہ امپلیمینٹیشن اس طریقے سے اگنوسٹک ہے جس سے ٹوکنز بنائے جاتے ہیں۔ اس کا مطلب ہے + * کہ {_mint} کا استعمال کرتے ہوئے ایک ڈیریوڈ کنٹریکٹ میں ایک سپلائی میکانزم شامل کرنا ہوگا۔ + * ایک عام میکانزم کے لیے {ERC20PresetMinterPauser} دیکھیں۔ + * + * ٹپ: تفصیلی تحریر کے لیے ہماری گائیڈ دیکھیں + * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[سپلائی میکانزم کو کیسے + * لاگو کیا جائے]۔ + * + * ہم نے عام OpenZeppelin رہنما خطوط پر عمل کیا ہے: فنکشنز ناکامی پر `false` واپس کرنے کے بجائے + * ریورٹ کرتے ہیں۔ یہ طرز عمل بہرحال روایتی ہے + * اور ERC20 ایپلیکیشنز کی توقعات سے متصادم نہیں ہے۔ + * + * مزید برآں، {transferFrom} پر کالز پر ایک {Approval} ایونٹ ایمٹ ہوتا ہے۔ + * یہ ایپلیکیشنز کو صرف مذکورہ ایونٹس کو سن کر تمام اکاؤنٹس کے لیے الاؤنس کو دوبارہ بنانے کی اجازت دیتا ہے۔ EIP کی دیگر امپلیمینٹیشنز + * ان ایونٹس کو ایمٹ نہیں کر سکتی ہیں، کیونکہ اس کی تفصیلات میں ضرورت نہیں ہے۔ + * + * آخر میں، غیر معیاری {decreaseAllowance} اور {increaseAllowance} + * فنکشنز الاؤنس سیٹ کرنے کے ارد گرد معروف مسائل کو کم کرنے کے لیے شامل کیے گئے ہیں۔ + * {IERC20-approve} دیکھیں۔ + */ + +``` + +### کنٹریکٹ ڈیفینیشن {#contract-definition} + +```solidity +contract ERC20 is Context, IERC20 { +``` + +یہ لائن انہیریٹنس کی وضاحت کرتی ہے، اس معاملے میں اوپر سے `IERC20` اور OpenGSN کے لیے `Context` سے۔ + +  + +```solidity + + using SafeMath for uint256; + +``` + +یہ لائن `SafeMath` لائبریری کو `uint256` قسم سے منسلک کرتی ہے۔ آپ یہ لائبریری +[یہاں](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol) تلاش کر سکتے ہیں۔ + +### ویری ایبل ڈیفینیشنز {#variable-definitions} + +یہ ڈیفینیشنز کنٹریکٹ کے اسٹیٹ ویری ایبلز کی وضاحت کرتی ہیں۔ یہ ویری ایبلز `private` قرار دیے گئے ہیں، لیکن +اس کا صرف یہ مطلب ہے کہ بلاک چین پر موجود دوسرے کنٹریکٹس انہیں پڑھ نہیں سکتے۔ _بلاک چین پر کوئی راز نہیں ہیں_، ہر نوڈ پر موجود سافٹ ویئر میں ہر بلاک پر ہر کنٹریکٹ کی اسٹیٹ ہوتی ہے۔ روایت کے مطابق، اسٹیٹ ویری ایبلز کا نام `_` رکھا جاتا ہے۔ + +پہلے دو ویری ایبلز [میپنگز](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) ہیں، +یعنی وہ تقریباً [ایسوسی ایٹیو ایرے](https://wikipedia.org/wiki/Associative_array) کی طرح برتاؤ کرتے ہیں، +سوائے اس کے کہ کیز عددی قدریں ہیں۔ اسٹوریج صرف ان اندراجات کے لیے مختص کیا جاتا ہے جن کی قدریں ڈیفالٹ (صفر) سے مختلف ہوتی ہیں۔ + +```solidity + mapping (address => uint256) private _balances; +``` + +پہلی میپنگ، `_balances`، ایڈریسز اور اس ٹوکن کے ان کے متعلقہ بیلنسز ہیں۔ بیلنس تک رسائی کے لیے، یہ نحو استعمال کریں: `_balances[
]`۔ + +  + +```solidity + mapping (address => mapping (address => uint256)) private _allowances; +``` + +یہ ویری ایبل، `_allowances`، پہلے بیان کردہ الاؤنسز کو اسٹور کرتا ہے۔ پہلا انڈیکس ٹوکنز کا مالک ہے، اور دوسرا الاؤنس کے ساتھ کنٹریکٹ ہے۔ ایڈریس A کی رقم تک رسائی حاصل کرنے کے لیے جو وہ ایڈریس B کے اکاؤنٹ سے خرچ کر سکتا ہے، `_allowances[B][A]` استعمال کریں۔ + +  + +```solidity + uint256 private _totalSupply; +``` + +جیسا کہ نام سے پتہ چلتا ہے، یہ ویری ایبل ٹوکنز کی کل سپلائی کا ٹریک رکھتا ہے۔ + +  + +```solidity + string private _name; + string private _symbol; + uint8 private _decimals; +``` + +یہ تینوں ویری ایبلز پڑھنے کی اہلیت کو بہتر بنانے کے لیے استعمال کیے جاتے ہیں۔ پہلے دو خود وضاحتی ہیں، لیکن `_decimals` نہیں ہے۔ + +ایک طرف، Ethereum میں فلوٹنگ پوائنٹ یا فریکشنل ویری ایبلز نہیں ہیں۔ دوسری طرف، انسان ٹوکنز کو تقسیم کرنے کے قابل ہونا پسند کرتے ہیں۔ لوگوں کے کرنسی کے لیے سونے پر بسنے کی ایک وجہ یہ تھی کہ جب کوئی گائے کی قیمت کے برابر بطخ خریدنا چاہتا تھا تو چینج کرنا مشکل تھا۔ + +اس کا حل انٹیجرز کا ٹریک رکھنا ہے، لیکن اصلی ٹوکن کے بجائے ایک فریکشنل ٹوکن کو گننا ہے جو تقریباً بے قیمت ہے۔ ایتھر کے معاملے میں، فریکشنل ٹوکن کو wei کہا جاتا ہے، اور 10^18 wei ایک +ETH کے برابر ہے۔ لکھتے وقت، 10,000,000,000,000 wei تقریباً ایک امریکی یا یورو سینٹ کے برابر ہے۔ + +ایپلیکیشنز کو یہ جاننے کی ضرورت ہے کہ ٹوکن بیلنس کیسے دکھایا جائے۔ اگر کسی صارف کے پاس 3,141,000,000,000,000,000 wei ہیں، تو کیا یہ +3.14 ETH ہے؟ 31.41 ETH؟ 3,141 ETH؟ ایتھر کے معاملے میں یہ 10^18 wei سے ETH تک بیان کیا گیا ہے، لیکن اپنے +ٹوکن کے لیے آپ ایک مختلف قدر منتخب کر سکتے ہیں۔ اگر ٹوکن کو تقسیم کرنے کا کوئی مطلب نہیں ہے، تو آپ صفر کی `_decimals` قدر استعمال کر سکتے ہیں۔ اگر آپ ETH جیسا ہی معیار استعمال کرنا چاہتے ہیں تو **18** کی قدر استعمال کریں۔ + +### کنسٹرکٹر {#the-constructor} + +```solidity + /** + * @dev {name} اور {symbol} کے لیے قدریں سیٹ کرتا ہے، {decimals} کو 18 کی + * ڈیفالٹ قدر کے ساتھ انیشلائز کرتا ہے۔ + * + * {decimals} کے لیے ایک مختلف قدر منتخب کرنے کے لیے، {_setupDecimals} استعمال کریں۔ + * + * یہ تینوں قدریں ناقابل تغیر ہیں: انہیں صرف تعمیر کے دوران ایک بار سیٹ کیا جا سکتا ہے۔ + */ + constructor (string memory name_, string memory symbol_) public { + // Solidity ≥0.7.0 میں، 'public' مضمر ہے اور اسے چھوڑا جا سکتا ہے۔ + + _name = name_; + _symbol = symbol_; + _decimals = 18; + } +``` + +کنسٹرکٹر کو اس وقت کال کیا جاتا ہے جب کنٹریکٹ پہلی بار بنایا جاتا ہے۔ روایت کے مطابق، فنکشن پیرامیٹرز کا نام `_` رکھا جاتا ہے۔ + +### یوزر انٹرفیس فنکشنز {#user-interface-functions} + +```solidity + /** + * @dev ٹوکن کا نام واپس کرتا ہے۔ + */ + function name() public view returns (string memory) { + return _name; + } + + /** + * @dev ٹوکن کی علامت واپس کرتا ہے، عام طور پر نام کا ایک چھوٹا ورژن۔ + */ + function symbol() public view returns (string memory) { + return _symbol; + } + + /** + * @dev اس کی صارف کی نمائندگی حاصل کرنے کے لیے استعمال ہونے والے ڈیسیملز کی تعداد واپس کرتا ہے۔ + * مثال کے طور پر، اگر `decimals` `2` کے برابر ہے، تو `505` ٹوکنز کا بیلنس + * صارف کو `5,05` (`505 / 10 ** 2`) کے طور پر دکھایا جانا چاہیے۔ + * + * ٹوکنز عام طور پر 18 کی قدر کا انتخاب کرتے ہیں، جو ایتھر اور wei کے درمیان تعلق کی نقل کرتا ہے۔ + * یہ وہ قدر ہے جسے {ERC20} استعمال کرتا ہے، جب تک کہ {_setupDecimals} کو کال نہ کیا جائے۔ + * + * نوٹ: یہ معلومات صرف _ڈسپلے_ کے مقاصد کے لیے استعمال ہوتی ہیں: یہ کسی بھی طرح + * کنٹریکٹ کے کسی بھی اریتھمیٹک کو متاثر نہیں کرتی ہے، بشمول + * {IERC20-balanceOf} اور {IERC20-transfer}۔ + */ + function decimals() public view returns (uint8) { + return _decimals; + } +``` + +یہ فنکشنز، `name`، `symbol`، اور `decimals` یوزر انٹرفیسز کو آپ کے کنٹریکٹ کے بارے میں جاننے میں مدد کرتے ہیں تاکہ وہ اسے صحیح طریقے سے ڈسپلے کر سکیں۔ + +ریٹرن کی قسم `string memory` ہے، یعنی ایک سٹرنگ ریٹرن کریں جو میموری میں اسٹور ہے۔ ویری ایبلز، جیسے سٹرنگز، کو تین جگہوں پر اسٹور کیا جا سکتا ہے: + +| | لائف ٹائم | کنٹریکٹ تک رسائی | گیس کی لاگت | +| -------- | ------------- | ---------------- | ---------------------------------------------------------------------- | +| میموری | فنکشن کال | پڑھنا/لکھنا | دس یا سو (اونچی جگہوں کے لیے زیادہ) | +| کال ڈیٹا | فنکشن کال | صرف پڑھنا | ریٹرن ٹائپ کے طور پر استعمال نہیں کیا جا سکتا، صرف فنکشن پیرامیٹر ٹائپ | +| اسٹوریج | تبدیل ہونے تک | پڑھنا/لکھنا | زیادہ (پڑھنے کے لیے 800، لکھنے کے لیے 20k) | + +اس معاملے میں، `memory` بہترین انتخاب ہے۔ + +### ٹوکن کی معلومات پڑھیں {#read-token-information} + +یہ وہ فنکشنز ہیں جو ٹوکن کے بارے میں معلومات فراہم کرتے ہیں، یا تو کل سپلائی یا کسی +اکاؤنٹ کا بیلنس۔ + +```solidity + /** + * @dev {IERC20-totalSupply} دیکھیں۔ + */ + function totalSupply() public view override returns (uint256) { + return _totalSupply; + } +``` + +`totalSupply` فنکشن ٹوکنز کی کل سپلائی واپس کرتا ہے۔ + +  + +```solidity + /** + * @dev {IERC20-balanceOf} دیکھیں۔ + */ + function balanceOf(address account) public view override returns (uint256) { + return _balances[account]; + } +``` + +ایک اکاؤنٹ کا بیلنس پڑھیں۔ نوٹ کریں کہ کسی کو بھی کسی دوسرے کے اکاؤنٹ کا بیلنس حاصل کرنے کی اجازت ہے۔ اس معلومات کو چھپانے کی کوشش کرنے کا کوئی فائدہ نہیں، کیونکہ یہ ہر نوڈ پر ویسے بھی دستیاب ہے۔ _بلاک چین پر کوئی راز نہیں ہے۔_ + +### ٹوکنز منتقل کریں {#transfer-tokens} + +```solidity + /** + * @dev {IERC20-transfer} دیکھیں۔ + * + * تقاضے: + * + * - `recipient` صفر ایڈریس نہیں ہو سکتا۔ + * - کالر کے پاس کم از کم `amount` کا بیلنس ہونا چاہیے۔ + */ + function transfer(address recipient, uint256 amount) public virtual override returns (bool) { +``` + +`transfer` فنکشن کو بھیجنے والے کے اکاؤنٹ سے ٹوکنز کو کسی دوسرے اکاؤنٹ میں منتقل کرنے کے لیے کال کیا جاتا ہے۔ نوٹ کریں کہ اگرچہ یہ ایک بولین قدر واپس کرتا ہے، وہ قدر ہمیشہ **true** ہوتی ہے۔ اگر منتقلی ناکام ہو جاتی ہے تو کنٹریکٹ کال کو ریورٹ کر دیتا ہے۔ + +  + +```solidity + _transfer(_msgSender(), recipient, amount); + return true; + } +``` + +`_transfer` فنکشن اصل کام کرتا ہے۔ یہ ایک پرائیویٹ فنکشن ہے جسے صرف دوسرے کنٹریکٹ فنکشنز کے ذریعے کال کیا جا سکتا ہے۔ روایت کے مطابق پرائیویٹ فنکشنز کا نام `_` رکھا جاتا ہے، بالکل اسٹیٹ ویری ایبلز کی طرح۔ + +عام طور پر Solidity میں ہم میسج بھیجنے والے کے لیے `msg.sender` استعمال کرتے ہیں۔ تاہم، یہ [OpenGSN](http://opengsn.org/) کو توڑتا ہے۔ اگر ہم اپنے ٹوکن کے ساتھ ایتھر لیس ٹرانزیکشنز کی اجازت دینا چاہتے ہیں، تو ہمیں `_msgSender()` استعمال کرنے کی ضرورت ہے۔ یہ عام ٹرانزیکشنز کے لیے `msg.sender` واپس کرتا ہے، لیکن ایتھر لیس ٹرانزیکشنز کے لیے اصل دستخط کنندہ واپس کرتا ہے نہ کہ وہ کنٹریکٹ جس نے میسج ریلے کیا۔ + +### الاؤنس فنکشنز {#allowance-functions} + +یہ وہ فنکشنز ہیں جو الاؤنس کی فعالیت کو لاگو کرتے ہیں: `allowance`، `approve`، `transferFrom`، اور `_approve`۔ مزید برآں، OpenZeppelin کا امپلیمینٹیشن بنیادی معیار سے آگے بڑھ کر کچھ خصوصیات شامل کرتا ہے جو سیکیورٹی کو بہتر بناتی ہیں: `increaseAllowance`، اور `decreaseAllowance`۔ + +#### الاؤنس فنکشن {#allowance} + +```solidity + /** + * @dev {IERC20-allowance} دیکھیں۔ + */ + function allowance(address owner, address spender) public view virtual override returns (uint256) { + return _allowances[owner][spender]; + } +``` + +`allowance` فنکشن ہر کسی کو کسی بھی الاؤنس کو چیک کرنے کی اجازت دیتا ہے۔ + +#### approve فنکشن {#approve} + +```solidity + /** + * @dev {IERC20-approve} دیکھیں۔ + * + * تقاضے: + * + * - `spender` صفر ایڈریس نہیں ہو سکتا۔ + */ + function approve(address spender, uint256 amount) public virtual override returns (bool) { +``` + +یہ فنکشن الاؤنس بنانے کے لیے کال کیا جاتا ہے۔ یہ اوپر دیے گئے `transfer` فنکشن سے ملتا جلتا ہے: + +- فنکشن صرف ایک اندرونی فنکشن (اس معاملے میں، `_approve`) کو کال کرتا ہے جو اصل کام کرتا ہے۔ +- فنکشن یا تو `true` (اگر کامیاب ہو) واپس کرتا ہے یا ریورٹ (اگر نہیں)۔ + +  + +```solidity + _approve(_msgSender(), spender, amount); + return true; + } +``` + +ہم اندرونی فنکشنز کا استعمال ان جگہوں کی تعداد کو کم سے کم کرنے کے لیے کرتے ہیں جہاں اسٹیٹ کی تبدیلیاں ہوتی ہیں۔ _کوئی بھی_ فنکشن جو اسٹیٹ کو تبدیل کرتا ہے وہ ایک ممکنہ سیکیورٹی رسک ہے جس کا سیکیورٹی کے لیے آڈٹ کرنے کی ضرورت ہے۔ اس طرح ہمارے پاس غلط ہونے کے امکانات کم ہیں۔ + +#### transferFrom فنکشن {#transferFrom} + +یہ وہ فنکشن ہے جسے ایک خرچ کرنے والا الاؤنس خرچ کرنے کے لیے کال کرتا ہے۔ اس کے لیے دو آپریشنز کی ضرورت ہے: خرچ کی جانے والی رقم کو منتقل کریں اور الاؤنس کو اس رقم سے کم کریں۔ + +```solidity + /** + * @dev {IERC20-transferFrom} دیکھیں۔ + * + * اپ ڈیٹ شدہ الاؤنس کی نشاندہی کرنے والا ایک {Approval} ایونٹ ایمٹ کرتا ہے۔ یہ + * EIP کے ذریعہ ضروری نہیں ہے۔ {ERC20} کے آغاز میں نوٹ دیکھیں۔ + * + * تقاضے: + * + * - `sender` اور `recipient` صفر ایڈریس نہیں ہو سکتے۔ + * - `sender` کے پاس کم از کم `amount` کا بیلنس ہونا چاہیے۔ + * - کالر کے پاس کم از کم `amount` کے `sender` کے ٹوکنز کے لیے الاؤنس ہونا چاہیے۔ + */ + function transferFrom(address sender, address recipient, uint256 amount) public virtual + override returns (bool) { + _transfer(sender, recipient, amount); +``` + +  + +`a.sub(b, "message")` فنکشن کال دو کام کرتی ہے۔ سب سے پہلے، یہ `a-b` کا حساب لگاتا ہے، جو کہ نیا الاؤنس ہے۔ +دوسرا، یہ چیک کرتا ہے کہ یہ نتیجہ منفی نہیں ہے۔ اگر یہ منفی ہے تو کال فراہم کردہ میسج کے ساتھ ریورٹ ہو جاتی ہے۔ نوٹ کریں کہ جب کوئی کال ریورٹ ہوتی ہے تو اس کال کے دوران پہلے کی گئی کوئی بھی پروسیسنگ نظر انداز کر دی جاتی ہے لہذا ہمیں `_transfer` کو انڈو کرنے کی ضرورت نہیں ہے۔ + +```solidity + _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, + "ERC20: منتقلی کی رقم الاؤنس سے زیادہ ہے")); + return true; + } +``` + +#### OpenZeppelin سیفٹی ایڈیشنز {#openzeppelin-safety-additions} + +ایک غیر صفر الاؤنس کو دوسری غیر صفر قدر پر سیٹ کرنا خطرناک ہے، +کیونکہ آپ صرف اپنی ٹرانزیکشنز کی ترتیب کو کنٹرول کرتے ہیں، کسی اور کی نہیں۔ تصور کریں کہ آپ کے پاس دو صارفین ہیں، ایلس جو سادہ لوح ہے اور بل جو بے ایمان ہے۔ ایلس بل سے کچھ سروس چاہتی ہے، جس کے بارے میں وہ سوچتی ہے کہ اس کی قیمت پانچ ٹوکن ہے - لہذا وہ بل کو پانچ ٹوکن کا الاؤنس دیتی ہے۔ + +پھر کچھ بدلتا ہے اور بل کی قیمت دس ٹوکن تک بڑھ جاتی ہے۔ ایلس، جو اب بھی سروس چاہتی ہے، ایک ٹرانزیکشن بھیجتی ہے جو بل کے الاؤنس کو دس پر سیٹ کرتی ہے۔ جس لمحے بل اس نئی ٹرانزیکشن کو ٹرانزیکشن پول میں دیکھتا ہے وہ ایک ٹرانزیکشن بھیجتا ہے جو ایلس کے پانچ ٹوکن خرچ کرتا ہے اور اس کی گیس کی قیمت بہت زیادہ ہے تاکہ اسے تیزی سے مائن کیا جا سکے۔ اس طرح بل پہلے پانچ ٹوکن خرچ کر سکتا ہے اور پھر، جب ایلس کا نیا الاؤنس مائن ہو جاتا ہے، تو پندرہ ٹوکن کی کل قیمت کے لیے دس مزید خرچ کر سکتا ہے، جو ایلس کی اجازت سے زیادہ ہے۔ اس تکنیک کو [فرنٹ رننگ](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running) کہا جاتا ہے + +| ایلس ٹرانزیکشن | ایلس نانس | بل ٹرانزیکشن | بل نانس | بل کا الاؤنس | ایلس سے بل کی کل آمدنی | +| ------------------------------------ | --------- | ------------------------------------------------ | ------- | ------------ | ---------------------- | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | +| approve(Bill, 10) | 11 | | | 10 | 5 | +| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 | + +اس مسئلے سے بچنے کے لیے، یہ دو فنکشنز (`increaseAllowance` اور `decreaseAllowance`) آپ کو ایک مخصوص رقم سے الاؤنس میں ترمیم کرنے کی اجازت دیتے ہیں۔ لہذا اگر بل نے پہلے ہی پانچ ٹوکن خرچ کر لیے ہیں، تو وہ صرف پانچ مزید خرچ کر سکے گا۔ ٹائمنگ پر منحصر ہے، اس کے کام کرنے کے دو طریقے ہیں، دونوں کا اختتام بل کو صرف دس ٹوکن ملنے پر ہوتا ہے: + +A: + +| ایلس ٹرانزیکشن | ایلس نانس | بل ٹرانزیکشن | بل نانس | بل کا الاؤنس | ایلس سے بل کی کل آمدنی | +| --------------------------------------------- | --------: | ----------------------------------------------- | ------: | -----------: | ---------------------- | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | +| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 | +| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 | + +B: + +| ایلس ٹرانزیکشن | ایلس نانس | بل ٹرانزیکشن | بل نانس | بل کا الاؤنس | ایلس سے بل کی کل آمدنی | +| --------------------------------------------- | --------: | ------------------------------------------------ | ------: | -----------: | ---------------------: | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 | +| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 | + +```solidity + /** + * @dev کالر کے ذریعہ `spender` کو دیے گئے الاؤنس کو ایٹامک طور پر بڑھاتا ہے۔ + * + * یہ {approve} کا ایک متبادل ہے جسے {IERC20-approve} میں بیان کردہ مسائل کے + * ازالے کے طور پر استعمال کیا جا سکتا ہے۔ + * + * اپ ڈیٹ شدہ الاؤنس کی نشاندہی کرنے والا ایک {Approval} ایونٹ ایمٹ کرتا ہے۔ + * + * تقاضے: + * + * - `spender` صفر ایڈریس نہیں ہو سکتا۔ + */ + function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) { + _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue)); + return true; + } +``` + +`a.add(b)` فنکشن ایک محفوظ اضافہ ہے۔ اس غیر امکانی صورت میں کہ `a`+`b`>=`2^256` یہ اس طرح سے ریپ نہیں ہوتا جس طرح عام اضافہ ہوتا ہے۔ + +```solidity + + /** + * @dev کالر کے ذریعہ `spender` کو دیے گئے الاؤنس کو ایٹامک طور پر کم کرتا ہے۔ + * + * یہ {approve} کا ایک متبادل ہے جسے {IERC20-approve} میں بیان کردہ مسائل کے + * ازالے کے طور پر استعمال کیا جا سکتا ہے۔ + * + * اپ ڈیٹ شدہ الاؤنس کی نشاندہی کرنے والا ایک {Approval} ایونٹ ایمٹ کرتا ہے۔ + * + * تقاضے: + * + * - `spender` صفر ایڈریس نہیں ہو سکتا۔ + * - `spender` کے پاس کالر کے لیے کم از کم `subtractedValue` کا الاؤنس ہونا چاہیے۔ + */ + function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) { + _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, + "ERC20: الاؤنس صفر سے کم ہو گیا")); + return true; + } +``` + +### ٹوکن کی معلومات میں ترمیم کرنے والے فنکشنز {#functions-that-modify-token-information} + +یہ وہ چار فنکشنز ہیں جو اصل کام کرتے ہیں: `_transfer`، `_mint`، `_burn`، اور `_approve`۔ + +#### _transfer فنکشن {#_transfer} + +```solidity + /** + * @dev `sender` سے `recipient` کو `amount` ٹوکنز منتقل کرتا ہے۔ + * + * یہ اندرونی فنکشن {transfer} کے برابر ہے، اور اسے + * مثلاً، خودکار ٹوکن فیس، سلیشنگ میکانزم وغیرہ کو لاگو کرنے کے لیے استعمال کیا جا سکتا ہے۔ + * + * ایک {Transfer} ایونٹ ایمٹ کرتا ہے۔ + * + * تقاضے: + * + * - `sender` صفر ایڈریس نہیں ہو سکتا۔ + * - `recipient` صفر ایڈریس نہیں ہو سکتا۔ + * - `sender` کے پاس کم از کم `amount` کا بیلنس ہونا چاہیے۔ + */ + function _transfer(address sender, address recipient, uint256 amount) internal virtual { +``` + +یہ فنکشن، `_transfer`، ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں ٹوکنز منتقل کرتا ہے۔ اسے `transfer` (بھیجنے والے کے اپنے اکاؤنٹ سے منتقلی کے لیے) اور `transferFrom` (کسی اور کے اکاؤنٹ سے منتقلی کے لیے الاؤنسز کا استعمال کرتے ہوئے) دونوں کے ذریعے کال کیا جاتا ہے۔ + +  + +```solidity + require(sender != address(0), "ERC20: صفر ایڈریس سے منتقلی"); + require(recipient != address(0), "ERC20: صفر ایڈریس پر منتقلی"); +``` + +Ethereum میں کوئی بھی حقیقت میں صفر ایڈریس کا مالک نہیں ہے (یعنی، کوئی بھی ایسی پرائیویٹ کلید نہیں جانتا جس کی مماثل پبلک کلید کو صفر ایڈریس میں تبدیل کیا گیا ہو)۔ جب لوگ اس ایڈریس کا استعمال کرتے ہیں، تو یہ عام طور پر ایک سافٹ ویئر بگ ہوتا ہے - لہذا اگر صفر ایڈریس بھیجنے والے یا وصول کنندہ کے طور پر استعمال کیا جاتا ہے تو ہم ناکام ہو جاتے ہیں۔ + +  + +```solidity + _beforeTokenTransfer(sender, recipient, amount); + +``` + +اس کنٹریکٹ کو استعمال کرنے کے دو طریقے ہیں: + +1. اسے اپنے کوڈ کے لیے بطور ٹیمپلیٹ استعمال کریں +2. [اس سے انہیریٹ کریں](https://www.bitdegree.org/learn/solidity-inheritance)، اور صرف ان فنکشنز کو اوور رائڈ کریں جن میں آپ کو ترمیم کرنے کی ضرورت ہے۔ + +دوسرا طریقہ بہت بہتر ہے کیونکہ OpenZeppelin ERC-20 کوڈ کا پہلے ہی آڈٹ کیا جا چکا ہے اور اسے محفوظ دکھایا گیا ہے۔ جب آپ انہیریٹنس استعمال کرتے ہیں تو یہ واضح ہوتا ہے کہ آپ کن فنکشنز میں ترمیم کرتے ہیں، اور اپنے کنٹریکٹ پر بھروسہ کرنے کے لیے لوگوں کو صرف ان مخصوص فنکشنز کا آڈٹ کرنے کی ضرورت ہوتی ہے۔ + +ہر بار جب ٹوکنز ہاتھ بدلتے ہیں تو ایک فنکشن انجام دینا اکثر مفید ہوتا ہے۔ تاہم، `_transfer` ایک بہت اہم فنکشن ہے اور اسے غیر محفوظ طریقے سے لکھنا ممکن ہے (نیچے دیکھیں)، لہذا اسے اوور رائڈ نہ کرنا بہتر ہے۔ اس کا حل `_beforeTokenTransfer` ہے، ایک [ہک فنکشن](https://wikipedia.org/wiki/Hooking)۔ آپ اس فنکشن کو اوور رائڈ کر سکتے ہیں، اور اسے ہر منتقلی پر کال کیا جائے گا۔ + +  + +```solidity + _balances[sender] = _balances[sender].sub(amount, "ERC20: منتقلی کی رقم بیلنس سے زیادہ ہے"); + _balances[recipient] = _balances[recipient].add(amount); +``` + +یہ وہ لائنیں ہیں جو اصل میں منتقلی کرتی ہیں۔ نوٹ کریں کہ ان کے درمیان **کچھ بھی نہیں** ہے، اور یہ کہ ہم منتقل شدہ رقم کو وصول کنندہ میں شامل کرنے سے پہلے بھیجنے والے سے گھٹاتے ہیں۔ یہ اہم ہے کیونکہ اگر درمیان میں کسی دوسرے کنٹریکٹ کو کال کیا جاتا تو اسے اس کنٹریکٹ کو دھوکہ دینے کے لیے استعمال کیا جا سکتا تھا۔ اس طرح منتقلی ایٹامک ہوتی ہے، اس کے بیچ میں کچھ نہیں ہو سکتا۔ + +  + +```solidity + emit Transfer(sender, recipient, amount); + } +``` + +آخر میں، ایک `Transfer` ایونٹ ایمٹ کریں۔ ایونٹس اسمارٹ کنٹریکٹس کے لیے قابل رسائی نہیں ہیں، لیکن بلاک چین کے باہر چلنے والا کوڈ ایونٹس کو سن سکتا ہے اور ان پر رد عمل ظاہر کر سکتا ہے۔ مثال کے طور پر، ایک والیٹ اس بات کا ٹریک رکھ سکتا ہے کہ مالک کو کب مزید ٹوکنز ملتے ہیں۔ + +#### _mint اور _burn فنکشنز {#_mint-and-_burn} + +یہ دو فنکشنز (`_mint` اور `_burn`) ٹوکنز کی کل سپلائی میں ترمیم کرتے ہیں۔ +یہ اندرونی ہیں اور اس کنٹریکٹ میں انہیں کال کرنے والا کوئی فنکشن نہیں ہے، لہذا یہ صرف اس صورت میں مفید ہیں جب آپ کنٹریکٹ سے انہیریٹ کریں اور یہ فیصلہ کرنے کے لیے اپنی منطق شامل کریں کہ کن حالات میں نئے ٹوکنز منٹ کیے جائیں یا موجودہ کو برن کیا جائے۔ + +**نوٹ:** ہر ERC-20 ٹوکن کی اپنی کاروباری منطق ہوتی ہے جو ٹوکن مینجمنٹ کا حکم دیتی ہے۔ +مثال کے طور پر، ایک فکسڈ سپلائی کنٹریکٹ کنسٹرکٹر میں صرف `_mint` کو کال کر سکتا ہے اور کبھی بھی `_burn` کو کال نہیں کرتا۔ ایک کنٹریکٹ جو ٹوکن بیچتا ہے وہ ادائیگی ہونے پر `_mint` کو کال کرے گا، اور قیاس ہے کہ کسی وقت `_burn` کو کال کرے گا تاکہ بے قابو افراط زر سے بچا جا سکے۔ + +```solidity + /** @dev `amount` ٹوکنز بناتا ہے اور انہیں `account` کو تفویض کرتا ہے، کل سپلائی + * میں اضافہ کرتا ہے۔ + * + * ایک {Transfer} ایونٹ ایمٹ کرتا ہے جس میں `from` کو صفر ایڈریس پر سیٹ کیا جاتا ہے۔ + * + * تقاضے: + * + * - `to` صفر ایڈریس نہیں ہو سکتا۔ + */ + function _mint(address account, uint256 amount) internal virtual { + require(account != address(0), "ERC20: صفر ایڈریس پر منٹ کریں"); + _beforeTokenTransfer(address(0), account, amount); + _totalSupply = _totalSupply.add(amount); + _balances[account] = _balances[account].add(amount); + emit Transfer(address(0), account, amount); + } +``` + +جب ٹوکنز کی کل تعداد تبدیل ہو تو `_totalSupply` کو اپ ڈیٹ کرنا یقینی بنائیں۔ + +  + +```solidity + /** + * @dev `account` سے `amount` ٹوکنز کو تباہ کرتا ہے، کل سپلائی کو + * کم کرتا ہے۔ + * + * ایک {Transfer} ایونٹ ایمٹ کرتا ہے جس میں `to` کو صفر ایڈریس پر سیٹ کیا جاتا ہے۔ + * + * تقاضے: + * + * - `account` صفر ایڈریس نہیں ہو سکتا۔ + * - `account` کے پاس کم از کم `amount` ٹوکنز ہونے چاہئیں۔ + */ + function _burn(address account, uint256 amount) internal virtual { + require(account != address(0), "ERC20: صفر ایڈریس سے برن کریں"); + + _beforeTokenTransfer(account, address(0), amount); + + _balances[account] = _balances[account].sub(amount, "ERC20: برن کی رقم بیلنس سے زیادہ ہے"); + _totalSupply = _totalSupply.sub(amount); + emit Transfer(account, address(0), amount); + } +``` + +`_burn` فنکشن تقریباً `_mint` کی طرح ہے، سوائے اس کے کہ یہ دوسری سمت میں جاتا ہے۔ + +#### _approve فنکشن {#_approve} + +یہ وہ فنکشن ہے جو اصل میں الاؤنسز کی وضاحت کرتا ہے۔ نوٹ کریں کہ یہ مالک کو ایک ایسا الاؤنس بیان کرنے کی اجازت دیتا ہے جو مالک کے موجودہ بیلنس سے زیادہ ہے۔ یہ ٹھیک ہے کیونکہ بیلنس منتقلی کے وقت چیک کیا جاتا ہے، جب یہ الاؤنس بنائے جانے کے وقت کے بیلنس سے مختلف ہو سکتا ہے۔ + +```solidity + /** + * @dev `owner` کے ٹوکنز پر `spender` کے الاؤنس کے طور پر `amount` سیٹ کرتا ہے۔ + * + * یہ اندرونی فنکشن `approve` کے برابر ہے، اور اسے + * مثلاً، کچھ سب سسٹمز کے لیے خودکار الاؤنس سیٹ کرنے وغیرہ کے لیے استعمال کیا جا سکتا ہے۔ + * + * ایک {Approval} ایونٹ ایمٹ کرتا ہے۔ + * + * تقاضے: + * + * - `owner` صفر ایڈریس نہیں ہو سکتا۔ + * - `spender` صفر ایڈریس نہیں ہو سکتا۔ + */ + function _approve(address owner, address spender, uint256 amount) internal virtual { + require(owner != address(0), "ERC20: صفر ایڈریس سے منظور کریں"); + require(spender != address(0), "ERC20: صفر ایڈریس پر منظور کریں"); + + _allowances[owner][spender] = amount; +``` + +  + +ایک `Approval` ایونٹ ایمٹ کریں۔ ایپلیکیشن کیسے لکھی جاتی ہے اس پر منحصر ہے، خرچ کرنے والے کنٹریکٹ کو منظوری کے بارے میں یا تو مالک کے ذریعے بتایا جا سکتا ہے یا ایک سرور کے ذریعے جو ان ایونٹس کو سنتا ہے۔ + +```solidity + emit Approval(owner, spender, amount); + } + +``` + +### ڈیسیملز ویری ایبل میں ترمیم کریں {#modify-the-decimals-variable} + +```solidity + + + /** + * @dev {decimals} کو 18 کی ڈیفالٹ قدر کے علاوہ کسی اور قدر پر سیٹ کرتا ہے۔ + * + * انتباہ: اس فنکشن کو صرف کنسٹرکٹر سے کال کیا جانا چاہیے۔ زیادہ تر + * ایپلیکیشنز جو ٹوکن کنٹریکٹس کے ساتھ تعامل کرتی ہیں وہ توقع نہیں کریں گی کہ + * {decimals} کبھی تبدیل ہو، اور اگر ایسا ہوتا ہے تو وہ غلط طریقے سے کام کر سکتی ہیں۔ + */ + function _setupDecimals(uint8 decimals_) internal { + _decimals = decimals_; + } +``` + +یہ فنکشن `_decimals` ویری ایبل میں ترمیم کرتا ہے جو یوزر انٹرفیس کو یہ بتانے کے لیے استعمال ہوتا ہے کہ رقم کی تشریح کیسے کی جائے۔ +آپ کو اسے کنسٹرکٹر سے کال کرنا چاہیے۔ اسے کسی بھی بعد کے مقام پر کال کرنا بے ایمانی ہوگی، اور ایپلیکیشنز اسے سنبھالنے کے لیے ڈیزائن نہیں کی گئی ہیں۔ + +### ہکس {#hooks} + +```solidity + + /** + * @dev ہک جو ٹوکنز کی کسی بھی منتقلی سے پہلے کال کیا جاتا ہے۔ اس میں + * منٹنگ اور برننگ شامل ہیں۔ + * + * کالنگ کی شرائط: + * + * - جب `from` اور `to` دونوں غیر صفر ہوں، تو `from` کے `amount` ٹوکنز + * `to` کو منتقل کیے جائیں گے۔ + * - جب `from` صفر ہو، تو `to` کے لیے `amount` ٹوکنز منٹ کیے جائیں گے۔ + * - جب `to` صفر ہو، تو `from` کے `amount` ٹوکنز برن کیے جائیں گے۔ + * - `from` اور `to` کبھی بھی دونوں صفر نہیں ہوتے۔ + * + * ہکس کے بارے میں مزید جاننے کے لیے، xref:ROOT:extending-contracts.adoc#using-hooks[ہکس کا استعمال] پر جائیں۔ + */ + function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { } +} +``` + +یہ منتقلی کے دوران کال کیا جانے والا ہک فنکشن ہے۔ یہ یہاں خالی ہے، لیکن اگر آپ کو اس سے کچھ کروانے کی ضرورت ہے تو آپ اسے صرف اوور رائڈ کرتے ہیں۔ + +## نتیجہ {#conclusion} + +جائزے کے لیے، اس کنٹریکٹ میں کچھ اہم ترین خیالات یہ ہیں (میری رائے میں، آپ کی رائے مختلف ہو سکتی ہے): + +- _بلاک چین پر کوئی راز نہیں ہوتے_۔ کوئی بھی معلومات جس تک ایک اسمارٹ کنٹریکٹ رسائی حاصل کر سکتا ہے وہ پوری دنیا کے لیے دستیاب ہے۔ +- آپ اپنی ٹرانزیکشنز کی ترتیب کو کنٹرول کر سکتے ہیں، لیکن یہ نہیں کہ دوسرے لوگوں کی ٹرانزیکشن کب ہوتی ہے۔ یہی وجہ ہے کہ الاؤنس تبدیل کرنا خطرناک ہو سکتا ہے، کیونکہ یہ خرچ کرنے والے کو دونوں الاؤنسز کی رقم خرچ کرنے دیتا ہے۔ +- `uint256` قسم کی قدریں ریپ ہوتی ہیں۔ دوسرے لفظوں میں، _0-1=2^256-1_۔ اگر یہ مطلوبہ طرز عمل نہیں ہے، تو آپ کو اس کی جانچ کرنی ہوگی (یا SafeMath لائبریری کا استعمال کرنا ہوگا جو آپ کے لیے یہ کرتی ہے)۔ نوٹ کریں کہ یہ [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html) میں تبدیل ہو گیا ہے۔ +- ایک مخصوص قسم کی تمام اسٹیٹ تبدیلیاں ایک مخصوص جگہ پر کریں، کیونکہ اس سے آڈٹ کرنا آسان ہو جاتا ہے۔ + یہی وجہ ہے کہ ہمارے پاس، مثال کے طور پر، `_approve` ہے، جسے `approve`، `transferFrom`، `increaseAllowance`، اور `decreaseAllowance` کے ذریعے کال کیا جاتا ہے +- اسٹیٹ کی تبدیلیاں ایٹامک ہونی چاہئیں، ان کے درمیان کوئی اور عمل نہیں ہونا چاہیے (جیسا کہ آپ `_transfer` میں دیکھ سکتے ہیں)۔ اس کی وجہ یہ ہے کہ اسٹیٹ کی تبدیلی کے دوران آپ کے پاس ایک غیر مستقل اسٹیٹ ہوتی ہے۔ مثال کے طور پر، جب آپ بھیجنے والے کے بیلنس سے کٹوتی کرتے ہیں اور جب آپ وصول کنندہ کے بیلنس میں اضافہ کرتے ہیں، اس کے درمیان وجود میں کم ٹوکن ہوتے ہیں جتنا ہونا چاہیے۔ اگر ان کے درمیان آپریشنز ہوں، خاص طور پر کسی دوسرے کنٹریکٹ کو کالز ہوں، تو اس کا ممکنہ طور پر غلط استعمال کیا جا سکتا ہے۔ + +اب جب کہ آپ نے دیکھ لیا ہے کہ OpenZeppelin ERC-20 کنٹریکٹ کیسے لکھا جاتا ہے، اور خاص طور پر اسے کیسے زیادہ محفوظ بنایا جاتا ہے، جائیں اور اپنے محفوظ کنٹریکٹس اور ایپلیکیشنز لکھیں۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/ur/developers/tutorials/erc20-with-safety-rails/index.md new file mode 100644 index 00000000000..cb258f22f74 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/erc20-with-safety-rails/index.md @@ -0,0 +1,217 @@ +--- +title: "حفاظتی ریلز کے ساتھ ERC-20" +description: "لوگوں کو معمولی غلطیوں سے بچنے میں مدد کرنے کا طریقہ" +author: Ori Pomerantz +lang: ur-in +tags: [ "erc-20" ] +skill: beginner +published: 2022-08-15 +--- + +## تعارف {#introduction} + +ایتھیریم کی سب سے بڑی خوبیوں میں سے ایک یہ ہے کہ کوئی مرکزی اتھارٹی نہیں ہے جو آپ کے ٹرانزیکشنز میں ترمیم کر سکے یا انہیں کالعدم کر سکے۔ ایتھیریم کے ساتھ ایک بڑا مسئلہ یہ ہے کہ کوئی ایسی مرکزی اتھارٹی نہیں ہے جس کے پاس صارف کی غلطیوں یا غیر قانونی ٹرانزیکشنز کو کالعدم کرنے کا اختیار ہو۔ اس مضمون میں آپ ان کچھ عام غلطیوں کے بارے میں جانیں گے جو صارفین [ERC-20](/developers/docs/standards/tokens/erc-20/) ٹوکنز کے ساتھ کرتے ہیں، اور ساتھ ہی یہ بھی جانیں گے کہ ایسے ERC-20 کنٹریکٹس کیسے بنائے جائیں جو صارفین کو ان غلطیوں سے بچنے میں مدد کریں، یا جو کسی مرکزی اتھارٹی کو کچھ اختیارات دیں (مثال کے طور پر اکاؤنٹس کو منجمد کرنے کا اختیار)۔ + +نوٹ کریں کہ جب کہ ہم [OpenZeppelin ERC-20 ٹوکن کنٹریکٹ](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20) کا استعمال کریں گے، یہ مضمون اس کی بہت زیادہ تفصیل سے وضاحت نہیں کرتا ہے۔ آپ یہ معلومات [یہاں](/developers/tutorials/erc20-annotated-code) حاصل کر سکتے ہیں۔ + +اگر آپ مکمل سورس کوڈ دیکھنا چاہتے ہیں: + +1. [Remix IDE](https://remix.ethereum.org/) کھولیں۔ +2. گٹ ہب کلون آئیکن (![گٹ ہب کلون آئیکن](icon-clone.png)) پر کلک کریں۔ +3. گٹ ہب ریپوزٹری `https://github.com/qbzzt/20220815-erc20-safety-rails` کو کلون کریں۔ +4. **contracts > erc20-safety-rails.sol** کھولیں۔ + +## ایک ERC-20 کنٹریکٹ بنانا {#creating-an-erc-20-contract} + +حفاظتی ریل کی فعالیت شامل کرنے سے پہلے ہمیں ایک ERC-20 کنٹریکٹ کی ضرورت ہے۔ اس مضمون میں ہم [اوپن زیپلن کنٹریکٹس وزرڈ](https://docs.openzeppelin.com/contracts/5.x/wizard) کا استعمال کریں گے۔ اسے دوسرے براؤزر میں کھولیں اور ان ہدایات پر عمل کریں: + +1. **ERC20** منتخب کریں۔ + +2. یہ سیٹنگز درج کریں: + + | پیرامیٹر | قدر | + | --------------- | ---------------- | + | نام | SafetyRailsToken | + | علامت | SAFE | + | Premint | 1000 | + | خصوصیات | کوئی نہیں | + | رسائی کنٹرول | Ownable | + | اپ گریڈ ایبلیٹی | کوئی نہیں | + +3. اوپر اسکرول کریں اور (Remix کے لیے) **ری مکس میں کھولیں** پر کلک کریں یا ایک مختلف ماحول استعمال کرنے کے لیے **ڈاؤن لوڈ** کریں۔ میں یہ فرض کروں گا کہ آپ ری مکس استعمال کر رہے ہیں، اگر آپ کچھ اور استعمال کرتے ہیں تو بس مناسب تبدیلیاں کریں۔ + +4. اب ہمارے پاس ایک مکمل طور پر فعال ERC-20 کنٹریکٹ ہے۔ امپورٹڈ کوڈ دیکھنے کے لیے آپ `.deps` > `npm` کو بڑھا سکتے ہیں۔ + +5. کنٹریکٹ کو کمپائل کریں، ڈیپلائے کریں، اور اس کے ساتھ کھیلیں یہ دیکھنے کے لیے کہ یہ ایک ERC-20 کنٹریکٹ کے طور پر کام کرتا ہے۔ اگر آپ کو ریمکس استعمال کرنے کا طریقہ سیکھنے کی ضرورت ہے، [تو اس ٹیوٹوریل کا استعمال کریں](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth)۔ + +## عام غلطیاں {#common-mistakes} + +### غلطیاں {#the-mistakes} + +صارفین کبھی کبھی غلط ایڈریس پر ٹوکن بھیج دیتے ہیں۔ جبکہ ہم ان کے ذہنوں کو پڑھ کر یہ نہیں جان سکتے کہ وہ کیا کرنا چاہتے تھے، غلطی کی دو قسمیں ہیں جو بہت زیادہ ہوتی ہیں اور جن کا پتہ لگانا آسان ہے: + +1. کنٹریکٹ کے اپنے ایڈریس پر ٹوکن بھیجنا۔ مثال کے طور پر، [Optimism کا OP ٹوکن](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) دو ماہ سے بھی کم عرصے میں [120,000 سے زیادہ](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000042) OP ٹوکن جمع کرنے میں کامیاب رہا۔ یہ دولت کی ایک اہم مقدار کی نمائندگی کرتا ہے جسے غالباً لوگوں نے کھو دیا ہے۔ + +2. ٹوکن کو ایک خالی ایڈریس پر بھیجنا، ایک ایسا ایڈریس جو [بیرونی ملکیت والے اکاؤنٹ](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) یا [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts) سے مطابقت نہیں رکھتا۔ اگرچہ میرے پاس اس بات کے اعداد و شمار نہیں ہیں کہ ایسا کتنی بار ہوتا ہے، [ایک واقعے میں 20,000,000 ٹوکنز کا نقصان ہو سکتا تھا](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595)۔ + +### ٹرانسفرز کو روکنا {#preventing-transfers} + +OpenZeppelin ERC-20 کنٹریکٹ میں [ایک ہُک، `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368) شامل ہے، جسے ٹوکن کی منتقلی سے پہلے کال کیا جاتا ہے۔ ڈیفالٹ کے طور پر یہ ہُک کچھ نہیں کرتا، لیکن ہم اس پر اپنی فعالیت کو لٹکا سکتے ہیں، جیسے چیکس جو کوئی مسئلہ ہونے پر واپس ہو جاتے ہیں۔ + +ہُک استعمال کرنے کے لیے، کنسٹرکٹر کے بعد یہ فنکشن شامل کریں: + +```solidity + function _beforeTokenTransfer(address from, address to, uint256 amount) + internal virtual + override(ERC20) + { + super._beforeTokenTransfer(from, to, amount); + } +``` + +اس فنکشن کے کچھ حصے نئے ہو سکتے ہیں اگر آپ Solidity سے بہت زیادہ واقف نہیں ہیں: + +```solidity + internal virtual +``` + +ورچوئل `virtual` کلیدی لفظ کا مطلب ہے کہ جس طرح ہم نے `ERC20` سے فعالیت وراثت میں حاصل کی اور اس فنکشن کو اوور رائیڈ کیا، اسی طرح دوسرے کنٹریکٹس ہم سے وراثت میں لے سکتے ہیں اور اس فنکشن کو اوور رائیڈ کر سکتے ہیں۔ + +```solidity + override(ERC20) +``` + +ہمیں واضح طور پر یہ بتانا ہوگا کہ ہم `_beforeTokenTransfer` کی ERC20 ٹوکن تعریف کو [اوور رائیڈ](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) کر رہے ہیں۔ عام طور پر، سیکورٹی کے نقطہ نظر سے، واضح تعریفیں مضمر تعریفوں سے بہت بہتر ہیں - آپ یہ نہیں بھول سکتے کہ آپ نے کچھ کیا ہے اگر وہ آپ کے سامنے ہے۔ یہی وجہ ہے کہ ہمیں یہ بتانے کی ضرورت ہے کہ ہم کس سپر کلاس کے `_beforeTokenTransfer` کو اوور رائیڈ کر رہے ہیں۔ + +```solidity + super._beforeTokenTransfer(from, to, amount); +``` + +یہ لائن اس کنٹریکٹ یا کنٹریکٹس کے `_beforeTokenTransfer` فنکشن کو کال کرتی ہے جس سے ہم نے وراثت میں حاصل کیا ہے جس میں یہ ہے۔ اس معاملے میں، وہ صرف `ERC20` ہے، `Ownable` میں یہ ہُک نہیں ہے۔ اگرچہ فی الحال `ERC20._beforeTokenTransfer` کچھ نہیں کرتا، ہم اسے اس صورت میں کال کرتے ہیں کہ مستقبل میں فعالیت شامل کی جائے (اور پھر ہم کنٹریکٹ کو دوبارہ ڈیپلائے کرنے کا فیصلہ کرتے ہیں، کیونکہ کنٹریکٹس ڈیپلائیمنٹ کے بعد تبدیل نہیں ہوتے)۔ + +### ضروریات کی کوڈنگ {#coding-the-requirements} + +ہم فنکشن میں یہ ضروریات شامل کرنا چاہتے ہیں: + +- ایڈریس `to` `address(this)` کے برابر نہیں ہو سکتا، جو کہ خود ERC-20 کنٹریکٹ کا ایڈریس ہے۔ +- ایڈریس `to` خالی نہیں ہو سکتا، اسے یا تو ہونا چاہیے: + - ایک بیرونی ملکیت والا اکاؤنٹ (EOA)۔ ہم براہ راست یہ نہیں جانچ سکتے کہ کوئی ایڈریس EOA ہے یا نہیں، لیکن ہم کسی ایڈریس کا ETH بیلنس چیک کر سکتے ہیں۔ EOAs کا تقریباً ہمیشہ ایک بیلنس ہوتا ہے، چاہے وہ اب استعمال نہ ہو رہے ہوں - انہیں آخری wei تک صاف کرنا مشکل ہے۔ + - ایک اسمارٹ کنٹریکٹ۔ یہ جانچنا کہ آیا کوئی ایڈریس ایک اسمارٹ کنٹریکٹ ہے، تھوڑا مشکل ہے۔ ایک آپ کوڈ ہے جو بیرونی کوڈ کی لمبائی کو چیک کرتا ہے، جسے [`EXTCODESIZE`](https://www.evm.codes/#3b) کہتے ہیں، لیکن یہ Solidity میں براہ راست دستیاب نہیں ہے۔ اس کے لیے ہمیں [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html) کا استعمال کرنا ہوگا، جو کہ EVM اسمبلی ہے۔ کچھ اور قدریں ہیں جنہیں ہم Solidity سے استعمال کر سکتے ہیں ([`
.code` اور `
.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types))، لیکن ان کی لاگت زیادہ ہے۔ + +آئیے نئے کوڈ کو لائن بہ لائن دیکھتے ہیں: + +```solidity + require(to != address(this), "کنٹریکٹ ایڈریس پر ٹوکن نہیں بھیج سکتے"); +``` + +یہ پہلی ضرورت ہے، جانچیں کہ `to` اور `this(address)` ایک ہی چیز نہیں ہیں۔ + +```solidity + bool isToContract; + assembly { + isToContract := gt(extcodesize(to), 0) + } +``` + +اس طرح ہم جانچتے ہیں کہ کوئی ایڈریس کنٹریکٹ ہے یا نہیں۔ ہم Yul سے براہ راست آؤٹ پٹ حاصل نہیں کر سکتے، اس لیے اس کے بجائے ہم نتیجہ رکھنے کے لیے ایک متغیر کی وضاحت کرتے ہیں (اس معاملے میں `isToContract`)۔ Yul اس طرح کام کرتا ہے کہ ہر آپ کوڈ کو ایک فنکشن سمجھا جاتا ہے۔ تو پہلے ہم کنٹریکٹ کا سائز حاصل کرنے کے لیے [`EXTCODESIZE`](https://www.evm.codes/#3b) کو کال کرتے ہیں، اور پھر [`GT`](https://www.evm.codes/#11) کا استعمال کرتے ہوئے یہ جانچتے ہیں کہ یہ صفر نہیں ہے (ہم غیر دستخط شدہ انٹیجرز کے ساتھ کام کر رہے ہیں، اس لیے یقیناً یہ منفی نہیں ہو سکتا)۔ پھر ہم نتیجہ `isToContract` میں لکھتے ہیں۔ + +```solidity + require(to.balance != 0 || isToContract, "خالی ایڈریس پر ٹوکن نہیں بھیج سکتے"); +``` + +اور آخر میں، ہمارے پاس خالی ایڈریسز کے لیے اصل جانچ ہے۔ + +## انتظامی رسائی {#admin-access} + +کبھی کبھی ایک ایڈمنسٹریٹر کا ہونا مفید ہوتا ہے جو غلطیوں کو کالعدم کر سکے۔ غلط استعمال کے امکانات کو کم کرنے کے لیے، یہ ایڈمنسٹریٹر ایک [ملٹی سگ](https://blog.logrocket.com/security-choices-multi-signature-wallets/) ہو سکتا ہے تاکہ متعدد لوگوں کو کسی کارروائی پر متفق ہونا پڑے۔ اس مضمون میں ہمارے پاس دو انتظامی خصوصیات ہوں گی: + +1. اکاؤنٹس کو منجمد اور غیر منجمد کرنا۔ یہ مفید ہو سکتا ہے، مثال کے طور پر، جب کسی اکاؤنٹ سے سمجھوتہ کیا گیا ہو۔ +2. اثاثوں کی صفائی۔ + + کبھی کبھی دھوکہ باز قانونی حیثیت حاصل کرنے کے لیے حقیقی ٹوکن کے کنٹریکٹ پر جعلی ٹوکن بھیجتے ہیں۔ مثال کے طور پر، [یہاں دیکھیں](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe?tab=holders)۔ جائز ERC-20 کنٹریکٹ [0x4200....0042](https://optimism.blockscout.com/token/0x4200000000000000000000000000000000000042) ہے۔ اسکیم جو اس کا دکھاوا کرتی ہے وہ [0x234....bbe](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe) ہے۔ + + یہ بھی ممکن ہے کہ لوگ غلطی سے ہمارے کنٹریکٹ میں جائز ERC-20 ٹوکن بھیج دیں، جو انہیں باہر نکالنے کا ایک طریقہ رکھنے کی ایک اور وجہ ہے۔ + +OpenZeppelin انتظامی رسائی کو فعال کرنے کے لیے دو میکانزم فراہم کرتا ہے: + +- [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) کنٹریکٹس کا ایک ہی مالک ہوتا ہے۔ وہ فنکشنز جن میں `onlyOwner` [موڈیفائر](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) ہوتا ہے، انہیں صرف وہی مالک کال کر سکتا ہے۔ مالکان ملکیت کسی اور کو منتقل کر سکتے ہیں یا اسے مکمل طور پر ترک کر سکتے ہیں۔ دیگر تمام اکاؤنٹس کے حقوق عام طور پر یکساں ہوتے ہیں۔ +- [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) کنٹریکٹس میں [کردار پر مبنی رسائی کنٹرول (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control) ہوتا ہے۔ + +سادگی کی خاطر، اس مضمون میں ہم `Ownable` کا استعمال کرتے ہیں۔ + +### کنٹریکٹس کو منجمد اور غیر منجمد کرنا {#freezing-and-thawing-contracts} + +کنٹریکٹس کو منجمد اور غیر منجمد کرنے کے لیے کئی تبدیلیوں کی ضرورت ہوتی ہے: + +- ایڈریسز سے [بولینز](https://en.wikipedia.org/wiki/Boolean_data_type) تک ایک [میپنگ](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) یہ ٹریک رکھنے کے لیے کہ کون سے ایڈریسز منجمد ہیں۔ تمام قدریں ابتدائی طور پر صفر ہوتی ہیں، جس کی بولین قدروں کے لیے غلط تشریح کی جاتی ہے۔ یہ وہی ہے جو ہم چاہتے ہیں کیونکہ ڈیفالٹ کے طور پر اکاؤنٹس منجمد نہیں ہوتے ہیں۔ + + ```solidity + mapping(address => bool) public frozenAccounts; + ``` + +- [ایونٹس](https://www.tutorialspoint.com/solidity/solidity_events.htm) کسی بھی دلچسپی رکھنے والے کو مطلع کرنے کے لیے جب کوئی اکاؤنٹ منجمد یا غیر منجمد کیا جاتا ہے۔ تکنیکی طور پر ان کارروائیوں کے لیے ایونٹس کی ضرورت نہیں ہے، لیکن یہ آف چین کوڈ کو ان ایونٹس کو سننے اور یہ جاننے میں مدد کرتا ہے کہ کیا ہو رہا ہے۔ جب کوئی ایسی چیز ہوتی ہے جو کسی اور سے متعلق ہو سکتی ہے تو اسمارٹ کنٹریکٹ کے لیے انہیں خارج کرنا اچھے آداب سمجھے جاتے ہیں۔ + + ایونٹس انڈیکسڈ ہیں اس لیے ان تمام اوقات کو تلاش کرنا ممکن ہو گا جب کوئی اکاؤنٹ منجمد یا غیر منجمد کیا گیا ہو۔ + + ```solidity + // جب اکاؤنٹس منجمد یا غیر منجمد کیے جاتے ہیں + event AccountFrozen(address indexed _addr); + event AccountThawed(address indexed _addr); + ``` + +- اکاؤنٹس کو منجمد اور غیر منجمد کرنے کے لیے فنکشنز۔ یہ دونوں فنکشنز تقریباً ایک جیسے ہیں، اس لیے ہم صرف فریز فنکشن پر غور کریں گے۔ + + ```solidity + function freezeAccount(address addr) + public + onlyOwner + ``` + + [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm) سے نشان زد فنکشنز کو دوسرے اسمارٹ کنٹریکٹس سے یا براہ راست ٹرانزیکشن کے ذریعے کال کیا جا سکتا ہے۔ + + ```solidity + { + require(!frozenAccounts[addr], "اکاؤنٹ پہلے ہی منجمد ہے"); + frozenAccounts[addr] = true; + emit AccountFrozen(addr); + } // freezeAccount + ``` + + اگر اکاؤنٹ پہلے سے ہی منجمد ہے، تو واپس جائیں۔ ورنہ، اسے منجمد کریں اور ایک ایونٹ `emit` کریں۔ + +- منجمد اکاؤنٹ سے رقم کی منتقلی کو روکنے کے لیے `_beforeTokenTransfer` کو تبدیل کریں۔ نوٹ کریں کہ منجمد اکاؤنٹ میں اب بھی رقم منتقل کی جا سکتی ہے۔ + + ```solidity + require(!frozenAccounts[from], "اکاؤنٹ منجمد ہے"); + ``` + +### اثاثوں کی صفائی {#asset-cleanup} + +اس کنٹریکٹ کے ذریعے رکھے گئے ERC-20 ٹوکنز کو جاری کرنے کے لیے ہمیں اس ٹوکن کنٹریکٹ پر ایک فنکشن کال کرنے کی ضرورت ہے جس سے وہ تعلق رکھتے ہیں، یا تو [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) یا [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve)۔ اس معاملے میں الاؤنسز پر گیس ضائع کرنے کا کوئی فائدہ نہیں، ہم براہ راست بھی منتقل کر سکتے ہیں۔ + +```solidity + function cleanupERC20( + address erc20, + address dest + ) + public + onlyOwner + { + IERC20 token = IERC20(erc20); +``` + +جب ہم ایڈریس وصول کرتے ہیں تو یہ ایک کنٹریکٹ کے لیے آبجیکٹ بنانے کا نحو ہے۔ ہم ایسا کر سکتے ہیں کیونکہ ہمارے پاس سورس کوڈ کے حصے کے طور پر ERC20 ٹوکنز کی تعریف ہے (لائن 4 دیکھیں)، اور اس فائل میں [IERC20 کی تعریف](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) شامل ہے، جو ایک OpenZeppelin ERC-20 کنٹریکٹ کے لیے انٹرفیس ہے۔ + +```solidity + uint balance = token.balanceOf(address(this)); + token.transfer(dest, balance); + } +``` + +یہ ایک کلین اپ فنکشن ہے، اس لیے قیاس ہے کہ ہم کوئی ٹوکن نہیں چھوڑنا چاہتے۔ صارف سے دستی طور پر بیلنس حاصل کرنے کے بجائے، ہم اس عمل کو خودکار بھی بنا سکتے ہیں۔ + +## نتیجہ {#conclusion} + +یہ ایک کامل حل نہیں ہے - "صارف نے غلطی کی" کے مسئلے کا کوئی کامل حل نہیں ہے۔ تاہم، اس قسم کی جانچ کا استعمال کم از کم کچھ غلطیوں کو روک سکتا ہے۔ اکاؤنٹس کو منجمد کرنے کی صلاحیت، اگرچہ خطرناک ہے، لیکن ہیکر کو چوری شدہ فنڈز سے انکار کرکے کچھ ہیکس کے نقصان کو محدود کرنے کے لیے استعمال کی جا سکتی ہے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/ur/developers/tutorials/ethereum-for-web2-auth/index.md new file mode 100644 index 00000000000..18b8dc33934 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/ethereum-for-web2-auth/index.md @@ -0,0 +1,886 @@ +--- +title: "ویب 2 کی توثیق کے لیے ایتھیریم کا استعمال" +description: "اس ٹیوٹوریل کو پڑھنے کے بعد، ایک ڈیولپر ایتھیریم لاگ ان (ویب 3) کو SAML لاگ ان کے ساتھ مربوط کر سکے گا، جو ویب 2 میں سنگل سائن آن اور دیگر متعلقہ خدمات فراہم کرنے کے لیے استعمال ہونے والا ایک معیار ہے۔ یہ ویب 2 وسائل تک رسائی کی توثیق ایتھیریم دستخطوں کے ذریعے کرنے کی اجازت دیتا ہے، جس میں صارف کی خصوصیات تصدیق ناموں سے آتی ہیں۔" +author: Ori Pomerantz +tags: [ "ویب 2", "توثیق (Authentication)", "eas" ] +skill: beginner +lang: ur-in +published: 2025-04-30 +--- + +## تعارف + +[SAML](https://www.onelogin.com/learn/saml) ویب 2 پر استعمال ہونے والا ایک معیار ہے جو [شناختی فراہم کنندہ (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) کو [سروس فراہم کنندگان (SP)](https://en.wikipedia.org/wiki/Service_provider_\(SAML\)) کے لیے صارف کی معلومات فراہم کرنے کی اجازت دیتا ہے۔ + +اس ٹیوٹوریل میں آپ سیکھیں گے کہ ایتھیریم دستخطوں کو SAML کے ساتھ کیسے مربوط کیا جائے تاکہ صارفین اپنے ایتھیریم والیٹس کا استعمال ان ویب 2 خدمات کے لیے خود کی توثیق کر سکیں جو ابھی تک مقامی طور پر ایتھیریم کو سپورٹ نہیں کرتی ہیں۔ + +نوٹ کریں کہ یہ ٹیوٹوریل دو الگ الگ سامعین کے لیے لکھا گیا ہے: + +- ایتھیریم کے لوگ جو ایتھیریم کو سمجھتے ہیں اور انہیں SAML سیکھنے کی ضرورت ہے۔ +- ویب 2 کے لوگ جو SAML اور ویب 2 کی توثیق کو سمجھتے ہیں اور انہیں ایتھیریم سیکھنے کی ضرورت ہے۔ + +نتیجتاً، اس میں بہت سارا تعارفی مواد ہوگا جو آپ پہلے سے جانتے ہیں۔ بلا جھجھک اسے چھوڑ دیں۔ + +### ایتھیریم کے لوگوں کے لیے SAML + +SAML ایک مرکزی پروٹوکول ہے۔ ایک سروس فراہم کنندہ (SP) صرف ایک شناختی فراہم کنندہ (IdP) سے دعوے (جیسے "یہ میرا صارف جان ہے، اس کے پاس A، B اور C کرنے کی اجازت ہونی چاہیے") قبول کرتا ہے اگر اس کے ساتھ پہلے سے موجود اعتماد کا رشتہ ہو، یا اس [سرٹیفکیٹ اتھارٹی](https://www.ssl.com/article/what-is-a-certificate-authority-ca/) کے ساتھ جس نے اس IdP کے سرٹیفکیٹ پر دستخط کیے ہیں۔ + +مثال کے طور پر، SP ایک ٹریول ایجنسی ہو سکتی ہے جو کمپنیوں کو سفری خدمات فراہم کرتی ہے، اور IdP کمپنی کی اندرونی ویب سائٹ ہو سکتی ہے۔ جب ملازمین کو کاروباری سفر بک کرنے کی ضرورت ہوتی ہے، تو ٹریول ایجنسی انہیں اصل میں سفر بک کرنے کی اجازت دینے سے پہلے کمپنی کے ذریعے توثیق کے لیے بھیجتی ہے۔ + +![مرحلہ وار SAML عمل](./fig-01-saml.png) + +یہ وہ طریقہ ہے جس سے تینوں ادارے، براؤزر، SP، اور IdP، رسائی کے لیے گفت و شنید کرتے ہیں۔ SP کو براؤزر استعمال کرنے والے صارف کے بارے میں پہلے سے کچھ جاننے کی ضرورت نہیں، صرف IdP پر بھروسہ کرنے کی ضرورت ہے۔ + +### SAML کے لوگوں کے لیے ایتھیریم + +ایتھیریم ایک غیر مرکزی نظام ہے۔ + +![ایتھیریم لاگ آن](./fig-02-eth-logon.png) + +صارفین کے پاس ایک نجی کلید ہوتی ہے (عام طور پر براؤزر ایکسٹینشن میں رکھی جاتی ہے)۔ نجی کلید سے آپ ایک عوامی کلید، اور اس سے 20 بائٹ کا پتہ اخذ کر سکتے ہیں۔ جب صارفین کو کسی سسٹم میں لاگ ان کرنے کی ضرورت ہوتی ہے، تو ان سے نانس (ایک بار استعمال ہونے والی قدر) کے ساتھ ایک پیغام پر دستخط کرنے کی درخواست کی جاتی ہے۔ سرور اس بات کی تصدیق کر سکتا ہے کہ دستخط اسی پتے سے بنایا گیا تھا۔ + +![تصدیق ناموں سے اضافی ڈیٹا حاصل کرنا](./fig-03-eas-data.png) + +دستخط صرف ایتھیریم پتے کی تصدیق کرتا ہے۔ دیگر صارف صفات حاصل کرنے کے لیے، آپ عام طور پر [تصدیق نامے](https://attest.org/) استعمال کرتے ہیں۔ ایک تصدیق نامے میں عام طور پر یہ فیلڈز ہوتے ہیں: + +- **تصدیق کنندہ**، وہ پتہ جس نے تصدیق کی +- **وصول کنندہ**، وہ پتہ جس پر تصدیق کا اطلاق ہوتا ہے +- **ڈیٹا**، وہ ڈیٹا جس کی تصدیق کی جا رہی ہے، جیسے نام، اجازتیں وغیرہ۔ +- **اسکیما**، ڈیٹا کی تشریح کے لیے استعمال ہونے والے اسکیما کی آئی ڈی۔ + +ایتھیریم کی غیر مرکزی نوعیت کی وجہ سے، کوئی بھی صارف تصدیق نامے بنا سکتا ہے۔ تصدیق کنندہ کی شناخت اس بات کی نشاندہی کرنے کے لیے اہم ہے کہ ہم کن تصدیق ناموں کو قابل اعتماد سمجھتے ہیں۔ + +## سیٹ اپ + +پہلا قدم ایک SAML SP اور ایک SAML IdP کا ہونا ہے جو آپس میں مواصلت کر رہے ہوں۔ + +1. سافٹ ویئر ڈاؤن لوڈ کریں۔ اس مضمون کے لیے نمونہ سافٹ ویئر [گٹ ہب پر](https://github.com/qbzzt/250420-saml-ethereum) ہے۔ مختلف مراحل مختلف برانچوں میں محفوظ ہیں، اس مرحلے کے لیے آپ کو `saml-only` چاہیے۔ + + ```sh + git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only + cd 250420-saml-ethereum + pnpm install + ``` + +2. خود دستخط شدہ سرٹیفکیٹس کے ساتھ کلیدیں بنائیں۔ اس کا مطلب ہے کہ کلید خود اپنی سرٹیفکیٹ اتھارٹی ہے، اور اسے دستی طور پر سروس فراہم کنندہ میں درآمد کرنے کی ضرورت ہے۔ مزید معلومات کے لیے [OpenSSL دستاویزات](https://docs.openssl.org/master/man1/openssl-req/) دیکھیں۔ + + ```sh + mkdir keys + cd keys + openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/ + openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/ + cd .. + ``` + +3. سرورز (SP اور IdP دونوں) شروع کریں + + ```sh + pnpm start + ``` + +4. URL [http://localhost:3000/](http://localhost:3000/) پر SP پر براؤز کریں اور IdP (پورٹ 3001) پر ری ڈائریکٹ ہونے کے لیے بٹن پر کلک کریں۔ + +5. IdP کو اپنا ای میل پتہ فراہم کریں اور **سروس فراہم کنندہ میں لاگ ان کریں** پر کلک کریں۔ دیکھیں کہ آپ کو سروس فراہم کنندہ (پورٹ 3000) پر واپس ری ڈائریکٹ کر دیا گیا ہے اور یہ آپ کو آپ کے ای میل پتے سے جانتا ہے۔ + +### تفصیلی وضاحت + +یہ ہے جو ہوتا ہے، مرحلہ وار: + +![ایتھیریم کے بغیر عام SAML لاگ آن](./fig-04-saml-no-eth.png) + +#### src/config.mts + +اس فائل میں شناختی فراہم کنندہ اور سروس فراہم کنندہ دونوں کے لیے کنفیگریشن موجود ہے۔ عام طور پر یہ دونوں مختلف ادارے ہوں گے، لیکن یہاں ہم سادگی کے لیے کوڈ شیئر کر سکتے ہیں۔ + +```typescript +const fs = await import("fs") + +const protocol="http" +``` + +ابھی کے لیے ہم صرف ٹیسٹ کر رہے ہیں، لہذا HTTP استعمال کرنا ٹھیک ہے۔ + +```typescript +export const spCert = fs.readFileSync("keys/saml-sp.crt").toString() +export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString() +``` + +عوامی کلیدیں پڑھیں، جو عام طور پر دونوں اجزاء کے لیے دستیاب ہوتی ہیں (اور یا تو براہ راست قابل اعتماد ہوتی ہیں، یا کسی قابل اعتماد سرٹیفکیٹ اتھارٹی کے ذریعے دستخط شدہ ہوتی ہیں)۔ + +```typescript +export const spPort = 3000 +export const spHostname = "localhost" +export const spDir = "sp" + +export const idpPort = 3001 +export const idpHostname = "localhost" +export const idpDir = "idp" + +export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}` +export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}` +``` + +دونوں اجزاء کے لیے URLs۔ + +```typescript +export const spPublicData = { +``` + +سروس فراہم کنندہ کے لیے عوامی ڈیٹا۔ + +```typescript + entityID: `${spUrl}/metadata`, +``` + +روایت کے مطابق، SAML میں `entityID` وہ URL ہے جہاں ادارے کا میٹا ڈیٹا دستیاب ہوتا ہے۔ یہ میٹا ڈیٹا یہاں عوامی ڈیٹا سے مطابقت رکھتا ہے، سوائے اس کے کہ یہ XML فارم میں ہے۔ + +```typescript + wantAssertionsSigned: true, + authnRequestsSigned: false, + signingCert: spCert, + allowCreate: true, + assertionConsumerService: [{ + Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST', + Location: `${spUrl}/assertion`, + }] + } +``` + +ہمارے مقاصد کے لیے سب سے اہم تعریف `assertionConsumerServer` ہے۔ اس کا مطلب ہے کہ سروس فراہم کنندہ کو کسی چیز کا دعویٰ کرنے کے لیے (مثال کے طور پر، "یہ معلومات بھیجنے والا صارف somebody@example.com ہے") ہمیں URL `http://localhost:3000/sp/assertion` پر [HTTP POST](https://www.w3schools.com/tags/ref_httpmethods.asp) استعمال کرنے کی ضرورت ہے۔ + +```typescript +export const idpPublicData = { + entityID: `${idpUrl}/metadata`, + signingCert: idpCert, + wantAuthnRequestsSigned: false, + singleSignOnService: [{ + Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", + Location: `${idpUrl}/login` + }], + singleLogoutService: [{ + Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", + Location: `${idpUrl}/logout` + }], + } +``` + +شناختی فراہم کنندہ کے لیے عوامی ڈیٹا اسی طرح کا ہے۔ یہ بتاتا ہے کہ کسی صارف کو لاگ ان کرنے کے لیے آپ `http://localhost:3001/idp/login` پر POST کرتے ہیں اور کسی صارف کو لاگ آؤٹ کرنے کے لیے آپ `http://localhost:3001/idp/logout` پر POST کرتے ہیں۔ + +#### src/sp.mts + +یہ وہ کوڈ ہے جو سروس فراہم کنندہ کو نافذ کرتا ہے۔ + +```typescript +import * as config from "./config.mts" +const fs = await import("fs") +const saml = await import("samlify") +``` + +ہم SAML کو نافذ کرنے کے لیے [`samlify`](https://www.npmjs.com/package/samlify) لائبریری کا استعمال کرتے ہیں۔ + +```typescript +import * as validator from "@authenio/samlify-node-xmllint" +saml.setSchemaValidator(validator) +``` + +`samlify` لائبریری ایک پیکیج سے یہ توثیق کرنے کی توقع کرتی ہے کہ XML درست ہے، متوقع عوامی کلید کے ساتھ دستخط شدہ ہے، وغیرہ۔ ہم اس مقصد کے لیے [`@authenio/samlify-node-xmllint`](https://www.npmjs.com/package/@authenio/samlify-node-xmllint) کا استعمال کرتے ہیں۔ + +```typescript +const express = (await import("express")).default +const spRouter = express.Router() +const app = express() +``` + +ایک [`express`](https://expressjs.com/) [`Router`](https://expressjs.com/en/5x/api.html#router) ایک "چھوٹی ویب سائٹ" ہے جسے کسی ویب سائٹ کے اندر نصب کیا جا سکتا ہے۔ اس معاملے میں، ہم اسے تمام سروس فراہم کنندہ کی تعریفوں کو ایک ساتھ گروپ کرنے کے لیے استعمال کرتے ہیں۔ + +```typescript +const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString() + +const sp = saml.ServiceProvider({ + privateKey: spPrivateKey, + ...config.spPublicData +}) +``` + +سروس فراہم کنندہ کی اپنی نمائندگی تمام عوامی ڈیٹا، اور وہ نجی کلید ہے جسے وہ معلومات پر دستخط کرنے کے لیے استعمال کرتا ہے۔ + +```typescript +const idp = saml.IdentityProvider(config.idpPublicData); +``` + +عوامی ڈیٹا میں وہ سب کچھ ہوتا ہے جو سروس فراہم کنندہ کو شناختی فراہم کنندہ کے بارے میں جاننے کی ضرورت ہوتی ہے۔ + +```typescript +spRouter.get(`/metadata`, + (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata()) +) +``` + +دیگر SAML اجزاء کے ساتھ باہمی تعاون کو فعال کرنے کے لیے، سروس اور شناختی فراہم کنندگان کو اپنا عوامی ڈیٹا (جسے میٹا ڈیٹا کہا جاتا ہے) `/metadata` میں XML فارمیٹ میں دستیاب ہونا چاہیے۔ + +```typescript +spRouter.post(`/assertion`, +``` + +یہ وہ صفحہ ہے جس تک براؤزر اپنی شناخت کے لیے رسائی حاصل کرتا ہے۔ دعویٰ میں صارف کا شناخت کنندہ (یہاں ہم ای میل پتہ استعمال کرتے ہیں) شامل ہوتا ہے، اور اس میں اضافی صفات بھی شامل ہو سکتی ہیں۔ یہ اوپر کے ترتیب وار خاکے میں مرحلہ 7 کے لیے ہینڈلر ہے۔ + +```typescript + async (req, res) => { + // console.log(`SAML response:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`) +``` + +آپ دعوے میں فراہم کردہ XML ڈیٹا دیکھنے کے لیے کمنٹ آؤٹ کمانڈ کا استعمال کر سکتے ہیں۔ یہ [بیس 64 انکوڈڈ](https://en.wikipedia.org/wiki/Base64) ہے۔ + +```typescript + try { + const loginResponse = await sp.parseLoginResponse(idp, 'post', req); +``` + +شناختی سرور سے لاگ ان کی درخواست کو پارس کریں۔ + +```typescript + res.send(` + + +

ہیلو ${loginResponse.extract.nameID}

+ + + `) + res.send(); +``` + +ایک HTML جواب بھیجیں، صرف صارف کو یہ دکھانے کے لیے کہ ہمیں لاگ ان مل گیا ہے۔ + +```typescript + } catch (err) { + console.error('SAML جواب پر کارروائی کرنے میں خرابی:', err); + res.status(400).send('SAML توثیق ناکام'); + } + } +) +``` + +ناکامی کی صورت میں صارف کو مطلع کریں۔ + +```typescript +spRouter.get('/login', +``` + +جب براؤزر اس صفحے کو حاصل کرنے کی کوشش کرتا ہے تو ایک لاگ ان درخواست بنائیں۔ یہ اوپر کے ترتیب وار خاکے میں مرحلہ 1 کے لیے ہینڈلر ہے۔ + +```typescript + async (req, res) => { + const loginRequest = await sp.createLoginRequest(idp, "post") +``` + +لاگ ان کی درخواست پوسٹ کرنے کے لیے معلومات حاصل کریں۔ + +```typescript + res.send(` + + + +``` + +یہ صفحہ خود بخود فارم (نیچے دیکھیں) جمع کراتا ہے۔ اس طرح صارف کو ری ڈائریکٹ ہونے کے لیے کچھ کرنے کی ضرورت نہیں ہے۔ یہ اوپر کے ترتیب وار خاکے میں مرحلہ 2 ہے۔ + +```typescript +
+``` + +`loginRequest.entityEndpoint` (شناختی فراہم کنندہ کے اینڈ پوائنٹ کا URL) پر پوسٹ کریں۔ + +```typescript + +``` + +ان پٹ کا نام `loginRequest.type` (`SAMLRequest`) ہے۔ اس فیلڈ کا مواد `loginRequest.context` ہے، جو دوبارہ XML ہے جو بیس 64 انکوڈڈ ہے۔ + +```typescript +
+ + + `) + } +) + +app.use(express.urlencoded({extended: true})) +``` + +[یہ مڈل ویئر](https://expressjs.com/en/5x/api.html#express.urlencoded) [HTTP درخواست](https://www.tutorialspoint.com/http/http_requests.htm) کی باڈی کو پڑھتا ہے۔ پہلے سے طے شدہ طور پر express اسے نظر انداز کرتا ہے، کیونکہ زیادہ تر درخواستوں کو اس کی ضرورت نہیں ہوتی۔ ہمیں اس کی ضرورت ہے کیونکہ POST باڈی کا استعمال کرتا ہے۔ + +```typescript +app.use(`/${config.spDir}`, spRouter) +``` + +راؤٹر کو سروس فراہم کنندہ ڈائرکٹری (`/sp`) میں نصب کریں۔ + +```typescript +app.get("/", (req, res) => { + res.send(` + + + + + + `) +}) +``` + +اگر کوئی براؤزر روٹ ڈائرکٹری حاصل کرنے کی کوشش کرتا ہے، تو اسے لاگ ان صفحہ کا ایک لنک فراہم کریں۔ + +```typescript +app.listen(config.spPort, () => { + console.log(`سروس فراہم کنندہ http://${config.spHostname}:${config.spPort} پر چل رہا ہے`) +}) +``` + +اس express ایپلیکیشن کے ساتھ `spPort` کو سنیں۔ + +#### src/idp.mts + +یہ شناختی فراہم کنندہ ہے۔ یہ سروس فراہم کنندہ سے بہت ملتا جلتا ہے، نیچے دی گئی وضاحتیں ان حصوں کے لیے ہیں جو مختلف ہیں۔ + +```typescript +const xmlParser = new (await import("fast-xml-parser")).XMLParser( + { + ignoreAttributes: false, // صفات کو محفوظ رکھیں + attributeNamePrefix: "@_", // صفات کے لیے سابقہ + } +) +``` + +ہمیں سروس فراہم کنندہ سے موصول ہونے والی XML درخواست کو پڑھنے اور سمجھنے کی ضرورت ہے۔ + +```typescript +const getLoginPage = requestId => ` +``` + +یہ فنکشن خودکار طور پر جمع کردہ فارم کے ساتھ صفحہ بناتا ہے جو اوپر کے ترتیب وار خاکے کے مرحلہ 4 میں واپس آتا ہے۔ + +```typescript + + + لاگ ان صفحہ + + +

لاگ ان صفحہ

+
+ + ای میل پتہ: +
+ +``` + +دو فیلڈز ہیں جو ہم سروس فراہم کنندہ کو بھیجتے ہیں: + +1. وہ `requestId` جس کا ہم جواب دے رہے ہیں۔ +2. صارف کا شناخت کنندہ (ہم ابھی کے لیے صارف کا فراہم کردہ ای میل پتہ استعمال کرتے ہیں)۔ + +```typescript +
+ + + +const idpRouter = express.Router() + +idpRouter.post("/loginSubmitted", async (req, res) => { + const loginResponse = await idp.createLoginResponse( +``` + +یہ اوپر کے ترتیب وار خاکے کے مرحلہ 5 کے لیے ہینڈلر ہے۔ [`idp.createLoginResponse`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L73-L125) لاگ ان جواب بناتا ہے۔ + +```typescript + sp, + { + authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport', + audience: sp.entityID, +``` + +سامعین سروس فراہم کنندہ ہے۔ + +```typescript + extract: { + request: { + id: req.body.requestId + } + }, +``` + +درخواست سے نکالی گئی معلومات۔ درخواست میں جس ایک پیرامیٹر کا ہم خیال رکھتے ہیں وہ requestId ہے، جو سروس فراہم کنندہ کو درخواستوں اور ان کے جوابات کو ملانے دیتا ہے۔ + +```typescript + signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert } // دستخط کو یقینی بنائیں +``` + +جواب پر دستخط کرنے کے لیے ڈیٹا رکھنے کے لیے ہمیں `signingKey` کی ضرورت ہے۔ سروس فراہم کنندہ غیر دستخط شدہ درخواستوں پر بھروسہ نہیں کرتا ہے۔ + +```typescript + }, + "post", + { + email: req.body.email +``` + +یہ صارف کی معلومات کے ساتھ وہ فیلڈ ہے جسے ہم سروس فراہم کنندہ کو واپس بھیجتے ہیں۔ + +```typescript + } + ); + + res.send(` + + + + +
+ +
+ + + `) +}) +``` + +دوبارہ، ایک خودکار طور پر جمع کردہ فارم استعمال کریں۔ یہ اوپر کے ترتیب وار خاکے کا مرحلہ 6 ہے۔ + +```typescript + +// لاگ ان درخواستوں کے لیے IdP اینڈ پوائنٹ +idpRouter.post(`/login`, +``` + +یہ وہ اینڈ پوائنٹ ہے جو سروس فراہم کنندہ سے لاگ ان کی درخواست وصول کرتا ہے۔ یہ اوپر کے ترتیب وار خاکے کے مرحلہ 3 کا ہینڈلر ہے۔ + +```typescript + async (req, res) => { + try { + // ورک اراؤنڈ کیونکہ میں parseLoginRequest کو کام کرنے پر مجبور نہیں کر سکا۔ + // const loginRequest = await idp.parseLoginRequest(sp, 'post', req) + const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8')) + res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"])) +``` + +ہمیں توثیق کی درخواست کی آئی ڈی کو پڑھنے کے لیے [`idp.parseLoginRequest`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L127-L144) کا استعمال کرنے کے قابل ہونا چاہیے۔ تاہم، میں اسے کام کرنے پر مجبور نہیں کر سکا اور اس پر زیادہ وقت صرف کرنا مناسب نہیں تھا، لہذا میں نے صرف ایک [عام مقصد کے XML پارسر](https://www.npmjs.com/package/fast-xml-parser) کا استعمال کیا۔ ہمیں جس معلومات کی ضرورت ہے وہ `` ٹیگ کے اندر `ID` کی صفت ہے، جو XML کی اعلیٰ سطح پر ہے۔ + +## ایتھیریم دستخطوں کا استعمال + +اب جب کہ ہم صارف کی شناخت سروس فراہم کنندہ کو بھیج سکتے ہیں، اگلا قدم صارف کی شناخت کو قابل اعتماد طریقے سے حاصل کرنا ہے۔ Viem ہمیں صرف والیٹ سے صارف کا پتہ پوچھنے کی اجازت دیتا ہے، لیکن اس کا مطلب ہے براؤزر سے معلومات مانگنا۔ ہم براؤزر کو کنٹرول نہیں کرتے ہیں، لہذا ہم اس سے ملنے والے جواب پر خود بخود بھروسہ نہیں کر سکتے۔ + +اس کے بجائے، IdP براؤزر کو دستخط کرنے کے لیے ایک سٹرنگ بھیجے گا۔ اگر براؤزر میں موجود والیٹ اس سٹرنگ پر دستخط کرتا ہے، تو اس کا مطلب ہے کہ یہ واقعی وہی پتہ ہے (یعنی، یہ اس پتے سے مطابقت رکھنے والی نجی کلید کو جانتا ہے)۔ + +اسے عملی طور پر دیکھنے کے لیے، موجودہ IdP اور SP کو روکیں اور یہ کمانڈز چلائیں: + +```sh +git checkout eth-signatures +pnpm install +pnpm start +``` + +پھر [SP پر](http://localhost:3000) براؤز کریں اور ہدایات پر عمل کریں۔ + +نوٹ کریں کہ اس مقام پر ہم نہیں جانتے کہ ایتھیریم پتے سے ای میل پتہ کیسے حاصل کیا جائے، لہذا اس کے بجائے ہم SP کو `@bad.email.address` کی اطلاع دیتے ہیں۔ + +### تفصیلی وضاحت + +تبدیلیاں پچھلے خاکے میں مرحلہ 4-5 میں ہیں۔ + +![ایتھیریم دستخط کے ساتھ SAML](./fig-05-saml-w-signature.png) + +ہم نے جو واحد فائل تبدیل کی ہے وہ `idp.mts` ہے۔ یہاں تبدیل شدہ حصے ہیں۔ + +```typescript +import { v4 as uuidv4 } from 'uuid' +import { verifyMessage } from 'viem' +``` + +ہمیں ان دو اضافی لائبریریوں کی ضرورت ہے۔ ہم [نانس](https://en.wikipedia.org/wiki/Cryptographic_nonce) کی قدر بنانے کے لیے [`uuid`](https://www.npmjs.com/package/uuid) کا استعمال کرتے ہیں۔ قدر خود کوئی معنی نہیں رکھتی، صرف یہ حقیقت کہ یہ صرف ایک بار استعمال ہوتی ہے۔ + +[`viem`](https://viem.sh/) لائبریری ہمیں ایتھیریم کی تعریفیں استعمال کرنے دیتی ہے۔ یہاں ہمیں اس کی تصدیق کرنے کی ضرورت ہے کہ دستخط واقعی درست ہے۔ + +```typescript +const loginPrompt = "سروس فراہم کنندہ تک رسائی حاصل کرنے کے لیے، اس نانس پر دستخط کریں: " +``` + +والیٹ صارف سے پیغام پر دستخط کرنے کی اجازت مانگتا ہے۔ ایک پیغام جو صرف ایک نانس ہو صارفین کو الجھا سکتا ہے، لہذا ہم اس پرامپٹ کو شامل کرتے ہیں۔ + +```typescript +// requestIDs یہاں رکھیں +let nonces = {} +``` + +ہمیں درخواست کی معلومات کی ضرورت ہے تاکہ ہم اس کا جواب دے سکیں۔ ہم اسے درخواست کے ساتھ بھیج سکتے ہیں (مرحلہ 4)، اور اسے واپس وصول کر سکتے ہیں (مرحلہ 5)۔ تاہم، ہم براؤزر سے ملنے والی معلومات پر بھروسہ نہیں کر سکتے، جو ایک ممکنہ طور پر مخالف صارف کے کنٹرول میں ہے۔ لہذا اسے یہاں محفوظ کرنا بہتر ہے، نانس کو کلید کے طور پر استعمال کرتے ہوئے۔ + +نوٹ کریں کہ ہم سادگی کی خاطر اسے یہاں ایک متغیر کے طور پر کر رہے ہیں۔ تاہم، اس کے کئی نقصانات ہیں: + +- ہم سروس سے انکار کے حملے کا شکار ہیں۔ ایک بدنیتی پر مبنی صارف متعدد بار لاگ آن کرنے کی کوشش کر سکتا ہے، جس سے ہماری میموری بھر جائے گی۔ +- اگر IdP کے عمل کو دوبارہ شروع کرنے کی ضرورت پڑی تو، ہم موجودہ قدروں کو کھو دیں گے۔ +- ہم متعدد پروسیسز میں لوڈ بیلنس نہیں کر سکتے، کیونکہ ہر ایک کا اپنا متغیر ہوگا۔ + +پروڈکشن سسٹم پر ہم ڈیٹا بیس کا استعمال کریں گے اور کسی قسم کا میعاد ختم ہونے کا طریقہ کار نافذ کریں گے۔ + +```typescript +const getSignaturePage = requestId => { + const nonce = uuidv4() + nonces[nonce] = requestId +``` + +ایک نانس بنائیں، اور مستقبل میں استعمال کے لیے `requestId` کو محفوظ کریں۔ + +```typescript + return ` + + + + + +

براہ کرم دستخط کریں

+ +
+ + + +` +} +``` + +باقی صرف معیاری HTML ہے۔ + +```typescript +idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => { +``` + +یہ ترتیب وار خاکے میں مرحلہ 5 کے لیے ہینڈلر ہے۔ + +```typescript + const requestId = nonces[req.params.nonce] + if (requestId === undefined) { + res.send("خراب نانس") + return ; + } + + nonces[req.params.nonce] = undefined +``` + +درخواست کی آئی ڈی حاصل کریں، اور `nonces` سے نانس کو حذف کریں تاکہ یہ یقینی بنایا جا سکے کہ اسے دوبارہ استعمال نہیں کیا جا سکتا۔ + +```typescript + try { +``` + +چونکہ دستخط کے غلط ہونے کے بہت سے طریقے ہیں، ہم اسے ایک `try ...` میں لپیٹتے ہیں۔ کسی بھی پھینکی گئی غلطیوں کو پکڑنے کے لیے `catch` بلاک۔ + +```typescript + const validSignature = await verifyMessage({ + address: req.params.account, + message: `${loginPrompt}${req.params.nonce}`, + signature: req.params.signature + }) +``` + +ترتیب وار خاکے میں مرحلہ 5.5 کو نافذ کرنے کے لیے [`verifyMessage`](https://viem.sh/docs/actions/public/verifyMessage#verifymessage) کا استعمال کریں۔ + +```typescript + if (!validSignature) + throw("خراب دستخط") + } catch (err) { + res.send("خرابی:" + err) + return ; + } +``` + +ہینڈلر کا بقیہ حصہ اس کے برابر ہے جو ہم نے پہلے `/loginSubmitted` ہینڈلر میں کیا ہے، سوائے ایک چھوٹی سی تبدیلی کے۔ + +```typescript + const loginResponse = await idp.createLoginResponse( + . + . + . + { + email: req.params.account + "@bad.email.address" + } + ); +``` + +ہمارے پاس اصل ای میل پتہ نہیں ہے (ہم اسے اگلے حصے میں حاصل کریں گے)، لہذا ابھی کے لیے ہم ایتھیریم پتہ واپس کرتے ہیں اور اسے واضح طور پر ای میل پتے کے طور پر نشان زد نہیں کرتے ہیں۔ + +```typescript +// لاگ ان درخواستوں کے لیے IdP اینڈ پوائنٹ +idpRouter.post(`/login`, + async (req, res) => { + try { + // ورک اراؤنڈ کیونکہ میں parseLoginRequest کو کام کرنے پر مجبور نہیں کر سکا۔ + // const loginRequest = await idp.parseLoginRequest(sp, 'post', req) + const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8')) + res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"])) + } catch (err) { + console.error('SAML جواب پر کارروائی کرنے میں خرابی:', err); + res.status(400).send('SAML توثیق ناکام'); + } + } +) +``` + +مرحلہ 3 کے ہینڈلر میں `getLoginPage` کی بجائے اب `getSignaturePage` کا استعمال کریں۔ + +## ای میل پتہ حاصل کرنا + +اگلا قدم ای میل پتہ حاصل کرنا ہے، جو سروس فراہم کنندہ کی طرف سے درخواست کردہ شناخت کنندہ ہے۔ ایسا کرنے کے لیے، ہم [ایتھیریم تصدیقی سروس (EAS)](https://attest.org/) کا استعمال کرتے ہیں۔ + +تصدیق نامے حاصل کرنے کا سب سے آسان طریقہ [GraphQL API](https://docs.attest.org/docs/developer-tools/api) کا استعمال کرنا ہے۔ ہم اس استفسار کا استعمال کرتے ہیں: + +``` +query GetAttestationsByRecipient { + attestations( + where: { + recipient: { equals: "${getAddress(ethAddr)}" } + schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" } + } + take: 1 + ) { + data + id + attester + } +} +``` + +اس [`schemaId`](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977) میں صرف ایک ای میل پتہ شامل ہے۔ یہ استفسار اس اسکیما کے تصدیق ناموں کی درخواست کرتا ہے۔ تصدیق نامے کا موضوع `recipient` کہلاتا ہے۔ یہ ہمیشہ ایک ایتھیریم پتہ ہوتا ہے۔ + +انتباہ: جس طرح سے ہم یہاں تصدیق نامے حاصل کر رہے ہیں اس میں دو حفاظتی مسائل ہیں۔ + +- ہم API اینڈ پوائنٹ، `https://optimism.easscan.org/graphql` پر جا رہے ہیں، جو ایک مرکزی جزو ہے۔ ہم `id` صفت حاصل کر سکتے ہیں اور پھر آن چین پر ایک تلاش کر کے تصدیق کر سکتے ہیں کہ تصدیق نامہ حقیقی ہے، لیکن API اینڈ پوائنٹ اب بھی ہمیں ان کے بارے میں نہ بتا کر تصدیق ناموں کو سنسر کر سکتا ہے۔ + + یہ مسئلہ حل کرنا ناممکن نہیں ہے، ہم اپنا GraphQL اینڈ پوائنٹ چلا سکتے ہیں اور چین لاگز سے تصدیق نامے حاصل کر سکتے ہیں، لیکن یہ ہمارے مقاصد کے لیے ضرورت سے زیادہ ہے۔ + +- ہم تصدیق کنندہ کی شناخت کو نہیں دیکھتے ہیں۔ کوئی بھی ہمیں غلط معلومات فراہم کر سکتا ہے۔ ایک حقیقی دنیا کے نفاذ میں ہمارے پاس قابل اعتماد تصدیق کنندگان کا ایک سیٹ ہوگا اور ہم صرف ان کے تصدیق ناموں کو دیکھیں گے۔ + +اسے عملی طور پر دیکھنے کے لیے، موجودہ IdP اور SP کو روکیں اور یہ کمانڈز چلائیں: + +```sh +git checkout email-address +pnpm install +pnpm start +``` + +پھر اپنا ای میل پتہ فراہم کریں۔ ایسا کرنے کے آپ کے پاس دو طریقے ہیں: + +- ایک نجی کلید کا استعمال کرتے ہوئے ایک والیٹ درآمد کریں، اور ٹیسٹنگ نجی کلید `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80` کا استعمال کریں۔ + +- اپنے ای میل پتے کے لیے ایک تصدیق نامہ شامل کریں: + + 1. تصدیق ایکسپلورر میں [اسکیما پر](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977) براؤز کریں۔ + + 2. **اسکیما کے ساتھ تصدیق کریں** پر کلک کریں۔ + + 3. وصول کنندہ کے طور پر اپنا ایتھیریم پتہ، ای میل پتے کے طور پر اپنا ای میل پتہ درج کریں، اور **آن چین** منتخب کریں۔ پھر **تصدیق نامہ بنائیں** پر کلک کریں۔ + + 4. اپنے والیٹ میں ٹرانزیکشن کی منظوری دیں۔ گیس کی ادائیگی کے لیے آپ کو [آپٹیمزم بلاک چین](https://app.optimism.io/bridge/deposit) پر کچھ ETH کی ضرورت ہوگی۔ + +کسی بھی طرح، اس کے بعد [http://localhost:3000](http://localhost:3000) پر براؤز کریں اور ہدایات پر عمل کریں۔ اگر آپ نے ٹیسٹنگ نجی کلید درآمد کی ہے، تو آپ کو موصول ہونے والا ای میل `test_addr_0@example.com` ہے۔ اگر آپ نے اپنا پتہ استعمال کیا ہے، تو یہ وہی ہونا چاہیے جس کی آپ نے تصدیق کی ہے۔ + +### تفصیلی وضاحت + +![ایتھیریم پتے سے ای میل تک پہنچنا](./fig-06-saml-sig-n-email.png) + +نئے اقدامات GraphQL مواصلت، اقدامات 5.6 اور 5.7 ہیں۔ + +دوبارہ، یہاں `idp.mts` کے تبدیل شدہ حصے ہیں۔ + +```typescript +import { GraphQLClient } from 'graphql-request' +import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk' +``` + +ہمیں جن لائبریریوں کی ضرورت ہے انہیں درآمد کریں۔ + +```typescript +const graphqlEndpointUrl = "https://optimism.easscan.org/graphql" +``` + +ہر بلاک چین کے لیے [ایک الگ اینڈ پوائنٹ](https://docs.attest.org/docs/developer-tools/api) ہے۔ + +```typescript +const graphqlClient = new GraphQLClient(graphqlEndpointUrl, { fetch }) +``` + +ایک نیا `GraphQLClient` کلائنٹ بنائیں جسے ہم اینڈ پوائنٹ سے استفسار کرنے کے لیے استعمال کر سکتے ہیں۔ + +```typescript +const graphqlSchema = 'string emailAddress' +const graphqlEncoder = new SchemaEncoder(graphqlSchema) +``` + +GraphQL ہمیں صرف بائٹس کے ساتھ ایک مبہم ڈیٹا آبجیکٹ دیتا ہے۔ اسے سمجھنے کے لیے ہمیں اسکیما کی ضرورت ہے۔ + +```typescript +const ethereumAddressToEmail = async ethAddr => { +``` + +ایتھیریم پتے سے ای میل پتے تک پہنچنے کا ایک فنکشن۔ + +```typescript + const query = ` + query GetAttestationsByRecipient { +``` + +یہ ایک GraphQL استفسار ہے۔ + +```typescript + attestations( +``` + +ہم تصدیق نامے تلاش کر رہے ہیں۔ + +```typescript + where: { + recipient: { equals: "${getAddress(ethAddr)}" } + schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" } + } +``` + +ہم جو تصدیق نامے چاہتے ہیں وہ ہمارے اسکیما میں ہیں، جہاں وصول کنندہ `getAddress(ethAddr)` ہے۔ [`getAddress`](https://viem.sh/docs/utilities/getAddress#getaddress) فنکشن اس بات کو یقینی بناتا ہے کہ ہمارے پتے کا [چیک سم](https://github.com/ethereum/ercs/blob/master/ERCS/erc-55.md) درست ہے۔ یہ ضروری ہے کیونکہ GraphQL کیس-اہم ہے۔ "0xBAD060A7"، "0xBad060A7"، اور "0xbad060a7" مختلف قدریں ہیں۔ + +```typescript + take: 1 +``` + +ہمیں کتنے ہی تصدیق نامے ملیں، ہم صرف پہلا چاہتے ہیں۔ + +```typescript + ) { + data + id + attester + } + }` +``` + +ہم جو فیلڈز وصول کرنا چاہتے ہیں۔ + +- `attester`: وہ پتہ جس نے تصدیق نامہ جمع کرایا۔ عام طور پر اس کا استعمال یہ فیصلہ کرنے کے لیے کیا جاتا ہے کہ آیا تصدیق نامے پر بھروسہ کرنا ہے یا نہیں۔ +- `id`: تصدیق نامہ آئی ڈی۔ آپ اس قدر کا استعمال [آن چین پر تصدیق نامہ پڑھنے](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000021?tab=read_proxy&source_address=0x4E0275Ea5a89e7a3c1B58411379D1a0eDdc5b088#0xa3112a64) کے لیے کر سکتے ہیں تاکہ یہ تصدیق کی جا سکے کہ GraphQL استفسار سے ملنے والی معلومات درست ہے۔ +- `data`: اسکیما ڈیٹا (اس معاملے میں، ای میل پتہ)۔ + +```typescript + const queryResult = await graphqlClient.request(query) + + if (queryResult.attestations.length == 0) + return "no_address@available.is" +``` + +اگر کوئی تصدیق نامہ نہیں ہے، تو ایک ایسی قدر واپس کریں جو واضح طور پر غلط ہو، لیکن جو سروس فراہم کنندہ کو درست معلوم ہو۔ + +```typescript + const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data) + return attestationDataFields[0].value.value +} +``` + +اگر کوئی قدر ہے، تو ڈیٹا کو ڈی کوڈ کرنے کے لیے `decodeData` کا استعمال کریں۔ ہمیں اس کے فراہم کردہ میٹا ڈیٹا کی ضرورت نہیں، صرف قدر خود۔ + +```typescript + const loginResponse = await idp.createLoginResponse( + sp, + { + . + . + . + }, + "post", + { + email: await ethereumAddressToEmail(req.params.account) + } + ); +``` + +ای میل پتہ حاصل کرنے کے لیے نئے فنکشن کا استعمال کریں۔ + +## غیر مرکزیت کے بارے میں کیا خیال ہے؟ + +اس ترتیب میں صارفین وہ شخص ہونے کا بہانہ نہیں کر سکتے جو وہ نہیں ہیں، جب تک کہ ہم ایتھیریم سے ای میل پتے کی میپنگ کے لیے قابل اعتماد تصدیق کنندگان پر انحصار کرتے ہیں۔ تاہم، ہمارا شناختی فراہم کنندہ اب بھی ایک مرکزی جزو ہے۔ جس کے پاس بھی شناختی فراہم کنندہ کی نجی کلید ہے وہ سروس فراہم کنندہ کو غلط معلومات بھیج سکتا ہے۔ + +[ملٹی پارٹی کمپیوٹیشن (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) کا استعمال کرتے ہوئے ایک حل ہو سکتا ہے۔ مجھے امید ہے کہ مستقبل کے ٹیوٹوریل میں اس کے بارے میں لکھوں گا۔ + +## نتیجہ + +لاگ آن معیار، جیسے ایتھیریم دستخط، کو اپنانے میں مرغی اور انڈے کا مسئلہ درپیش ہے۔ سروس فراہم کنندگان وسیع تر ممکنہ مارکیٹ کو اپیل کرنا چاہتے ہیں۔ صارفین اپنے لاگ آن معیار کی حمایت کے بارے میں فکر کیے بغیر خدمات تک رسائی حاصل کرنا چاہتے ہیں۔ +اڈاپٹر بنانا، جیسے کہ ایتھیریم IdP، ہمیں اس رکاوٹ کو دور کرنے میں مدد کر سکتا ہے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/ur/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md new file mode 100644 index 00000000000..a15aafd580f --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md @@ -0,0 +1,156 @@ +--- +title: "ایتھیریم ڈیولپمنٹ کے ساتھ شروعات کرنا" +description: "یہ ایتھیریم ڈیولپمنٹ کے ساتھ شروعات کرنے کے لیے ایک ابتدائی گائیڈ ہے۔ ہم آپ کو ایک API اینڈ پوائنٹ شروع کرنے، کمانڈ لائن کی درخواست کرنے سے لے کر آپ کی پہلی ویب 3 اسکرپٹ لکھنے تک لے جائیں گے! بلاک چین ڈیولپمنٹ کے کسی تجربے کی ضرورت نہیں ہے!" +author: "Elan Halpern" +tags: + [ + "javascript", + "ethers.js", + "نوڈز", + "querying", + "alchemy" + ] +skill: beginner +lang: ur-in +published: 2020-10-30 +source: Medium +sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f +--- + +![ایتھیریم اور Alchemy لوگو](./ethereum-alchemy.png) + +یہ ایتھیریم ڈیولپمنٹ کے ساتھ شروعات کرنے کے لیے ایک ابتدائی گائیڈ ہے۔ اس ٹیوٹوریل کے لیے ہم [Alchemy](https://alchemyapi.io/) کا استعمال کریں گے، جو کہ معروف بلاک چین ڈیولپر پلیٹ فارم ہے جو Maker، 0x، MyEtherWallet، Dharma، اور Kyber سمیت 70% سرفہرست بلاک چین ایپس کے لاکھوں صارفین کو تقویت فراہم کرتا ہے۔ Alchemy ہمیں ایتھیریم چین پر ایک API اینڈ پوائنٹ تک رسائی فراہم کرے گا تاکہ ہم ٹرانزیکشنز کو پڑھ اور لکھ سکیں۔ + +ہم آپ کو Alchemy کے ساتھ سائن اپ کرنے سے لے کر آپ کی پہلی ویب 3 اسکرپٹ لکھنے تک لے جائیں گے! بلاک چین ڈیولپمنٹ کے کسی تجربے کی ضرورت نہیں ہے! + +## 1۔ ایک مفت Alchemy اکاؤنٹ کے لیے سائن اپ کریں {#sign-up-for-a-free-alchemy-account} + +Alchemy کے ساتھ ایک اکاؤنٹ بنانا آسان ہے، [یہاں مفت میں سائن اپ کریں](https://auth.alchemy.com/)۔ + +## 2۔ ایک Alchemy ایپ بنائیں {#create-an-alchemy-app} + +ایتھیریم چین کے ساتھ کمیونیکیٹ کرنے اور Alchemy کی پروڈکٹس کا استعمال کرنے کے لیے، آپ کو اپنی درخواستوں کی توثیق کرنے کے لیے ایک API کی کی ضرورت ہے۔ + +آپ [ڈیش بورڈ سے API کیز بنا سکتے ہیں](https://dashboard.alchemy.com/)۔ ایک نئی کی بنانے کے لیے، نیچے دکھائے گئے "ایپ بنائیں" (Create App) پر نیویگیٹ کریں: + +_ہمیں اپنا ڈیش بورڈ دکھانے کی اجازت دینے کے لیے [_ShapeShift_](https://shapeshift.com/) کا خصوصی شکریہ!_ + +![Alchemy ڈیش بورڈ](./alchemy-dashboard.png) + +اپنی نئی کی حاصل کرنے کے لیے "ایپ بنائیں" (Create App) کے تحت تفصیلات پُر کریں۔ آپ یہاں اپنی پہلے بنائی ہوئی ایپس اور اپنی ٹیم کی بنائی ہوئی ایپس کو بھی دیکھ سکتے ہیں۔ کسی بھی ایپ کے لیے "کی دیکھیں" (View Key) پر کلک کرکے موجودہ کیز حاصل کریں۔ + +![Alchemy کے ساتھ ایپ بنانے کا اسکرین شاٹ](./create-app.png) + +آپ "ایپس" (Apps) پر ہوور کرکے اور کسی ایک کو منتخب کرکے بھی موجودہ API کیز حاصل کر سکتے ہیں۔ آپ یہاں "کی دیکھیں" (View Key) کے ساتھ ساتھ مخصوص ڈومینز کو وائٹ لسٹ کرنے، کئی ڈیولپر ٹولز دیکھنے اور اینالیٹکس دیکھنے کے لیے "ایپ میں ترمیم کریں" (Edit App) بھی کر سکتے ہیں۔ + +![ایک صارف کو API کیز حاصل کرنے کا طریقہ دکھانے والا Gif](./pull-api-keys.gif) + +## 3۔ کمانڈ لائن سے ایک درخواست کریں {#make-a-request-from-the-command-line} + +JSON-RPC اور curl کا استعمال کرتے ہوئے Alchemy کے ذریعے ایتھیریم بلاک چین کے ساتھ انٹریکٹ کریں۔ + +مینوئل درخواستوں کے لیے، ہم `POST` درخواستوں کے ذریعے `JSON-RPC` کے ساتھ انٹریکٹ کرنے کی تجویز دیتے ہیں۔ بس `Content-Type: application/json` ہیڈر پاس کریں اور اپنی کوئری کو `POST` باڈی کے طور پر درج ذیل فیلڈز کے ساتھ پاس کریں: + +- `jsonrpc`: JSON-RPC ورژن — فی الحال، صرف `2.0` سپورٹڈ ہے۔ +- `method`: ETH API کا طریقہ۔ [API کا حوالہ دیکھیں۔](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc) +- `params`: طریقہ کار کو پاس کیے جانے والے پیرامیٹرز کی ایک فہرست۔ +- `id`: آپ کی درخواست کا ID۔ جواب کے ذریعے واپس کیا جائے گا تاکہ آپ ٹریک رکھ سکیں کہ کونسا جواب کس درخواست سے تعلق رکھتا ہے۔ + +یہاں ایک مثال ہے جسے آپ موجودہ گیس کی قیمت حاصل کرنے کے لیے کمانڈ لائن سے چلا سکتے ہیں: + +```bash +curl https://eth-mainnet.alchemyapi.io/v2/demo \ +-X POST \ +-H "Content-Type: application/json" \ +-d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' +``` + +_**نوٹ:** [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) کو اپنی API کی `https://eth-mainnet.alchemyapi.io/v2/**your-api-key` سے بدلیں۔_ + +**نتائج:** + +```json +{ "id": 73,"jsonrpc": "2.0","result": "0x09184e72a000" // 10000000000000 } +``` + +## 4. اپنا ویب 3 کلائنٹ سیٹ اپ کریں {#set-up-your-web3-client} + +**اگر آپ کے پاس پہلے سے کلائنٹ ہے،** تو اپنے موجودہ نوڈ پرووائیڈر URL کو اپنی API کی کے ساتھ Alchemy URL میں تبدیل کریں: `“https://eth-mainnet.alchemyapi.io/v2/your-api-key"` + +**_نوٹ:_** نیچے دی گئی اسکرپٹس کو **نوڈ کانٹیکسٹ** میں چلانے یا **فائل میں محفوظ کرنے** کی ضرورت ہے، کمانڈ لائن سے نہیں۔ اگر آپ کے پاس پہلے سے نوڈ یا npm انسٹال نہیں ہے، تو میکس کے لیے یہ فوری [سیٹ اپ گائیڈ](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs) دیکھیں۔ + +بہت ساری [ویب 3 لائبریریاں](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries) ہیں جنہیں آپ Alchemy کے ساتھ انٹیگریٹ کر سکتے ہیں، تاہم، ہم [Alchemy Web3](https://docs.alchemy.com/reference/api-overview) استعمال کرنے کی تجویز دیتے ہیں، جو web3.js کا ایک ڈراپ ان متبادل ہے، جسے Alchemy کے ساتھ بغیر کسی رکاوٹ کے کام کرنے کے لیے بنایا اور کنفیگر کیا گیا ہے۔ یہ متعدد فوائد فراہم کرتا ہے جیسے خودکار دوبارہ کوششیں اور مضبوط WebSocket سپورٹ۔ + +AlchemyWeb3.js کو انسٹال کرنے کے لیے، **اپنی پروجیکٹ ڈائرکٹری پر نیویگیٹ کریں** اور چلائیں: + +**Yarn کے ساتھ:** + +``` +yarn add @alch/alchemy-web3 +``` + +**NPM کے ساتھ:** + +``` +npm install @alch/alchemy-web3 +``` + +Alchemy کے نوڈ انفراسٹرکچر کے ساتھ انٹریکٹ کرنے کے لیے، NodeJS میں چلائیں یا اسے جاوا اسکرپٹ فائل میں شامل کریں: + +```js +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3( + "https://eth-mainnet.alchemyapi.io/v2/your-api-key" +) +``` + +## 5. اپنی پہلی ویب 3 اسکرپٹ لکھیں! {#write-your-first-web3-script} + +اب تھوڑی ویب 3 پروگرامنگ میں عملی طور پر کام کرنے کے لیے، ہم ایک سادہ اسکرپٹ لکھیں گے جو ایتھیریم مین نیٹ سے تازہ ترین بلاک نمبر پرنٹ کرتی ہے۔ + +**1.** **اگر آپ نے پہلے سے ایسا نہیں کیا ہے، تو اپنے ٹرمینل میں ایک نئی پروجیکٹ ڈائرکٹری بنائیں اور اس میں cd کریں:** + +``` +mkdir web3-example +cd web3-example +``` + +**2.** **اگر آپ نے پہلے سے نہیں کیا ہے تو Alchemy web3 (یا کوئی بھی web3) ڈیپینڈینسی کو اپنے پروجیکٹ میں انسٹال کریں:** + +``` +npm install @alch/alchemy-web3 +``` + +**3.** **`index.js` نامی ایک فائل بنائیں اور اس میں درج ذیل مواد شامل کریں:** + +> آپ کو بالآخر `demo` کو اپنی Alchemy HTTP API کی سے بدلنا چاہیے۔ + +```js +async function main() { + const { createAlchemyWeb3 } = require("@alch/alchemy-web3") + const web3 = createAlchemyWeb3("https://eth-mainnet.alchemyapi.io/v2/demo") + const blockNumber = await web3.eth.getBlockNumber() + console.log("تازہ ترین بلاک نمبر ہے " + blockNumber) +} +main() +``` + +async چیزوں سے ناواقف ہیں؟ یہ [میڈیم پوسٹ](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c) دیکھیں۔ + +\*\*4۔ **اسے اپنے ٹرمینل میں نوڈ کا استعمال کرتے ہوئے چلائیں** + +``` +node index.js +``` + +\*\*5۔ **اب آپ کو اپنے کنسول میں تازہ ترین بلاک نمبر کا آؤٹ پٹ نظر آنا چاہیے!** + +``` +تازہ ترین بلاک نمبر 11043912 ہے +``` + +**واہ!** مبارک ہو! **آپ نے ابھی ابھی Alchemy کا استعمال کرتے ہوئے اپنی پہلی ویب 3 اسکرپٹ لکھی ہے 🎉** + +یقین نہیں ہے کہ آگے کیا کرنا ہے؟ ہمارے [ہیلو ورلڈ اسمارٹ کنٹریکٹ گائیڈ](https://www.alchemy.com/docs/hello-world-smart-contract) میں اپنا پہلا اسمارٹ کنٹریکٹ ڈیپلائے کرنے کی کوشش کریں اور کچھ سولیڈیٹی پروگرامنگ میں عملی کام کریں، یا [ڈیش بورڈ ڈیمو ایپ](https://docs.alchemyapi.io/tutorials/demo-app) کے ساتھ اپنے ڈیش بورڈ کے علم کی جانچ کریں! + +_[Alchemy کے ساتھ مفت میں سائن اپ کریں](https://auth.alchemy.com/)، ہماری [دستاویزات](https://www.alchemy.com/docs/) دیکھیں، اور تازہ ترین خبروں کے لیے، ہمیں [Twitter](https://twitter.com/AlchemyPlatform) پر فالو کریں_۔ diff --git a/public/content/translations/ur/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/ur/developers/tutorials/guide-to-smart-contract-security-tools/index.md new file mode 100644 index 00000000000..26d546f1b72 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -0,0 +1,102 @@ +--- +title: "اسمارٹ کنٹریکٹ سیکیورٹی ٹولز کے لئے ایک گائیڈ" +description: "تین مختلف ٹیسٹنگ اور پروگرام کے تجزیہ کی تکنیکوں کا ایک جائزہ" +author: "Trailofbits" +lang: ur-in +tags: [ "solidity", "اسمارٹ معاہدات", "سیکورٹی" ] +skill: intermediate +published: 2020-09-07 +source: Building secure contracts +sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis +--- + +ہم تین مخصوص ٹیسٹنگ اور پروگرام کے تجزیہ کی تکنیکوں کا استعمال کرنے جا رہے ہیں: + +- **[Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) کے ساتھ اسٹیٹک تجزیہ۔** پروگرام کے تمام راستوں کا تخمینہ لگایا جاتا ہے اور ایک ہی وقت میں تجزیہ کیا جاتا ہے، مختلف پروگرام پریزنٹیشنز (مثال کے طور پر، کنٹرول-فلو-گراف) کے ذریعے۔ +- **[Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) کے ساتھ فزنگ۔** کوڈ کو ٹرانزیکشنز کی سیوڈو-رینڈم جنریشن کے ساتھ عمل میں لایا جاتا ہے۔ فزر دی گئی پراپرٹی کی خلاف ورزی کرنے کے لیے ٹرانزیکشنز کا ایک سلسلہ تلاش کرنے کی کوشش کرے گا۔ +- **[Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) کے ساتھ سمبولک ایکزیکیوشن۔** ایک رسمی تصدیقی تکنیک، جو ہر ایکزیکیوشن پاتھ کو ایک ریاضیاتی فارمولے میں ترجمہ کرتی ہے، جس کے اوپر رکاوٹوں کی جانچ کی جا سکتی ہے۔ + +ہر تکنیک کے فوائد اور نقصانات ہیں، اور یہ [مخصوص معاملات](#determining-security-properties) میں مفید ہوگی: + +| تکنیک | ٹول | استعمال | رفتار | چھوٹے ہوئے بگز | غلط الارم | +| ----------------- | --------- | ----------------------------- | ----- | -------------- | --------- | +| اسٹیٹک تجزیہ | Slither | CLI اور اسکرپٹس | سیکنڈ | معتدل | کم | +| فزنگ | Echidna | Solidity پراپرٹیز | منٹ | کم | کوئی نہیں | +| سمبولک ایکزیکیوشن | Manticore | Solidity پراپرٹیز اور اسکرپٹس | گھنٹے | کوئی نہیں\* | کوئی نہیں | + +\* اگر تمام راستوں کو ٹائم آؤٹ کے بغیر دریافت کیا جاتا ہے + +**Slither** سیکنڈوں میں کنٹریکٹس کا تجزیہ کرتا ہے، تاہم، اسٹیٹک تجزیہ غلط الارم کا باعث بن سکتا ہے اور پیچیدہ جانچ (مثال کے طور پر، حسابی جانچ) کے لیے کم موزوں ہوگا۔ بلٹ ان ڈیٹیکٹرز تک پش بٹن رسائی کے لیے API کے ذریعے Slither چلائیں یا صارف کی طرف سے متعین کردہ جانچ کے لیے API کے ذریعے۔ + +**Echidna** کو کئی منٹ تک چلنے کی ضرورت ہے اور یہ صرف سچے مثبت نتائج پیدا کرے گا۔ Echidna صارف کی فراہم کردہ سیکیورٹی پراپرٹیز کی جانچ کرتا ہے، جو Solidity میں لکھی گئی ہیں۔ یہ بگز کو چھوڑ سکتا ہے کیونکہ یہ رینڈم ایکسپلوریشن پر مبنی ہے۔ + +**Manticore** "سب سے بھاری وزن" کا تجزیہ کرتا ہے۔ Echidna کی طرح، Manticore صارف کی فراہم کردہ پراپرٹیز کی تصدیق کرتا ہے۔ اسے چلنے کے لیے زیادہ وقت درکار ہوگا، لیکن یہ کسی پراپرٹی کی درستگی کو ثابت کر سکتا ہے اور غلط الارم کی اطلاع نہیں دے گا۔ + +## تجویز کردہ ورک فلو {#suggested-workflow} + +Slither کے بلٹ ان ڈیٹیکٹرز کے ساتھ شروع کریں تاکہ یہ یقینی بنایا جا سکے کہ کوئی سادہ بگز ابھی موجود نہیں ہیں یا بعد میں متعارف نہیں ہوں گے۔ وراثت، متغیر انحصار، اور ساختی مسائل سے متعلق پراپرٹیز کی جانچ کے لیے Slither کا استعمال کریں۔ جیسے جیسے کوڈبیس بڑھتا ہے، اسٹیٹ مشین کی مزید پیچیدہ پراپرٹیز کی جانچ کے لیے Echidna کا استعمال کریں۔ Solidity سے غیر دستیاب تحفظات کے لیے کسٹم چیکس تیار کرنے کے لیے Slither پر دوبارہ جائیں، جیسے کسی فنکشن کو اوور رائڈ ہونے سے بچانا۔ آخر میں، اہم سیکیورٹی پراپرٹیز کی ٹارگٹڈ تصدیق کے لیے Manticore کا استعمال کریں، جیسے، حسابی آپریشنز۔ + +- عام مسائل کو پکڑنے کے لیے Slither کے CLI کا استعمال کریں +- اپنے کنٹریکٹ کی اعلیٰ سطحی سیکیورٹی پراپرٹیز کی جانچ کے لیے Echidna کا استعمال کریں +- کسٹم اسٹیٹک چیکس لکھنے کے لیے Slither کا استعمال کریں +- جب آپ اہم سیکیورٹی پراپرٹیز کی گہری یقین دہانی چاہتے ہیں تو Manticore کا استعمال کریں + +**یونٹ ٹیسٹ پر ایک نوٹ**۔ اعلیٰ معیار کا سافٹ ویئر بنانے کے لیے یونٹ ٹیسٹ ضروری ہیں۔ تاہم، یہ تکنیکیں سیکیورٹی کی خامیوں کو تلاش کرنے کے لیے سب سے زیادہ موزوں نہیں ہیں۔ وہ عام طور پر کوڈ کے مثبت رویوں کی جانچ کے لیے استعمال ہوتے ہیں (یعنی، کوڈ عام سیاق و سباق میں توقع کے مطابق کام کرتا ہے)، جبکہ سیکیورٹی کی خامیاں ان ایج کیسز میں رہتی ہیں جن پر ڈیولپرز نے غور نہیں کیا تھا۔ درجنوں اسمارٹ کنٹریکٹ سیکیورٹی جائزوں کے ہمارے مطالعے میں، [یونٹ ٹیسٹ کوریج کا سیکیورٹی کی خامیوں کی تعداد یا شدت پر کوئی اثر نہیں تھا](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) جو ہمیں اپنے کلائنٹ کے کوڈ میں ملیں۔ + +## سیکیورٹی پراپرٹیز کا تعین کرنا {#determining-security-properties} + +اپنے کوڈ کو مؤثر طریقے سے ٹیسٹ اور تصدیق کرنے کے لیے، آپ کو ان علاقوں کی نشاندہی کرنی ہوگی جن پر توجہ کی ضرورت ہے۔ چونکہ سیکیورٹی پر خرچ ہونے والے آپ کے وسائل محدود ہیں، اس لیے اپنی کوشش کو بہتر بنانے کے لیے اپنے کوڈبیس کے کمزور یا اعلیٰ قیمت والے حصوں کی گنجائش کا تعین کرنا ضروری ہے۔ تھریٹ ماڈلنگ مدد کر سکتی ہے۔ جائزہ لینے پر غور کریں: + +- [ریپڈ رسک اسیسمنٹس](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (ہمارا ترجیحی طریقہ جب وقت کم ہو) +- [ڈیٹا سینٹرک سسٹم تھریٹ ماڈلنگ کے لیے گائیڈ](https://csrc.nist.gov/pubs/sp/800/154/ipd) (عرف NIST 800-154) +- [Shostack تھریٹ ماڈلنگ](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998) +- [STRIDE](https://wikipedia.org/wiki/STRIDE_\(security\)) / [DREAD](https://wikipedia.org/wiki/DREAD_\(risk_assessment_model\)) +- [PASTA](https://wikipedia.org/wiki/Threat_model#P.A.S.T.A.) +- [Assertions کا استعمال](https://blog.regehr.org/archives/1091) + +### اجزاء {#components} + +یہ جاننا کہ آپ کیا جانچنا چاہتے ہیں، آپ کو صحیح ٹول منتخب کرنے میں بھی مدد ملے گی۔ + +وہ وسیع علاقے جو اسمارٹ کنٹریکٹس کے لیے اکثر متعلقہ ہوتے ہیں ان میں شامل ہیں: + +- **اسٹیٹ مشین۔** زیادہ تر کنٹریکٹس کو اسٹیٹ مشین کے طور پر پیش کیا جا سکتا ہے۔ یہ جانچنے پر غور کریں کہ (1) کوئی غلط اسٹیٹ تک نہیں پہنچا جا سکتا، (2) اگر کوئی اسٹیٹ درست ہے تو اس تک پہنچا جا سکتا ہے، اور (3) کوئی اسٹیٹ کنٹریکٹ کو ٹریپ نہیں کرتی ہے۔ + + - Echidna اور Manticore اسٹیٹ مشین کی تفصیلات کی جانچ کے لیے ترجیحی ٹولز ہیں۔ + +- **رسائی کنٹرولز۔** اگر آپ کے سسٹم میں مراعات یافتہ صارفین ہیں (مثال کے طور پر، ایک مالک، کنٹرولرز، ...) آپ کو یہ یقینی بنانا ہوگا کہ (1) ہر صارف صرف مجاز کارروائیاں انجام دے سکتا ہے اور (2) کوئی صارف زیادہ مراعات یافتہ صارف کی کارروائیوں کو بلاک نہیں کر سکتا۔ + + - Slither، Echidna اور Manticore درست رسائی کنٹرولز کی جانچ کر سکتے ہیں۔ مثال کے طور پر، Slither یہ جانچ سکتا ہے کہ صرف وائٹ لسٹ کیے گئے فنکشنز میں onlyOwner موڈیفائر کی کمی ہے۔ Echidna اور Manticore زیادہ پیچیدہ رسائی کنٹرول کے لیے مفید ہیں، جیسے کہ اجازت صرف اس صورت میں دی جاتی ہے جب کنٹریکٹ کسی دی گئی اسٹیٹ تک پہنچ جائے۔ + +- **حسابی آپریشنز۔** حسابی آپریشنز کی درستگی کی جانچ کرنا بہت اہم ہے۔ ہر جگہ `SafeMath` کا استعمال اوور فلو/انڈر فلو کو روکنے کے لیے ایک اچھا قدم ہے، تاہم، آپ کو اب بھی دیگر حسابی خامیوں پر غور کرنا چاہیے، بشمول راؤنڈنگ کے مسائل اور وہ خامیاں جو کنٹریکٹ کو ٹریپ کرتی ہیں۔ + + - Manticore یہاں بہترین انتخاب ہے۔ Echidna کا استعمال کیا جا سکتا ہے اگر حساب کتاب SMT سالور کے دائرہ کار سے باہر ہو۔ + +- **وراثت کی درستگی۔** Solidity کنٹریکٹس کثیر وراثت پر بہت زیادہ انحصار کرتے ہیں۔ غلطیاں جیسے کہ `super` کال سے محروم شیڈونگ فنکشن اور غلط تشریح شدہ c3 لینیئرائزیشن آرڈر آسانی سے متعارف ہو سکتے ہیں۔ + + - Slither ان مسائل کا پتہ لگانے کو یقینی بنانے کا ٹول ہے۔ + +- **بیرونی تعاملات۔** کنٹریکٹس ایک دوسرے کے ساتھ تعامل کرتے ہیں، اور کچھ بیرونی کنٹریکٹس پر بھروسہ نہیں کرنا چاہیے۔ مثال کے طور پر، اگر آپ کا کنٹریکٹ بیرونی اوریکلز پر انحصار کرتا ہے، تو کیا یہ محفوظ رہے گا اگر آدھے دستیاب اوریکلز سے سمجھوتہ ہو جائے؟ + + - Manticore اور Echidna آپ کے کنٹریکٹس کے ساتھ بیرونی تعاملات کی جانچ کے لیے بہترین انتخاب ہیں۔ Manticore میں بیرونی کنٹریکٹس کو اسٹب کرنے کے لیے ایک بلٹ ان میکانزم ہے۔ + +- **معیاری مطابقت۔** Ethereum معیارات (مثال کے طور پر، ERC20) کے ڈیزائن میں خامیوں کی ایک تاریخ ہے۔ اس معیار کی حدود سے آگاہ رہیں جس پر آپ تعمیر کر رہے ہیں۔ + - Slither، Echidna، اور Manticore آپ کو کسی دیے گئے معیار سے انحراف کا پتہ لگانے میں مدد کریں گے۔ + +### ٹول سلیکشن چیٹ شیٹ {#tool-selection-cheatsheet} + +| جز | ٹولز | مثالیں | +| --------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| اسٹیٹ مشین | Echidna, Manticore | | +| رسائی کنٹرول | Slither, Echidna, Manticore | [Slither exercise 2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md)، [Echidna exercise 2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) | +| حسابی آپریشنز | Manticore, Echidna | [Echidna exercise 1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md)، [Manticore exercises 1 - 3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) | +| وراثت کی درستگی | Slither | [Slither exercise 1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) | +| بیرونی تعاملات | Manticore, Echidna | | +| معیاری مطابقت | Slither, Echidna, Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) | + +آپ کے اہداف کے لحاظ سے دیگر علاقوں کی جانچ کرنے کی ضرورت ہوگی، لیکن توجہ کے یہ موٹے دانے والے علاقے کسی بھی اسمارٹ کنٹریکٹ سسٹم کے لیے ایک اچھی شروعات ہیں۔ + +ہمارے عوامی آڈٹس میں تصدیق شدہ یا آزمائی گئی پراپرٹیز کی مثالیں شامل ہیں۔ حقیقی دنیا کی سیکیورٹی پراپرٹیز کا جائزہ لینے کے لیے درج ذیل رپورٹس کے `Automated Testing and Verification` سیکشنز کو پڑھنے پر غور کریں: + +- [0x](https://github.com/trailofbits/publications/blob/master/reviews/0x-protocol.pdf) +- [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf) diff --git a/public/content/translations/ur/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/ur/developers/tutorials/hello-world-smart-contract-fullstack/index.md new file mode 100644 index 00000000000..e971035a361 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/hello-world-smart-contract-fullstack/index.md @@ -0,0 +1,1540 @@ +--- +title: "ہیلو ورلڈ اسمارٹ کنٹریکٹ برائے مبتدی - فل اسٹیک" +description: "Ethereum پر ایک سادہ اسمارٹ کنٹریکٹ لکھنے اور اسے ڈیپلائے کرنے کے بارے میں تعارفی ٹیوٹوریل۔" +author: "nstrike2" +tags: + [ + "solidity", + "hardhat", + "alchemy", + "اسمارٹ معاہدات", + "تعینات کرنا", + "بلاک ایکسپلورر", + "فرنٹ اینڈ", + "لین دین" + ] +skill: beginner +lang: ur-in +published: 2021-10-25 +--- + +اگر آپ بلاک چین ڈیولپمنٹ میں نئے ہیں اور یہ نہیں جانتے کہ کہاں سے شروع کرنا ہے یا اسمارٹ کنٹریکٹس کو کیسے ڈیپلائے اور ان کے ساتھ تعامل کرنا ہے تو یہ گائیڈ آپ کے لیے ہے۔ ہم [MetaMask](https://metamask.io)، [Solidity](https://docs.soliditylang.org/en/v0.8.0/)، [Hardhat](https://hardhat.org)، اور [Alchemy](https://alchemy.com/eth) کا استعمال کرتے ہوئے Goerli ٹیسٹ نیٹ ورک پر ایک سادہ، اسمارٹ کنٹریکٹ بنانے اور اسے ڈیپلائے کرنے کے عمل سے گزریں گے۔ + +اس ٹیوٹوریل کو مکمل کرنے کے لیے آپ کو ایک Alchemy اکاؤنٹ کی ضرورت ہوگی۔ [ایک مفت اکاؤنٹ کے لیے سائن اپ کریں](https://www.alchemy.com/). + +اگر آپ کو کسی بھی وقت کوئی سوال ہو تو، بلا جھجھک [Alchemy Discord](https://discord.gg/gWuC7zB) میں رابطہ کریں! + +## حصہ 1 - Hardhat کا استعمال کرتے ہوئے اپنا اسمارٹ کنٹریکٹ بنائیں اور ڈیپلائے کریں {#part-1} + +### Ethereum نیٹ ورک سے جڑیں {#connect-to-the-ethereum-network} + +Ethereum چین سے درخواستیں کرنے کے بہت سے طریقے ہیں۔ سادگی کے لیے، ہم Alchemy پر ایک مفت اکاؤنٹ استعمال کریں گے، جو ایک بلاک چین ڈیولپر پلیٹ فارم اور API ہے جو ہمیں خود ایک نوڈ چلائے بغیر Ethereum چین کے ساتھ بات چیت کرنے کی اجازت دیتا ہے۔ Alchemy میں نگرانی اور تجزیات کے لیے ڈیولپر ٹولز بھی ہیں؛ ہم اس ٹیوٹوریل میں ان سے فائدہ اٹھائیں گے تاکہ یہ سمجھ سکیں کہ ہمارے اسمارٹ کنٹریکٹ کی ڈیپلائیمنٹ میں پس پردہ کیا ہو رہا ہے۔ + +### اپنی ایپ اور API کلید بنائیں {#create-your-app-and-api-key} + +ایک بار جب آپ Alchemy اکاؤنٹ بنا لیتے ہیں، تو آپ ایک ایپ بنا کر ایک API کلید تیار کر سکتے ہیں۔ یہ آپ کو Goerli ٹیسٹ نیٹ پر درخواستیں بھیجنے کی اجازت دے گا۔ اگر آپ ٹیسٹ نیٹ سے واقف نہیں ہیں تو آپ [نیٹ ورک منتخب کرنے کے لیے Alchemy کی گائیڈ پڑھ سکتے ہیں](https://www.alchemy.com/docs/choosing-a-web3-network)۔ + +Alchemy ڈیش بورڈ پر، نیویگیشن بار میں **ایپس** ڈراپ ڈاؤن تلاش کریں اور **ایپ بنائیں** پر کلک کریں۔ + +![Hello world create app](./hello-world-create-app.png) + +اپنی ایپ کو '_ہیلو ورلڈ_' نام دیں اور ایک مختصر تفصیل لکھیں۔ اپنے ماحول کے طور پر **اسٹیجنگ** اور اپنے نیٹ ورک کے طور پر **Goerli** منتخب کریں۔ + +![create app view hello world](./create-app-view-hello-world.png) + +_نوٹ: یقینی بنائیں کہ **Goerli** منتخب کریں، ورنہ یہ ٹیوٹوریل کام نہیں کرے گا۔_ + +**ایپ بنائیں** پر کلک کریں۔ آپ کی ایپ نیچے دی گئی جدول میں ظاہر ہوگی۔ + +### ایک Ethereum اکاؤنٹ بنائیں {#create-an-ethereum-account} + +ٹرانزیکشنز بھیجنے اور وصول کرنے کے لیے آپ کو ایک Ethereum اکاؤنٹ کی ضرورت ہے۔ ہم MetaMask استعمال کریں گے، جو براؤزر میں ایک ورچوئل والیٹ ہے جو صارفین کو اپنے Ethereum اکاؤنٹ کے پتے کا انتظام کرنے کی اجازت دیتا ہے۔ + +آپ [یہاں](https://metamask.io/download) مفت میں MetaMask اکاؤنٹ ڈاؤن لوڈ اور بنا سکتے ہیں۔ جب آپ ایک اکاؤنٹ بنا رہے ہوں، یا اگر آپ کے پاس پہلے سے ہی ایک اکاؤنٹ ہے، تو یقینی بنائیں کہ اوپری دائیں کونے میں "Goerli ٹیسٹ نیٹ ورک" پر سوئچ کریں (تاکہ ہم اصلی پیسے سے نمٹ نہ رہے ہوں)۔ + +### مرحلہ 4: ایک فاسیٹ سے ایتھر شامل کریں {#step-4-add-ether-from-a-faucet} + +اپنے اسمارٹ کنٹریکٹ کو ٹیسٹ نیٹ ورک پر ڈیپلائے کرنے کے لیے، آپ کو کچھ جعلی ETH کی ضرورت ہوگی۔ Goerli نیٹ ورک پر ETH حاصل کرنے کے لیے، Goerli فوسیٹ پر جائیں اور اپنا Goerli اکاؤنٹ ایڈریس درج کریں۔ نوٹ کریں کہ Goerli فوسیٹس حال ہی میں تھوڑے غیر معتبر ہو سکتے ہیں - آزمانے کے لیے اختیارات کی فہرست کے لیے [ٹیسٹ نیٹ ورکس کا صفحہ](/developers/docs/networks/#goerli) دیکھیں۔ + +_نوٹ: نیٹ ورک کی بھیڑ کی وجہ سے، اس میں کچھ وقت لگ سکتا ہے۔_ +`` + +### مرحلہ 5: اپنا بیلنس چیک کریں {#step-5-check-your-balance} + +یہ دوبارہ چیک کرنے کے لیے کہ آیا ETH آپ کے والیٹ میں ہے، آئیے [Alchemy کے کمپوزر ٹول](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) کا استعمال کرتے ہوئے ایک [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) درخواست کریں۔ یہ ہمارے والیٹ میں ETH کی رقم واپس کرے گا۔ مزید جاننے کے لیے [کمپوزر ٹول کا استعمال کیسے کریں اس پر Alchemy کا مختصر ٹیوٹوریل](https://youtu.be/r6sjRxBZJuU) دیکھیں۔ + +اپنا MetaMask اکاؤنٹ کا پتہ درج کریں اور **درخواست بھیجیں** پر کلک کریں۔ آپ کو ایک جواب نظر آئے گا جو نیچے دیے گئے کوڈ کے ٹکڑے جیسا لگتا ہے۔ + +```json +{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" } +``` + +> _نوٹ: یہ نتیجہ wei میں ہے، ETH میں نہیں۔ Wei کو ایتھر کی سب سے چھوٹی اکائی کے طور پر استعمال کیا جاتا ہے۔_ + +اف! ہمارا جعلی پیسہ سب وہیں ہے۔ + +### مرحلہ 6: ہمارے پروجیکٹ کو شروع کریں {#step-6-initialize-our-project} + +سب سے پہلے، ہمیں اپنے پروجیکٹ کے لیے ایک فولڈر بنانا ہوگا۔ اپنی کمانڈ لائن پر جائیں اور درج ذیل کو ان پٹ کریں۔ + +``` +mkdir hello-world +cd hello-world +``` + +اب جب کہ ہم اپنے پروجیکٹ فولڈر کے اندر ہیں، ہم پروجیکٹ کو شروع کرنے کے لیے `npm init` استعمال کریں گے۔ + +> اگر آپ کے پاس ابھی تک npm انسٹال نہیں ہے، تو [Node.js اور npm انسٹال کرنے کے لیے ان ہدایات](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) پر عمل کریں۔ + +اس ٹیوٹوریل کے مقصد کے لیے، اس سے کوئی فرق نہیں پڑتا کہ آپ ابتدائی سوالات کا جواب کیسے دیتے ہیں۔ حوالہ کے لیے ہم نے اسے اس طرح کیا: + +``` +پیکیج کا نام: (hello-world) +ورژن: (1.0.0) +تفصیل: ہیلو ورلڈ اسمارٹ کنٹریکٹ +انٹری پوائنٹ: (index.js) +ٹیسٹ کمانڈ: +گٹ ریپوزٹری: +کلیدی الفاظ: +مصنف: +لائسنس: (ISC) + +/Users/.../.../.../hello-world/package.json پر لکھنے کے بارے میں: + +{ + "name": "hello-world", + "version": "1.0.0", + "description": "ہیلو ورلڈ اسمارٹ کنٹریکٹ", + "main": "index.js", + "scripts": { + "test": "echo \"Error: no test specified\" && exit 1" + }, + "author": "", + "license": "ISC" +} +``` + +package.json کو منظور کریں اور ہم تیار ہیں! + +### مرحلہ 7: Hardhat ڈاؤن لوڈ کریں {#step-7-download-hardhat} + +Hardhat آپ کے Ethereum سافٹ ویئر کو کمپائل، ڈیپلوئے، ٹیسٹ اور ڈیبگ کرنے کے لیے ایک ڈیولپمنٹ ماحول ہے۔ یہ ڈیولپرز کو لائیو چین پر ڈیپلوئے کرنے سے پہلے مقامی طور پر اسمارٹ کنٹریکٹس اور dapps بنانے میں مدد کرتا ہے۔ + +ہمارے `hello-world` پروجیکٹ کے اندر چلائیں: + +``` +npm install --save-dev hardhat +``` + +[انسٹالیشن کی ہدایات](https://hardhat.org/getting-started/#overview) پر مزید تفصیلات کے لیے یہ صفحہ دیکھیں۔ + +### مرحلہ 8: Hardhat پروجیکٹ بنائیں {#step-8-create-hardhat-project} + +ہمارے `hello-world` پروجیکٹ فولڈر کے اندر، چلائیں: + +``` +npx hardhat +``` + +پھر آپ کو ایک خوش آمدیدی پیغام اور یہ منتخب کرنے کا آپشن نظر آئے گا کہ آپ کیا کرنا چاہتے ہیں۔ “create an empty hardhat.config.js” منتخب کریں: + +``` +888 888 888 888 888 +888 888 888 888 888 +888 888 888 888 888 +8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 +888 888 "88b 888P" d88" 888 888 "88b "88b 888 +888 888 .d888888 888 888 888 888 888 .d888888 888 +888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. +888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 + +👷 Hardhat v2.0.11 میں خوش آمدید 👷‍ + +آپ کیا کرنا چاہتے ہیں؟ … +ایک نمونہ پروجیکٹ بنائیں +❯ ایک خالی hardhat.config.js بنائیں +بند کریں +``` + +یہ پروجیکٹ میں ایک `hardhat.config.js` فائل بنائے گا۔ ہم اسے بعد میں ٹیوٹوریل میں اپنے پروجیکٹ کے سیٹ اپ کی وضاحت کے لیے استعمال کریں گے۔ + +### مرحلہ 9: پروجیکٹ فولڈر شامل کریں {#step-9-add-project-folders} + +پروجیکٹ کو منظم رکھنے کے لیے، آئیے دو نئے فولڈر بنائیں۔ کمانڈ لائن میں، اپنے `hello-world` پروجیکٹ کی روٹ ڈائرکٹری میں جائیں اور ٹائپ کریں: + +``` +mkdir contracts +mkdir scripts +``` + +- `contracts/` وہ جگہ ہے جہاں ہم اپنی ہیلو ورلڈ اسمارٹ کنٹریکٹ کوڈ فائل رکھیں گے۔ +- `scripts/` وہ جگہ ہے جہاں ہم اپنے کنٹریکٹ کو ڈیپلائے کرنے اور اس کے ساتھ انٹریکٹ کرنے کے لیے اسکرپٹس رکھیں گے۔ + +### مرحلہ 10: ہمارا کنٹریکٹ لکھیں {#step-10-write-our-contract} + +آپ خود سے پوچھ رہے ہوں گے کہ ہم کوڈ کب لکھنے جا رہے ہیں؟ یہی وقت ہے! + +اپنے پسندیدہ ایڈیٹر میں ہیلو-ورلڈ پروجیکٹ کھولیں۔ اسمارٹ کنٹریکٹس زیادہ تر Solidity میں لکھے جاتے ہیں، جسے ہم اپنا اسمارٹ کنٹریکٹ لکھنے کے لیے استعمال کریں گے۔‌ + +1. `contracts` فولڈر پر جائیں اور `HelloWorld.sol` نامی ایک نئی فائل بنائیں۔ +2. ذیل میں ایک نمونہ ہیلو ورلڈ اسمارٹ کنٹریکٹ ہے جسے ہم اس ٹیوٹوریل کے لیے استعمال کریں گے۔ نیچے دیے گئے مواد کو `HelloWorld.sol` فائل میں کاپی کریں۔ + +_نوٹ: یہ سمجھنے کے لیے کہ یہ کنٹریکٹ کیا کرتا ہے، تبصرے ضرور پڑھیں۔_ + +``` +// Solidity کے ورژن کی وضاحت کرتا ہے، سیمنٹک ورژننگ کا استعمال کرتے ہوئے۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +pragma solidity >=0.7.3; + +// `HelloWorld` نامی ایک کنٹریکٹ کی وضاحت کرتا ہے۔ +// ایک کنٹریکٹ فنکشنز اور ڈیٹا (اس کی حالت) کا ایک مجموعہ ہے۔ ایک بار ڈیپلائے ہونے کے بعد، ایک کنٹریکٹ Ethereum بلاک چین پر ایک مخصوص ایڈریس پر رہتا ہے۔ مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +contract HelloWorld { + + //اپ ڈیٹ فنکشن کال ہونے پر جاری کیا جاتا ہے + //اسمارٹ کنٹریکٹ ایونٹس آپ کے کنٹریکٹ کے لیے یہ بتانے کا ایک طریقہ ہیں کہ بلاک چین پر آپ کے ایپ فرنٹ اینڈ پر کچھ ہوا ہے، جو کچھ ایونٹس کے لیے 'سن' سکتا ہے اور جب وہ ہوتے ہیں تو کارروائی کر سکتا ہے۔ + event UpdatedMessages(string oldStr, string newStr); + + // `string` قسم کے `message` نامی ایک اسٹیٹ متغیر کا اعلان کرتا ہے۔ + // اسٹیٹ متغیرات وہ متغیرات ہیں جن کی قدریں کنٹریکٹ اسٹوریج میں مستقل طور پر محفوظ ہوتی ہیں۔ کلیدی لفظ `public` متغیرات کو کنٹریکٹ کے باہر سے قابل رسائی بناتا ہے اور ایک فنکشن بناتا ہے جسے دوسرے کنٹریکٹس یا کلائنٹس قدر تک رسائی کے لیے کال کر سکتے ہیں۔ + string public message; + + // بہت سی کلاس پر مبنی آبجیکٹ اورینٹڈ زبانوں کی طرح، ایک کنسٹرکٹر ایک خاص فنکشن ہے جو صرف کنٹریکٹ کی تخلیق پر عمل میں لایا جاتا ہے۔ + // کنسٹرکٹرز کا استعمال کنٹریکٹ کے ڈیٹا کو شروع کرنے کے لیے کیا جاتا ہے۔ مزید جانیں:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + constructor(string memory initMessage) { + + // ایک اسٹرنگ آرگیومنٹ `initMessage` کو قبول کرتا ہے اور قدر کو کنٹریکٹ کے `message` اسٹوریج متغیر میں سیٹ کرتا ہے۔ + message = initMessage; + } + + // ایک عوامی فنکشن جو ایک اسٹرنگ آرگیومنٹ کو قبول کرتا ہے اور `message` اسٹوریج متغیر کو اپ ڈیٹ کرتا ہے۔ + function update(string memory newMessage) public { + string memory oldMsg = message; + message = newMessage; + emit UpdatedMessages(oldMsg, newMessage); + } +} +``` + +یہ ایک بنیادی اسمارٹ کنٹریکٹ ہے جو تخلیق کے وقت ایک پیغام محفوظ کرتا ہے۔ اسے `update` فنکشن کو کال کرکے اپ ڈیٹ کیا جاسکتا ہے۔ + +### مرحلہ 11: MetaMask اور Alchemy کو اپنے پروجیکٹ سے جوڑیں {#step-11-connect-metamask-alchemy-to-your-project} + +ہم نے ایک MetaMask والیٹ، Alchemy اکاؤنٹ بنایا ہے، اور اپنا اسمارٹ کنٹریکٹ لکھا ہے، اب ان تینوں کو جوڑنے کا وقت آگیا ہے۔ + +آپ کے والیٹ سے بھیجی گئی ہر ٹرانزیکشن کے لیے آپ کی منفرد پرائیویٹ کلید کا استعمال کرتے ہوئے ایک دستخط کی ضرورت ہوتی ہے۔ ہمارے پروگرام کو یہ اجازت دینے کے لیے، ہم اپنی پرائیویٹ کلید کو ایک انوائرمنٹ فائل میں محفوظ طریقے سے محفوظ کر سکتے ہیں۔ ہم یہاں Alchemy کے لیے ایک API کلید بھی محفوظ کریں گے۔ + +> ٹرانزیکشنز بھیجنے کے بارے میں مزید جاننے کے لیے، web3 کا استعمال کرتے ہوئے ٹرانزیکشنز بھیجنے پر [یہ ٹیوٹوریل](https://www.alchemy.com/docs/hello-world-smart-contract#step-11-connect-metamask--alchemy-to-your-project) دیکھیں۔ + +سب سے پہلے، اپنی پروجیکٹ ڈائرکٹری میں dotenv پیکیج انسٹال کریں: + +``` +npm install dotenv --save +``` + +پھر، پروجیکٹ کی روٹ ڈائرکٹری میں ایک `.env` فائل بنائیں۔ اس میں اپنی MetaMask پرائیویٹ کلید اور HTTP Alchemy API URL شامل کریں۔ + +آپ کی انوائرمنٹ فائل کا نام `.env` ہونا چاہئے ورنہ اسے انوائرمنٹ فائل کے طور پر تسلیم نہیں کیا جائے گا۔ + +اس کا نام `process.env` یا `.env-custom` یا کچھ اور نہ رکھیں۔ + +- اپنی پرائیویٹ کلید برآمد کرنے کے لیے [ان ہدایات](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) پر عمل کریں +- HTTP Alchemy API URL حاصل کرنے کے لیے نیچے دیکھیں + +![](./get-alchemy-api-key.gif) + +آپ کا `.env` اس طرح نظر آنا چاہیے: + +``` +API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" +PRIVATE_KEY = "your-metamask-private-key" +``` + +انہیں حقیقت میں ہمارے کوڈ سے جوڑنے کے لیے، ہم ان متغیرات کا حوالہ اپنی `hardhat.config.js` فائل میں مرحلہ 13 پر دیں گے۔ + +### مرحلہ 12: Ethers.js انسٹال کریں {#step-12-install-ethersjs} + +Ethers.js ایک لائبریری ہے جو زیادہ صارف دوست طریقوں کے ساتھ [معیاری JSON-RPC طریقوں](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc) کو لپیٹ کر Ethereum کے ساتھ تعامل اور درخواستیں کرنا آسان بناتی ہے۔ + +Hardhat ہمیں اضافی ٹولنگ اور توسیع شدہ فعالیت کے لیے [پلگ انز](https://hardhat.org/plugins/) کو مربوط کرنے کی اجازت دیتا ہے۔ ہم کنٹریکٹ ڈیپلائیمنٹ کے لیے [Ethers پلگ ان](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) سے فائدہ اٹھائیں گے۔ + +اپنی پروجیکٹ ڈائرکٹری میں ٹائپ کریں: + +```bash +npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0" +``` + +### مرحلہ 13: hardhat.config.js کو اپ ڈیٹ کریں {#step-13-update-hardhat-configjs} + +ہم نے اب تک کئی انحصارات اور پلگ ان شامل کیے ہیں، اب ہمیں `hardhat.config.js` کو اپ ڈیٹ کرنے کی ضرورت ہے تاکہ ہمارے پروجیکٹ کو ان سب کے بارے میں معلوم ہو۔ + +اپنی `hardhat.config.js` کو اس طرح اپ ڈیٹ کریں: + +```javascript +/** + * @type import('hardhat/config').HardhatUserConfig + */ + +require("dotenv").config() +require("@nomiclabs/hardhat-ethers") + +const { API_URL, PRIVATE_KEY } = process.env + +module.exports = { + solidity: "0.7.3", + defaultNetwork: "goerli", + networks: { + hardhat: {}, + goerli: { + url: API_URL, + accounts: [`0x${PRIVATE_KEY}`], + }, + }, +} +``` + +### مرحلہ 14: ہمارا کنٹریکٹ کمپائل کریں {#step-14-compile-our-contract} + +یہ یقینی بنانے کے لیے کہ اب تک سب کچھ کام کر رہا ہے، آئیے اپنے کنٹریکٹ کو کمپائل کریں۔ `compile` ٹاسک بلٹ ان ہارڈ ہیٹ ٹاسک میں سے ایک ہے۔ + +کمانڈ لائن سے چلائیں: + +```bash +npx hardhat compile +``` + +آپ کو `SPDX license identifier not provided in source file` کے بارے میں ایک انتباہ مل سکتا ہے، لیکن اس کے بارے میں فکر کرنے کی کوئی ضرورت نہیں ہے — امید ہے کہ باقی سب کچھ ٹھیک نظر آئے گا! اگر نہیں، تو آپ ہمیشہ [Alchemy discord](https://discord.gg/u72VCg3) میں پیغام بھیج سکتے ہیں۔ + +### مرحلہ 15: ہمارا ڈیپلائے اسکرپٹ لکھیں {#step-15-write-our-deploy-script} + +اب جب کہ ہمارا کنٹریکٹ لکھا جا چکا ہے اور ہماری کنفیگریشن فائل تیار ہے، اب وقت آگیا ہے کہ ہم اپنی کنٹریکٹ ڈیپلوئے اسکرپٹ لکھیں۔ + +`scripts/` فولڈر پر جائیں اور `deploy.js` نامی ایک نئی فائل بنائیں، اس میں درج ذیل مواد شامل کریں: + +```javascript +async function main() { + const HelloWorld = await ethers.getContractFactory("HelloWorld") + + // ڈیپلائیمنٹ شروع کریں، ایک وعدہ واپس کریں جو ایک کنٹریکٹ آبجیکٹ پر حل ہوتا ہے + const hello_world = await HelloWorld.deploy("Hello World!") + console.log("کنٹریکٹ اس ایڈریس پر ڈیپلائے کیا گیا:", hello_world.address) +} + +main() + .then(() => process.exit(0)) + .catch((error) => { + console.error(error) + process.exit(1) + }) +``` + +Hardhat اپنے [کنٹریکٹس ٹیوٹوریل](https://hardhat.org/tutorial/testing-contracts.html#writing-tests) میں بہت اچھی طرح سے وضاحت کرتا ہے کہ کوڈ کی یہ ہر لائن کیا کرتی ہے، ہم نے یہاں ان کی وضاحتیں اپنائی ہیں۔ + +```javascript +const HelloWorld = await ethers.getContractFactory("HelloWorld") +``` + +ethers.js میں ایک `ContractFactory` ایک تجرید ہے جو نئے اسمارٹ کنٹریکٹس کو ڈیپلائے کرنے کے لیے استعمال ہوتی ہے، لہذا یہاں `HelloWorld` ہمارے ہیلو ورلڈ کنٹریکٹ کی مثالوں کے لیے ایک [فیکٹری](https://en.wikipedia.org/wiki/Factory_\(object-oriented_programming\)) ہے۔ `hardhat-ethers` پلگ ان کا استعمال کرتے وقت `ContractFactory` اور `Contract`، مثالیں پہلے دستخط کنندہ (مالک) سے بطور ڈیفالٹ جڑی ہوتی ہیں۔ + +```javascript +const hello_world = await HelloWorld.deploy() +``` + +`ContractFactory` پر `deploy()` کو کال کرنے سے ڈیپلائیمنٹ شروع ہو جائے گی، اور ایک `Promise` واپس آئے گا جو ایک `Contract` آبجیکٹ پر حل ہوتا ہے۔ یہ وہ آبجیکٹ ہے جس میں ہمارے ہر اسمارٹ کنٹریکٹ فنکشن کے لیے ایک طریقہ ہے۔ + +### مرحلہ 16: ہمارا کنٹریکٹ ڈیپلائے کریں {#step-16-deploy-our-contract} + +ہم آخر کار اپنے اسمارٹ کنٹریکٹ کو ڈیپلوئے کرنے کے لیے تیار ہیں! کمانڈ لائن پر جائیں اور چلائیں: + +```bash +npx hardhat run scripts/deploy.js --network goerli +``` + +پھر آپ کو کچھ اس طرح نظر آنا چاہیے: + +```bash +کنٹریکٹ اس ایڈریس پر ڈیپلائے کیا گیا: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 +``` + +**براہ کرم یہ ایڈریس محفوظ کریں**۔ ہم اسے بعد میں ٹیوٹوریل میں استعمال کریں گے۔ + +اگر ہم [Goerli etherscan](https://goerli.etherscan.io) پر جائیں اور اپنے کنٹریکٹ ایڈریس کو تلاش کریں تو ہمیں یہ دیکھنا چاہیے کہ یہ کامیابی سے ڈیپلائے ہو گیا ہے۔ ٹرانزیکشن کچھ اس طرح نظر آئے گی: + +![](./etherscan-contract.png) + +`From` ایڈریس آپ کے MetaMask اکاؤنٹ ایڈریس سے مماثل ہونا چاہئے اور `To` ایڈریس **کنٹریکٹ کی تخلیق** کہے گا۔ اگر ہم ٹرانزیکشن پر کلک کرتے ہیں تو ہمیں `To` فیلڈ میں اپنا کنٹریکٹ ایڈریس نظر آئے گا۔ + +![](./etherscan-transaction.png) + +مبارک ہو! آپ نے ابھی ایک Ethereum ٹیسٹ نیٹ پر ایک اسمارٹ کنٹریکٹ ڈیپلائے کیا ہے۔ + +پس پردہ کیا ہو رہا ہے یہ سمجھنے کے لیے، آئیے اپنے [Alchemy ڈیش بورڈ](https://dashboard.alchemy.com/explorer) میں ایکسپلورر ٹیب پر جائیں۔ اگر آپ کے پاس متعدد Alchemy ایپس ہیں تو یقینی بنائیں کہ ایپ کے لحاظ سے فلٹر کریں اور **ہیلو ورلڈ** منتخب کریں۔ + +![](./hello-world-explorer.png) + +یہاں آپ کو کچھ JSON-RPC طریقے نظر آئیں گے جو Hardhat/Ethers نے ہمارے لیے پس پردہ بنائے تھے جب ہم نے `.deploy()` فنکشن کو کال کیا تھا۔ یہاں دو اہم طریقے ہیں [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction)، جو ہمارے کنٹریکٹ کو Goerli چین پر لکھنے کی درخواست ہے، اور [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash)، جو ہیش دیے جانے پر ہماری ٹرانزیکشن کے بارے میں معلومات پڑھنے کی درخواست ہے۔ ٹرانزیکشنز بھیجنے کے بارے میں مزید جاننے کے لیے، [Web3 کا استعمال کرتے ہوئے ٹرانزیکشنز بھیجنے پر ہمارا ٹیوٹوریل](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) دیکھیں۔ + +## حصہ 2: اپنے اسمارٹ کنٹریکٹ کے ساتھ تعامل کریں {#part-2-interact-with-your-smart-contract} + +اب جب کہ ہم نے Goerli نیٹ ورک پر ایک اسمارٹ کنٹریکٹ کامیابی سے ڈیپلائے کر لیا ہے، آئیے سیکھتے ہیں کہ اس کے ساتھ کیسے تعامل کیا جائے۔ + +### ایک interact.js فائل بنائیں {#create-a-interactjs-file} + +یہ وہ فائل ہے جہاں ہم اپنا تعامل کا اسکرپٹ لکھیں گے۔ ہم Ethers.js لائبریری استعمال کریں گے جو آپ نے پہلے حصہ 1 میں انسٹال کی تھی۔ + +`scripts/` فولڈر کے اندر، `interact.js` نامی ایک نئی فائل بنائیں اور درج ذیل کوڈ شامل کریں: + +```javascript +// interact.js + +const API_KEY = process.env.API_KEY +const PRIVATE_KEY = process.env.PRIVATE_KEY +const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS +``` + +### اپنی .env فائل کو اپ ڈیٹ کریں {#update-your-env-file} + +ہم نئے انوائرمنٹ متغیرات استعمال کریں گے، لہذا ہمیں انہیں `.env` فائل میں بیان کرنے کی ضرورت ہے جو [ہم نے پہلے بنائی تھی](#step-11-connect-metamask-&-alchemy-to-your-project)۔ + +ہمیں اپنے Alchemy `API_KEY` اور `CONTRACT_ADDRESS` کے لیے ایک تعریف شامل کرنے کی ضرورت ہوگی جہاں آپ کا اسمارٹ کنٹریکٹ ڈیپلائے کیا گیا تھا۔ + +آپ کی `.env` فائل کچھ اس طرح نظر آنی چاہیے: + +```bash +# .env + +API_URL = "https://eth-goerli.alchemyapi.io/v2/" +API_KEY = "" +PRIVATE_KEY = "" +CONTRACT_ADDRESS = "0x" +``` + +### اپنا کنٹریکٹ ABI حاصل کریں {#grab-your-contract-ABI} + +ہمارا کنٹریکٹ [ABI (ایپلیکیشن بائنری انٹرفیس)](/glossary/#abi) ہمارے اسمارٹ کنٹریکٹ کے ساتھ تعامل کرنے کا انٹرفیس ہے۔ Hardhat خود بخود ایک ABI تیار کرتا ہے اور اسے `HelloWorld.json` میں محفوظ کرتا ہے۔ ABI کا استعمال کرنے کے لیے، ہمیں اپنی `interact.js` فائل میں کوڈ کی درج ذیل لائنیں شامل کرکے مواد کو پارس کرنا ہوگا: + +```javascript +// interact.js +const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json") +``` + +اگر آپ ABI دیکھنا چاہتے ہیں تو آپ اسے اپنے کنسول پر پرنٹ کر سکتے ہیں: + +```javascript +console.log(JSON.stringify(contract.abi)) +``` + +اپنا ABI کنسول پر پرنٹ دیکھنے کے لیے، اپنے ٹرمینل پر جائیں اور چلائیں: + +```bash +npx hardhat run scripts/interact.js +``` + +### اپنے کنٹریکٹ کی ایک مثال بنائیں {#create-an-instance-of-your-contract} + +ہمارے کنٹریکٹ کے ساتھ تعامل کرنے کے لیے، ہمیں اپنے کوڈ میں کنٹریکٹ کی ایک مثال بنانے کی ضرورت ہے۔ Ethers.js کے ساتھ ایسا کرنے کے لیے، ہمیں تین تصورات کے ساتھ کام کرنے کی ضرورت ہوگی: + +1. پرووائیڈر - ایک نوڈ پرووائیڈر جو آپ کو بلاک چین تک پڑھنے اور لکھنے کی رسائی دیتا ہے +2. دستخط کنندہ - ایک Ethereum اکاؤنٹ کی نمائندگی کرتا ہے جو ٹرانزیکشنز پر دستخط کر سکتا ہے +3. کنٹریکٹ - ایک Ethers.js آبجیکٹ جو آن چین ڈیپلائے کیے گئے ایک مخصوص کنٹریکٹ کی نمائندگی کرتا ہے + +ہم کنٹریکٹ کی اپنی مثال بنانے کے لیے پچھلے مرحلے سے کنٹریکٹ ABI کا استعمال کریں گے: + +```javascript +// interact.js + +// پرووائیڈر +const alchemyProvider = new ethers.providers.AlchemyProvider( + (network = "goerli"), + API_KEY +) + +// دستخط کنندہ +const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider) + +// کنٹریکٹ +const helloWorldContract = new ethers.Contract( + CONTRACT_ADDRESS, + contract.abi, + signer +) +``` + +[ethers.js دستاویزات](https://docs.ethers.io/v5/) میں پرووائیڈرز، دستخط کنندگان، اور کنٹریکٹس کے بارے میں مزید جانیں۔ + +### ابتدائی پیغام پڑھیں {#read-the-init-message} + +یاد ہے جب ہم نے اپنا کنٹریکٹ `initMessage = "Hello world!"` کے ساتھ ڈیپلائے کیا تھا؟ اب ہم اپنے اسمارٹ کنٹریکٹ میں محفوظ اس پیغام کو پڑھنے اور اسے کنسول پر پرنٹ کرنے جا رہے ہیں۔ + +JavaScript میں، نیٹ ورکس کے ساتھ تعامل کرتے وقت غیر مطابقت پذیر فنکشنز استعمال ہوتے ہیں۔ غیر مطابقت پذیر فنکشنز کے بارے میں مزید جاننے کے لیے، [یہ میڈیم مضمون پڑھیں](https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff)۔ + +ہمارے اسمارٹ کنٹریکٹ میں `message` فنکشن کو کال کرنے اور ابتدائی پیغام پڑھنے کے لیے نیچے دیے گئے کوڈ کا استعمال کریں: + +```javascript +// interact.js + +// ... + +async function main() { + const message = await helloWorldContract.message() + console.log("پیغام یہ ہے: " + message) +} +main() +``` + +`npx hardhat run scripts/interact.js` کا استعمال کرتے ہوئے ٹرمینل میں فائل چلانے کے بعد ہمیں یہ جواب نظر آنا چاہیے: + +``` +پیغام یہ ہے: ہیلو ورلڈ! +``` + +مبارک ہو! آپ نے ابھی Ethereum بلاک چین سے اسمارٹ کنٹریکٹ کا ڈیٹا کامیابی سے پڑھ لیا ہے، شاباش! + +### پیغام کو اپ ڈیٹ کریں {#update-the-message} + +صرف پیغام پڑھنے کے بجائے، ہم `update` فنکشن کا استعمال کرتے ہوئے اپنے اسمارٹ کنٹریکٹ میں محفوظ پیغام کو بھی اپ ڈیٹ کر سکتے ہیں! بہت اچھا ہے، ہے نا؟ + +پیغام کو اپ ڈیٹ کرنے کے لیے، ہم اپنے انسٹینٹی ایٹڈ کنٹریکٹ آبجیکٹ پر براہ راست `update` فنکشن کو کال کر سکتے ہیں: + +```javascript +// interact.js + +// ... + +async function main() { + const message = await helloWorldContract.message() + console.log("پیغام یہ ہے: " + message) + + console.log("پیغام کو اپ ڈیٹ کیا جا رہا ہے...") + const tx = await helloWorldContract.update("یہ نیا پیغام ہے۔") + await tx.wait() +} +main() +``` + +نوٹ کریں کہ لائن 11 پر، ہم واپس کیے گئے ٹرانزیکشن آبجیکٹ پر `.wait()` کو کال کرتے ہیں۔ یہ یقینی بناتا ہے کہ ہمارا اسکرپٹ فنکشن سے باہر نکلنے سے پہلے بلاک چین پر ٹرانزیکشن کے مائن ہونے کا انتظار کرے۔ اگر `.wait()` کال شامل نہیں ہے، تو اسکرپٹ کنٹریکٹ میں اپ ڈیٹ شدہ `message` قدر نہیں دیکھ سکتا۔ + +### نیا پیغام پڑھیں {#read-the-new-message} + +آپ کو اپ ڈیٹ شدہ `message` قدر پڑھنے کے لیے [پچھلے مرحلے](#read-the-init-message) کو دہرانے کے قابل ہونا چاہیے۔ ایک لمحہ نکالیں اور دیکھیں کہ کیا آپ اس نئی قدر کو پرنٹ کرنے کے لیے ضروری تبدیلیاں کر سکتے ہیں! + +اگر آپ کو کوئی اشارہ چاہیے، تو یہاں یہ ہے کہ آپ کی `interact.js` فائل اس وقت کیسی نظر آنی چاہیے: + +```javascript +// interact.js + +const API_KEY = process.env.API_KEY +const PRIVATE_KEY = process.env.PRIVATE_KEY +const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS + +const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json") + +// پرووائیڈر - Alchemy +const alchemyProvider = new ethers.providers.AlchemyProvider( + (network = "goerli"), + API_KEY +) + +// دستخط کنندہ - آپ +const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider) + +// کنٹریکٹ کی مثال +const helloWorldContract = new ethers.Contract( + CONTRACT_ADDRESS, + contract.abi, + signer +) + +async function main() { + const message = await helloWorldContract.message() + console.log("پیغام یہ ہے: " + message) + + console.log("پیغام کو اپ ڈیٹ کیا جا رہا ہے...") + const tx = await helloWorldContract.update("یہ نیا پیغام ہے") + await tx.wait() + + const newMessage = await helloWorldContract.message() + console.log("نیا پیغام یہ ہے: " + newMessage) +} + +main() +``` + +اب صرف اسکرپٹ چلائیں اور آپ کو پرانا پیغام، اپ ڈیٹ کی حیثیت، اور نیا پیغام اپنے ٹرمینل پر پرنٹ ہوتا نظر آنا چاہیے! + +`npx hardhat run scripts/interact.js --network goerli` + +``` +پیغام یہ ہے: ہیلو ورلڈ! +پیغام کو اپ ڈیٹ کیا جا رہا ہے... +نیا پیغام یہ ہے: یہ نیا پیغام ہے۔ +``` + +اس اسکرپٹ کو چلاتے وقت، آپ کو معلوم ہو سکتا ہے کہ نیا پیغام لوڈ ہونے سے پہلے `Updating the message...` مرحلے میں کچھ وقت لگتا ہے۔ یہ مائننگ کے عمل کی وجہ سے ہے؛ اگر آپ ٹرانزیکشنز کو مائن ہونے کے دوران ٹریک کرنے میں دلچسپی رکھتے ہیں، تو ٹرانزیکشن کی حیثیت دیکھنے کے لیے [Alchemy میم پول](https://dashboard.alchemyapi.io/mempool) پر جائیں۔ اگر ٹرانزیکشن ڈراپ ہو جاتی ہے، تو [Goerli Etherscan](https://goerli.etherscan.io) کو چیک کرنا اور اپنی ٹرانزیکشن ہیش کو تلاش کرنا بھی مددگار ہے۔ + +## حصہ 3: اپنے اسمارٹ کنٹریکٹ کو Etherscan پر شائع کریں {#part-3-publish-your-smart-contract-to-etherscan} + +آپ نے اپنے اسمارٹ کنٹریکٹ کو زندہ کرنے کی تمام محنت کی؛ اب اسے دنیا کے ساتھ شیئر کرنے کا وقت ہے! + +Etherscan پر اپنے اسمارٹ کنٹریکٹ کی تصدیق کرکے، کوئی بھی آپ کا سورس کوڈ دیکھ سکتا ہے اور آپ کے اسمارٹ کنٹریکٹ کے ساتھ تعامل کر سکتا ہے۔ آئیے شروع کرتے ہیں! + +### مرحلہ 1: اپنے Etherscan اکاؤنٹ پر ایک API کلید تیار کریں {#step-1-generate-an-api-key-on-your-etherscan-account} + +Etherscan API کلید اس بات کی تصدیق کے لیے ضروری ہے کہ آپ اس اسمارٹ کنٹریکٹ کے مالک ہیں جسے آپ شائع کرنے کی کوشش کر رہے ہیں۔ + +اگر آپ کے پاس پہلے سے Etherscan اکاؤنٹ نہیں ہے، تو [ایک اکاؤنٹ کے لیے سائن اپ کریں](https://etherscan.io/register)۔ + +لاگ ان ہونے کے بعد، نیویگیشن بار میں اپنا صارف نام تلاش کریں، اس پر ہوور کریں اور **میری پروفائل** بٹن منتخب کریں۔ + +آپ کے پروفائل صفحہ پر، آپ کو ایک سائیڈ نیویگیشن بار نظر آنا چاہیے۔ سائیڈ نیویگیشن بار سے، **API کیز** منتخب کریں۔ اگلا، ایک نئی API کلید بنانے کے لیے "شامل کریں" بٹن دبائیں، اپنی ایپ کا نام **hello-world** رکھیں اور **نئی API کلید بنائیں** بٹن دبائیں۔ + +آپ کی نئی API کلید API کلید کی میز میں ظاہر ہونی چاہیے۔ API کلید کو اپنے کلپ بورڈ پر کاپی کریں۔ + +اگلا، ہمیں Etherscan API کلید کو اپنی `.env` فائل میں شامل کرنے کی ضرورت ہے۔ + +اسے شامل کرنے کے بعد، آپ کی `.env` فائل اس طرح نظر آنی چاہیے: + +```javascript +API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" +PUBLIC_KEY = "your-public-account-address" +PRIVATE_KEY = "your-private-account-address" +CONTRACT_ADDRESS = "your-contract-address" +ETHERSCAN_API_KEY = "your-etherscan-key" +``` + +### Hardhat کے ذریعے ڈیپلائے کیے گئے اسمارٹ کنٹریکٹس {#hardhat-deployed-smart-contracts} + +#### hardhat-etherscan انسٹال کریں {#install-hardhat-etherscan} + +Hardhat کا استعمال کرتے ہوئے اپنے کنٹریکٹ کو Etherscan پر شائع کرنا سیدھا سادہ ہے۔ شروع کرنے کے لیے آپ کو پہلے `hardhat-etherscan` پلگ ان انسٹال کرنے کی ضرورت ہوگی۔ `hardhat-etherscan` خود بخود اسمارٹ کنٹریکٹ کے سورس کوڈ اور ABI کی Etherscan پر تصدیق کرے گا۔ اسے شامل کرنے کے لیے، `hello-world` ڈائرکٹری میں چلائیں: + +```text +npm install --save-dev @nomiclabs/hardhat-etherscan +``` + +انسٹال ہونے کے بعد، اپنی `hardhat.config.js` کے اوپری حصے میں درج ذیل بیان شامل کریں، اور Etherscan کنفیگریشن کے اختیارات شامل کریں: + +```javascript +// hardhat.config.js + +require("dotenv").config() +require("@nomiclabs/hardhat-ethers") +require("@nomiclabs/hardhat-etherscan") + +const { API_URL, PRIVATE_KEY, ETHERSCAN_API_KEY } = process.env + +module.exports = { + solidity: "0.7.3", + defaultNetwork: "goerli", + networks: { + hardhat: {}, + goerli: { + url: API_URL, + accounts: [`0x${PRIVATE_KEY}`], + }, + }, + etherscan: { + // Etherscan کے لیے آپ کی API کلید + // https://etherscan.io/ پر ایک حاصل کریں + apiKey: ETHERSCAN_API_KEY, + }, +} +``` + +#### Etherscan پر اپنے اسمارٹ کنٹریکٹ کی تصدیق کریں {#verify-your-smart-contract-on-etherscan} + +یقینی بنائیں کہ تمام فائلیں محفوظ ہیں اور تمام `.env` متغیرات صحیح طریقے سے کنفیگر کیے گئے ہیں۔ + +`verify` ٹاسک چلائیں، کنٹریکٹ ایڈریس، اور جس نیٹ ورک پر یہ ڈیپلائے کیا گیا ہے اسے پاس کریں: + +```text +npx hardhat verify --network goerli DEPLOYED_CONTRACT_ADDRESS 'Hello World!' +``` + +یقینی بنائیں کہ `DEPLOYED_CONTRACT_ADDRESS` Goerli ٹیسٹ نیٹ ورک پر آپ کے ڈیپلائے کیے گئے اسمارٹ کنٹریکٹ کا ایڈریس ہے۔ اس کے علاوہ، آخری آرگیومنٹ (`'Hello World!'`) وہی اسٹرنگ قدر ہونی چاہیے جو [حصہ 1 میں ڈیپلائے مرحلے کے دوران](#write-our-deploy-script) استعمال کی گئی تھی۔ + +اگر سب کچھ ٹھیک رہا، تو آپ کو اپنے ٹرمینل میں درج ذیل پیغام نظر آئے گا: + +```text +کنٹریکٹ کے لیے سورس کوڈ کامیابی سے جمع کر دیا گیا +contracts/HelloWorld.sol:HelloWorld at 0xdeployed-contract-address +Etherscan پر تصدیق کے لیے۔ تصدیق کے نتیجے کا انتظار ہے... + + +Etherscan پر HelloWorld کنٹریکٹ کامیابی سے تصدیق شدہ ہے۔ +https://goerli.etherscan.io/address/#contracts +``` + +مبارک ہو! آپ کا اسمارٹ کنٹریکٹ کوڈ Etherscan پر ہے! + +### Etherscan پر اپنا اسمارٹ کنٹریکٹ دیکھیں! {#check-out-your-smart-contract-on-etherscan} + +جب آپ اپنے ٹرمینل میں فراہم کردہ لنک پر جاتے ہیں، تو آپ کو Etherscan پر اپنا اسمارٹ کنٹریکٹ کوڈ اور ABI شائع ہوتا نظر آنا چاہیے! + +**واہو - آپ نے کر دکھایا چیمپئن! اب کوئی بھی آپ کے اسمارٹ کنٹریکٹ کو کال یا اس پر لکھ سکتا ہے! ہم یہ دیکھنے کے لیے انتظار نہیں کر سکتے کہ آپ اگلا کیا بناتے ہیں!** + +## حصہ 4 - اپنے اسمارٹ کنٹریکٹ کو فرنٹ اینڈ کے ساتھ مربوط کرنا {#part-4-integrating-your-smart-contract-with-the-frontend} + +اس ٹیوٹوریل کے آخر تک، آپ جان جائیں گے کہ کیسے: + +- MetaMask والیٹ کو اپنے dapp سے جوڑیں +- [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) API کا استعمال کرتے ہوئے اپنے اسمارٹ کنٹریکٹ سے ڈیٹا پڑھیں +- MetaMask کا استعمال کرتے ہوئے Ethereum ٹرانزیکشنز پر دستخط کریں + +اس dapp کے لیے، ہم اپنے فرنٹ اینڈ فریم ورک کے طور پر [React](https://react.dev/) کا استعمال کریں گے؛ تاہم، یہ نوٹ کرنا ضروری ہے کہ ہم اس کی بنیادی باتوں کو توڑنے میں زیادہ وقت نہیں گزاریں گے، کیونکہ ہم زیادہ تر اپنے پروجیکٹ میں Web3 کی فعالیت لانے پر توجہ دیں گے۔ + +پیشگی شرط کے طور پر، آپ کو React کی مبتدی سطح کی سمجھ ہونی چاہیے۔ اگر نہیں، تو ہم سرکاری [React کا تعارف ٹیوٹوریل](https://react.dev/learn) مکمل کرنے کی سفارش کرتے ہیں۔ + +### اسٹارٹر فائلیں کلون کریں {#clone-the-starter-files} + +سب سے پہلے، اس پروجیکٹ کے لیے اسٹارٹر فائلیں حاصل کرنے کے لیے [hello-world-part-four GitHub repository](https://github.com/alchemyplatform/hello-world-part-four-tutorial) پر جائیں اور اس ریپوزٹری کو اپنی مقامی مشین پر کلون کریں۔ + +کلون کی گئی ریپوزٹری کو مقامی طور پر کھولیں۔ نوٹ کریں کہ اس میں دو فولڈرز ہیں: `starter-files` اور `completed`۔ + +- `starter-files`- **ہم اس ڈائرکٹری میں کام کریں گے**، ہم UI کو آپ کے Ethereum والیٹ اور اسمارٹ کنٹریکٹ سے جوڑیں گے جسے ہم نے [حصہ 3](#part-3) میں Etherscan پر شائع کیا تھا۔ +- `completed` میں مکمل ٹیوٹوریل شامل ہے اور اسے صرف ایک حوالہ کے طور پر استعمال کیا جانا چاہئے اگر آپ پھنس جائیں۔ + +اگلا، اپنی `starter-files` کی کاپی کو اپنے پسندیدہ کوڈ ایڈیٹر میں کھولیں، اور پھر `src` فولڈر میں جائیں۔ + +ہمارا لکھا ہوا سارا کوڈ `src` فولڈر کے تحت رہے گا۔ ہم اپنے پروجیکٹ کو Web3 کی فعالیت دینے کے لیے `HelloWorld.js` جزو اور `util/interact.js` JavaScript فائلوں میں ترمیم کریں گے۔ + +### اسٹارٹر فائلیں چیک کریں {#check-out-the-starter-files} + +کوڈنگ شروع کرنے سے پہلے، آئیے دریافت کریں کہ اسٹارٹر فائلوں میں ہمیں کیا فراہم کیا گیا ہے۔ + +#### اپنا react پروجیکٹ چلائیں {#get-your-react-project-running} + +آئیے اپنے براؤزر میں React پروجیکٹ چلا کر شروع کریں۔ React کی خوبصورتی یہ ہے کہ ایک بار جب ہمارا پروجیکٹ ہمارے براؤزر میں چل رہا ہو، تو ہمارے ذریعے محفوظ کی گئی کوئی بھی تبدیلی ہمارے براؤزر میں لائیو اپ ڈیٹ ہو جائے گی۔ + +پروجیکٹ کو چلانے کے لیے، `starter-files` فولڈر کی روٹ ڈائرکٹری پر جائیں، اور پروجیکٹ کی انحصار کو انسٹال کرنے کے لیے اپنے ٹرمینل میں `npm install` چلائیں: + +```bash +cd starter-files +npm install +``` + +ان کے انسٹال ہونے کے بعد، اپنے ٹرمینل میں `npm start` چلائیں: + +```bash +npm start +``` + +ایسا کرنے سے آپ کے براؤزر میں [http://localhost:3000/](http://localhost:3000/) کھل جانا چاہیے، جہاں آپ کو ہمارے پروجیکٹ کا فرنٹ اینڈ نظر آئے گا۔ اس میں ایک فیلڈ (آپ کے اسمارٹ کنٹریکٹ میں محفوظ پیغام کو اپ ڈیٹ کرنے کی جگہ)، ایک "والیٹ جوڑیں" بٹن، اور ایک "اپ ڈیٹ" بٹن ہونا چاہیے۔ + +اگر آپ کسی بھی بٹن پر کلک کرنے کی کوشش کرتے ہیں، تو آپ دیکھیں گے کہ وہ کام نہیں کرتے ہیں - اس کی وجہ یہ ہے کہ ہمیں ابھی بھی ان کی فعالیت کو پروگرام کرنے کی ضرورت ہے۔ + +#### `HelloWorld.js` جزو {#the-helloworld-js-component} + +آئیے اپنے ایڈیٹر میں `src` فولڈر میں واپس جائیں اور `HelloWorld.js` فائل کھولیں۔ یہ بہت ضروری ہے کہ ہم اس فائل میں ہر چیز کو سمجھیں، کیونکہ یہ بنیادی React کمپونینٹ ہے جس پر ہم کام کریں گے۔ + +اس فائل کے اوپری حصے میں، آپ دیکھیں گے کہ ہمارے پاس کئی درآمدی بیانات ہیں جو ہمارے پروجیکٹ کو چلانے کے لیے ضروری ہیں، بشمول React لائبریری، useEffect اور useState ہکس، `./util/interact.js` سے کچھ آئٹمز (ہم ان کی مزید تفصیلات جلد بیان کریں گے!)، اور Alchemy لوگو۔ + +```javascript +// HelloWorld.js + +import React from "react" +import { useEffect, useState } from "react" +import { + helloWorldContract, + connectWallet, + updateMessage, + loadCurrentMessage, + getCurrentWalletConnected, +} from "./util/interact.js" + +import alchemylogo from "./alchemylogo.svg" +``` + +اگلا، ہمارے پاس ہمارے ریاستی متغیرات ہیں جنہیں ہم مخصوص واقعات کے بعد اپ ڈیٹ کریں گے۔ + +```javascript +// HelloWorld.js + +//ریاستی متغیرات +const [walletAddress, setWallet] = useState("") +const [status, setStatus] = useState("") +const [message, setMessage] = useState("نیٹ ورک سے کوئی کنکشن نہیں ہے۔") +const [newMessage, setNewMessage] = useState("") +``` + +یہاں ہر متغیر کی نمائندگی کرتا ہے: + +- `walletAddress` - ایک اسٹرنگ جو صارف کے والیٹ کا پتہ محفوظ کرتا ہے +- `status`- ایک اسٹرنگ جو ایک مددگار پیغام محفوظ کرتا ہے جو صارف کو dapp کے ساتھ تعامل کرنے کے طریقے کے بارے میں رہنمائی کرتا ہے +- `message` - ایک اسٹرنگ جو اسمارٹ کنٹریکٹ میں موجودہ پیغام کو محفوظ کرتا ہے +- `newMessage` - ایک اسٹرنگ جو نیا پیغام محفوظ کرتا ہے جو اسمارٹ کنٹریکٹ میں لکھا جائے گا + +ریاستی متغیرات کے بعد، آپ کو پانچ غیر نافذ شدہ افعال نظر آئیں گے: `useEffect` ,`addSmartContractListener`, `addWalletListener` , `connectWalletPressed`, اور `onUpdatePressed`۔ ہم ذیل میں وضاحت کریں گے کہ وہ کیا کرتے ہیں: + +```javascript +// HelloWorld.js + +//صرف ایک بار کال کیا گیا +useEffect(async () => { + //TODO: نافذ کریں +}, []) + +function addSmartContractListener() { + //TODO: نافذ کریں +} + +function addWalletListener() { + //TODO: نافذ کریں +} + +const connectWalletPressed = async () => { + //TODO: نافذ کریں +} + +const onUpdatePressed = async () => { + //TODO: نافذ کریں +} +``` + +- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html)- یہ ایک React ہک ہے جسے آپ کے جزو کے رینڈر ہونے کے بعد کال کیا جاتا ہے۔ کیونکہ اس میں ایک خالی سرنی `[]` پراپ پاس کی گئی ہے (لائن 4 دیکھیں)، اسے صرف جزو کے _پہلے_ رینڈر پر کال کیا جائے گا۔ یہاں ہم اپنے اسمارٹ کنٹریکٹ میں محفوظ موجودہ پیغام کو لوڈ کریں گے، اپنے اسمارٹ کنٹریکٹ اور والیٹ سننے والوں کو کال کریں گے، اور اپنے UI کو اپ ڈیٹ کریں گے تاکہ یہ ظاہر ہو کہ آیا والیٹ پہلے سے جڑا ہوا ہے۔ +- `addSmartContractListener`- یہ فنکشن ایک سننے والا سیٹ اپ کرتا ہے جو ہمارے HelloWorld کنٹریکٹ کے `UpdatedMessages` ایونٹ کو دیکھے گا اور جب ہمارے اسمارٹ کنٹریکٹ میں پیغام تبدیل ہو جائے گا تو ہمارے UI کو اپ ڈیٹ کرے گا۔ +- `addWalletListener`- یہ فنکشن ایک سننے والا سیٹ اپ کرتا ہے جو صارف کے MetaMask والیٹ کی حالت میں تبدیلیوں کا پتہ لگاتا ہے، جیسے کہ جب صارف اپنا والیٹ منقطع کرتا ہے یا پتے تبدیل کرتا ہے۔ +- `connectWalletPressed`- اس فنکشن کو صارف کے MetaMask والیٹ کو ہمارے dapp سے جوڑنے کے لیے کال کیا جائے گا۔ +- `onUpdatePressed` - اس فنکشن کو اس وقت کال کیا جائے گا جب صارف اسمارٹ کنٹریکٹ میں محفوظ پیغام کو اپ ڈیٹ کرنا چاہے گا۔ + +اس فائل کے آخر کے قریب، ہمارے پاس ہمارے کمپونینٹ کا UI ہے۔ + +```javascript +// HelloWorld.js + +//ہمارے جزو کا UI +return ( +
+ + + +

موجودہ پیغام:

+

{message}

+ +

نیا پیغام:

+ +
+ setNewMessage(e.target.value)} + value={newMessage} + /> +

{status}

+ + +
+ +
+) +``` + +اگر آپ اس کوڈ کو احتیاط سے اسکین کرتے ہیں، تو آپ دیکھیں گے کہ ہم اپنے UI میں اپنے مختلف ریاستی متغیرات کہاں استعمال کرتے ہیں: + +- لائن 6-12 پر، اگر صارف کا والیٹ جڑا ہوا ہے (یعنی، `walletAddress.length > 0`)، تو ہم ID "walletButton" والے بٹن میں صارف کے `walletAddress` کا ایک چھوٹا ورژن دکھاتے ہیں؛ ورنہ یہ صرف "والیٹ جوڑیں" کہتا ہے۔ +- لائن 17 پر، ہم اسمارٹ کنٹریکٹ میں محفوظ موجودہ پیغام دکھاتے ہیں، جو `message` اسٹرنگ میں پکڑا گیا ہے۔ +- لائن 23-26 پر، ہم اپنے `newMessage` ریاستی متغیر کو اپ ڈیٹ کرنے کے لیے ایک [کنٹرولڈ جزو](https://legacy.reactjs.org/docs/forms.html#controlled-components) استعمال کرتے ہیں جب ٹیکسٹ فیلڈ میں ان پٹ تبدیل ہوتا ہے۔ + +ہمارے ریاستی متغیرات کے علاوہ، آپ یہ بھی دیکھیں گے کہ `connectWalletPressed` اور `onUpdatePressed` افعال کو اس وقت کال کیا جاتا ہے جب IDs `publishButton` اور `walletButton` والے بٹنوں پر بالترتیب کلک کیا جاتا ہے۔ + +آخر میں، آئیے اس بات پر توجہ دیں کہ یہ `HelloWorld.js` جزو کہاں شامل کیا گیا ہے۔ + +اگر آپ `App.js` فائل پر جاتے ہیں، جو React میں مرکزی جزو ہے جو دیگر تمام اجزاء کے لیے کنٹینر کے طور پر کام کرتا ہے، تو آپ دیکھیں گے کہ ہمارا `HelloWorld.js` جزو لائن 7 پر داخل کیا گیا ہے۔ + +آخری لیکن کم از کم، آئیے ایک اور فائل چیک کریں جو آپ کے لیے فراہم کی گئی ہے، `interact.js` فائل۔ + +#### `interact.js` فائل {#the-interact-js-file} + +چونکہ ہم [M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) پیراڈائم کی پیروی کرنا چاہتے ہیں، ہم ایک الگ فائل چاہیں گے جس میں ہمارے dapp کی منطق، ڈیٹا، اور قوانین کا انتظام کرنے کے لیے ہمارے تمام افعال شامل ہوں، اور پھر ان افعال کو ہمارے فرنٹ اینڈ (ہمارا `HelloWorld.js` جزو) میں برآمد کرنے کے قابل ہوں۔ + +👆🏽یہ ہماری `interact.js` فائل کا عین مقصد ہے! + +اپنی `src` ڈائرکٹری میں `util` فولڈر پر جائیں، اور آپ دیکھیں گے کہ ہم نے `interact.js` نامی ایک فائل شامل کی ہے جس میں ہمارے تمام اسمارٹ کنٹریکٹ تعامل اور والیٹ افعال اور متغیرات شامل ہوں گے۔ + +```javascript +// interact.js + +//export const helloWorldContract; + +export const loadCurrentMessage = async () => {} + +export const connectWallet = async () => {} + +const getCurrentWalletConnected = async () => {} + +export const updateMessage = async (message) => {} +``` + +آپ دیکھیں گے کہ فائل کے اوپری حصے میں، ہم نے `helloWorldContract` آبجیکٹ پر تبصرہ کیا ہے۔ بعد میں اس ٹیوٹوریل میں، ہم اس آبجیکٹ کو غیر تبصرہ کریں گے اور اس متغیر میں اپنے اسمارٹ کنٹریکٹ کو انسٹینٹی ایٹ کریں گے، جسے ہم پھر اپنے `HelloWorld.js` جزو میں برآمد کریں گے۔ + +ہمارے `helloWorldContract` آبجیکٹ کے بعد چار غیر نافذ شدہ افعال درج ذیل کام کرتے ہیں: + +- `loadCurrentMessage` - یہ فنکشن اسمارٹ کنٹریکٹ میں محفوظ موجودہ پیغام کو لوڈ کرنے کی منطق کو سنبھالتا ہے۔ یہ [Alchemy Web3 API](https://github.com/alchemyplatform/alchemy-web3) کا استعمال کرتے ہوئے ہیلو ورلڈ اسمارٹ کنٹریکٹ پر ایک _ریڈ_ کال کرے گا۔ +- `connectWallet` - یہ فنکشن صارف کے MetaMask کو ہمارے dapp سے جوڑے گا۔ +- `getCurrentWalletConnected` - یہ فنکشن چیک کرے گا کہ آیا کوئی Ethereum اکاؤنٹ پہلے سے ہی صفحہ لوڈ پر ہمارے dapp سے جڑا ہوا ہے اور ہمارے UI کو اسی کے مطابق اپ ڈیٹ کرے گا۔ +- `updateMessage` - یہ فنکشن اسمارٹ کنٹریکٹ میں محفوظ پیغام کو اپ ڈیٹ کرے گا۔ یہ ہیلو ورلڈ اسمارٹ کنٹریکٹ پر ایک _رائٹ_ کال کرے گا، لہذا صارف کے MetaMask والیٹ کو پیغام کو اپ ڈیٹ کرنے کے لیے ایک Ethereum ٹرانزیکشن پر دستخط کرنا ہوگا۔ + +اب جب کہ ہم سمجھ گئے ہیں کہ ہم کس کے ساتھ کام کر رہے ہیں، آئیے یہ معلوم کریں کہ اپنے اسمارٹ کنٹریکٹ سے کیسے پڑھا جائے! + +### مرحلہ 3: اپنے اسمارٹ کنٹریکٹ سے پڑھیں {#step-3-read-from-your-smart-contract} + +اپنے اسمارٹ کنٹریکٹ سے پڑھنے کے لیے، آپ کو کامیابی سے سیٹ اپ کرنے کی ضرورت ہوگی: + +- Ethereum چین سے ایک API کنکشن +- آپ کے اسمارٹ کنٹریکٹ کی ایک لوڈ شدہ مثال +- آپ کے اسمارٹ کنٹریکٹ فنکشن کو کال کرنے کے لیے ایک فنکشن +- ایک سننے والا جو اپ ڈیٹس کے لیے دیکھتا ہے جب آپ اسمارٹ کنٹریکٹ سے پڑھ رہے ڈیٹا میں تبدیلی آتی ہے + +یہ بہت سارے مراحل لگ سکتے ہیں، لیکن فکر نہ کریں! ہم آپ کو ہر ایک کو قدم بہ قدم کرنے کا طریقہ بتائیں گے! :\) + +#### Ethereum چین سے ایک API کنکشن قائم کریں {#establish-an-api-connection-to-the-ethereum-chain} + +تو یاد ہے کہ اس ٹیوٹوریل کے حصہ 2 میں، ہم نے اپنے اسمارٹ کنٹریکٹ سے پڑھنے کے لیے اپنی [Alchemy Web3 کلید کا استعمال کیا تھا](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)؟ آپ کو اپنے dapp میں چین سے پڑھنے کے لیے بھی ایک Alchemy Web3 کلید کی ضرورت ہوگی۔ + +اگر آپ کے پاس یہ پہلے سے نہیں ہے، تو پہلے [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) انسٹال کریں، اپنی `starter-files` کی روٹ ڈائرکٹری پر جائیں اور اپنے ٹرمینل میں درج ذیل کو چلائیں: + +```text +npm install @alch/alchemy-web3 +``` + +[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) [Web3.js](https://docs.web3js.org/) کے ارد گرد ایک ریپر ہے، جو بہتر API طریقے اور دیگر اہم فوائد فراہم کرتا ہے تاکہ آپ کی زندگی کو ایک web3 ڈیولپر کے طور پر آسان بنایا جا سکے۔ یہ کم سے کم کنفیگریشن کی ضرورت کے لیے ڈیزائن کیا گیا ہے تاکہ آپ اسے اپنی ایپ میں فوراً استعمال کرنا شروع کر سکیں! + +پھر، اپنے پروجیکٹ ڈائرکٹری میں [dotenv](https://www.npmjs.com/package/dotenv) پیکیج انسٹال کریں، تاکہ ہمارے پاس اپنی API کلید کو حاصل کرنے کے بعد اسے محفوظ کرنے کے لیے ایک محفوظ جگہ ہو۔ + +```text +npm install dotenv --save +``` + +ہمارے dapp کے لیے، **ہم اپنی HTTP API کلید کے بجائے اپنی Websockets API کلید کا استعمال کریں گے**، کیونکہ یہ ہمیں ایک سننے والا سیٹ اپ کرنے کی اجازت دے گا جو اس وقت پتہ لگاتا ہے جب اسمارٹ کنٹریکٹ میں محفوظ پیغام تبدیل ہوتا ہے۔ + +ایک بار جب آپ کے پاس اپنی API کلید ہو، تو اپنی روٹ ڈائرکٹری میں ایک `.env` فائل بنائیں اور اس میں اپنا Alchemy Websockets url شامل کریں۔ اس کے بعد، آپ کی `.env` فائل اس طرح نظر آنی چاہیے: + +```javascript +REACT_APP_ALCHEMY_KEY = wss://eth-goerli.ws.alchemyapi.io/v2/ +``` + +اب، ہم اپنے dapp میں اپنا Alchemy Web3 اینڈ پوائنٹ سیٹ اپ کرنے کے لیے تیار ہیں! آئیے اپنی `interact.js` پر واپس جائیں، جو ہمارے `util` فولڈر کے اندر نیسٹڈ ہے اور فائل کے اوپری حصے میں درج ذیل کوڈ شامل کریں: + +```javascript +// interact.js + +require("dotenv").config() +const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(alchemyKey) + +//export const helloWorldContract; +``` + +اوپر، ہم نے پہلے اپنی `.env` فائل سے Alchemy کلید درآمد کی اور پھر اپنا Alchemy Web3 اینڈ پوائنٹ قائم کرنے کے لیے اپنی `alchemyKey` کو `createAlchemyWeb3` میں پاس کیا۔ + +اس اینڈ پوائنٹ کے تیار ہونے کے ساتھ، اب وقت آگیا ہے کہ ہم اپنا اسمارٹ کنٹریکٹ لوڈ کریں! + +#### اپنا ہیلو ورلڈ اسمارٹ کنٹریکٹ لوڈ کرنا {#loading-your-hello-world-smart-contract} + +اپنے ہیلو ورلڈ اسمارٹ کنٹریکٹ کو لوڈ کرنے کے لیے، آپ کو اس کا کنٹریکٹ ایڈریس اور ABI کی ضرورت ہوگی، جو دونوں Etherscan پر مل سکتے ہیں اگر آپ نے [اس ٹیوٹوریل کا حصہ 3](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan) مکمل کیا ہو۔ + +#### Etherscan سے اپنا کنٹریکٹ ABI کیسے حاصل کریں {#how-to-get-your-contract-abi-from-etherscan} + +اگر آپ نے اس ٹیوٹوریل کا حصہ 3 چھوڑ دیا ہے، تو آپ HelloWorld کنٹریکٹ کا استعمال کر سکتے ہیں جس کا ایڈریس [0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code) ہے۔ اس کا ABI [یہاں](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code) پایا جا سکتا ہے۔ + +ایک کنٹریکٹ ABI اس بات کی وضاحت کے لیے ضروری ہے کہ کنٹریکٹ کس فنکشن کو کال کرے گا اور یہ بھی یقینی بناتا ہے کہ فنکشن آپ کی توقع کے مطابق فارمیٹ میں ڈیٹا واپس کرے گا۔ ایک بار جب ہم اپنا کنٹریکٹ ABI کاپی کر لیں، تو آئیے اسے اپنی `src` ڈائرکٹری میں `contract-abi.json` نامی JSON فائل کے طور پر محفوظ کریں۔ + +آپ کی contract-abi.json فائل آپ کی src فولڈر میں محفوظ ہونی چاہیے۔ + +ہمارے کنٹریکٹ ایڈریس، ABI، اور Alchemy Web3 اینڈ پوائنٹ سے لیس، ہم اپنے اسمارٹ کنٹریکٹ کی ایک مثال لوڈ کرنے کے لیے [کنٹریکٹ میتھڈ](https://docs.web3js.org/api/web3-eth-contract/class/Contract) کا استعمال کر سکتے ہیں۔ `interact.js` فائل میں اپنا کنٹریکٹ ABI درآمد کریں اور اپنا کنٹریکٹ ایڈریس شامل کریں۔ + +```javascript +// interact.js + +const contractABI = require("../contract-abi.json") +const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A" +``` + +اب ہم آخر کار اپنے `helloWorldContract` متغیر کو غیر تبصرہ کر سکتے ہیں، اور اپنے AlchemyWeb3 اینڈ پوائنٹ کا استعمال کرتے ہوئے اسمارٹ کنٹریکٹ کو لوڈ کر سکتے ہیں: + +```javascript +// interact.js +export const helloWorldContract = new web3.eth.Contract( + contractABI, + contractAddress +) +``` + +خلاصہ کرنے کے لیے، آپ کی `interact.js` کی پہلی 12 لائنیں اب اس طرح نظر آنی چاہئیں: + +```javascript +// interact.js + +require("dotenv").config() +const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(alchemyKey) + +const contractABI = require("../contract-abi.json") +const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A" + +export const helloWorldContract = new web3.eth.Contract( + contractABI, + contractAddress +) +``` + +اب جب کہ ہمارا کنٹریکٹ لوڈ ہو گیا ہے، ہم اپنا `loadCurrentMessage` فنکشن نافذ کر سکتے ہیں! + +#### اپنی `interact.js` فائل میں `loadCurrentMessage` کو نافذ کرنا {#implementing-loadCurrentMessage-in-your-interact-js-file} + +یہ فنکشن بہت سادہ ہے۔ ہم اپنے کنٹریکٹ سے پڑھنے کے لیے ایک سادہ غیر مطابقت پذیر web3 کال کریں گے۔ ہمارا فنکشن اسمارٹ کنٹریکٹ میں محفوظ پیغام کو واپس کرے گا: + +اپنی `interact.js` فائل میں `loadCurrentMessage` کو درج ذیل میں اپ ڈیٹ کریں: + +```javascript +// interact.js + +export const loadCurrentMessage = async () => { + const message = await helloWorldContract.methods.message().call() + return message +} +``` + +چونکہ ہم اس اسمارٹ کنٹریکٹ کو اپنے UI میں دکھانا چاہتے ہیں، آئیے اپنے `HelloWorld.js` جزو میں `useEffect` فنکشن کو درج ذیل میں اپ ڈیٹ کریں: + +```javascript +// HelloWorld.js + +//صرف ایک بار کال کیا گیا +useEffect(async () => { + const message = await loadCurrentMessage() + setMessage(message) +}, []) +``` + +نوٹ کریں، ہم صرف یہ چاہتے ہیں کہ ہمارا `loadCurrentMessage` جزو کے پہلے رینڈر کے دوران ایک بار کال کیا جائے۔ ہم جلد ہی `addSmartContractListener` نافذ کریں گے تاکہ اسمارٹ کنٹریکٹ میں پیغام تبدیل ہونے کے بعد UI خود بخود اپ ڈیٹ ہو جائے۔ + +اس سے پہلے کہ ہم اپنے سننے والے میں غوطہ لگائیں، آئیے دیکھتے ہیں کہ ہمارے پاس اب تک کیا ہے۔ اپنی `HelloWorld.js` اور `interact.js` فائلیں محفوظ کریں، اور پھر [http://localhost:3000/](http://localhost:3000/) پر جائیں۔ + +آپ دیکھیں گے کہ موجودہ پیغام اب "نیٹ ورک سے کوئی کنکشن نہیں ہے" نہیں کہتا۔ اس کے بجائے یہ اسمارٹ کنٹریکٹ میں محفوظ پیغام کی عکاسی کرتا ہے۔ زبردست! + +#### آپ کا UI اب اسمارٹ کنٹریکٹ میں محفوظ پیغام کی عکاسی کرنا چاہئے {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract} + +اب اس سننے والے کی بات کرتے ہیں... + +#### `addSmartContractListener` نافذ کریں {#implement-addsmartcontractlistener} + +اگر آپ اس ٹیوٹوریل سیریز کے [حصہ 1](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract) میں لکھی گئی `HelloWorld.sol` فائل کو یاد کریں، تو آپ کو یاد ہوگا کہ `UpdatedMessages` نامی ایک اسمارٹ کنٹریکٹ ایونٹ ہے جو ہمارے اسمارٹ کنٹریکٹ کے `update` فنکشن کو کال کرنے کے بعد خارج ہوتا ہے (لائن 9 اور 27 دیکھیں): + +```javascript +// HelloWorld.sol + +// Solidity کے ورژن کی وضاحت کرتا ہے، سیمنٹک ورژننگ کا استعمال کرتے ہوئے۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +pragma solidity ^0.7.3; + +// `HelloWorld` نامی ایک کنٹریکٹ کی وضاحت کرتا ہے۔ +// ایک کنٹریکٹ فنکشنز اور ڈیٹا (اس کی حالت) کا ایک مجموعہ ہے۔ ایک بار ڈیپلائے ہونے کے بعد، ایک کنٹریکٹ Ethereum بلاک چین پر ایک مخصوص ایڈریس پر رہتا ہے۔ مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +contract HelloWorld { + + //اپ ڈیٹ فنکشن کال ہونے پر جاری کیا جاتا ہے + //اسمارٹ کنٹریکٹ ایونٹس آپ کے کنٹریکٹ کے لیے یہ بتانے کا ایک طریقہ ہیں کہ بلاک چین پر آپ کے ایپ فرنٹ اینڈ پر کچھ ہوا ہے، جو کچھ ایونٹس کے لیے 'سن' سکتا ہے اور جب وہ ہوتے ہیں تو کارروائی کر سکتا ہے۔ + event UpdatedMessages(string oldStr, string newStr); + + // `string` قسم کے `message` نامی ایک اسٹیٹ متغیر کا اعلان کرتا ہے۔ + // اسٹیٹ متغیرات وہ متغیرات ہیں جن کی قدریں کنٹریکٹ اسٹوریج میں مستقل طور پر محفوظ ہوتی ہیں۔ کلیدی لفظ `public` متغیرات کو کنٹریکٹ کے باہر سے قابل رسائی بناتا ہے اور ایک فنکشن بناتا ہے جسے دوسرے کنٹریکٹس یا کلائنٹس قدر تک رسائی کے لیے کال کر سکتے ہیں۔ + string public message; + + // بہت سی کلاس پر مبنی آبجیکٹ اورینٹڈ زبانوں کی طرح، ایک کنسٹرکٹر ایک خاص فنکشن ہے جو صرف کنٹریکٹ کی تخلیق پر عمل میں لایا جاتا ہے۔ + // کنسٹرکٹرز کا استعمال کنٹریکٹ کے ڈیٹا کو شروع کرنے کے لیے کیا جاتا ہے۔ مزید جانیں:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + constructor(string memory initMessage) { + + // ایک اسٹرنگ آرگیومنٹ `initMessage` کو قبول کرتا ہے اور قدر کو کنٹریکٹ کے `message` اسٹوریج متغیر میں سیٹ کرتا ہے۔ + message = initMessage; + } + + // ایک عوامی فنکشن جو ایک اسٹرنگ آرگیومنٹ کو قبول کرتا ہے اور `message` اسٹوریج متغیر کو اپ ڈیٹ کرتا ہے۔ + function update(string memory newMessage) public { + string memory oldMsg = message; + message = newMessage; + emit UpdatedMessages(oldMsg, newMessage); + } +} +``` + +اسمارٹ کنٹریکٹ ایونٹس آپ کے کنٹریکٹ کے لیے یہ بتانے کا ایک طریقہ ہیں کہ بلاک چین پر کچھ ہوا ہے (یعنی، ایک _ایونٹ_ تھا) آپ کی فرنٹ اینڈ ایپلیکیشن کو، جو مخصوص ایونٹس کے لیے 'سن' سکتی ہے اور جب وہ ہوتے ہیں تو کارروائی کر سکتی ہے۔ + +`addSmartContractListener` فنکشن خاص طور پر ہمارے ہیلو ورلڈ اسمارٹ کنٹریکٹ کے `UpdatedMessages` ایونٹ کو سنے گا، اور ہمارے UI کو نیا پیغام دکھانے کے لیے اپ ڈیٹ کرے گا۔ + +`addSmartContractListener` کو درج ذیل میں تبدیل کریں: + +```javascript +// HelloWorld.js + +function addSmartContractListener() { + helloWorldContract.events.UpdatedMessages({}, (error, data) => { + if (error) { + setStatus("😥 " + error.message) + } else { + setMessage(data.returnValues[1]) + setNewMessage("") + setStatus("🎉 آپ کا پیغام اپ ڈیٹ ہو گیا ہے!") + } + }) +} +``` + +آئیے دیکھتے ہیں کہ جب سننے والا کسی ایونٹ کا پتہ لگاتا ہے تو کیا ہوتا ہے: + +- اگر ایونٹ کے خارج ہونے پر کوئی خرابی ہوتی ہے، تو یہ ہمارے `status` ریاستی متغیر کے ذریعے UI میں ظاہر ہوگی۔ +- ورنہ، ہم واپس کیے گئے `data` آبجیکٹ کا استعمال کریں گے۔ `data.returnValues` ایک صفر پر انڈیکس شدہ سرنی ہے جہاں سرنی میں پہلا عنصر پچھلا پیغام اور دوسرا عنصر اپ ڈیٹ شدہ پیغام کو محفوظ کرتا ہے۔ مجموعی طور پر، ایک کامیاب ایونٹ پر ہم اپنی `message` اسٹرنگ کو اپ ڈیٹ شدہ پیغام پر سیٹ کریں گے، `newMessage` اسٹرنگ کو صاف کریں گے، اور اپنی `status` ریاستی متغیر کو اپ ڈیٹ کریں گے تاکہ یہ ظاہر ہو کہ ہمارے اسمارٹ کنٹریکٹ پر ایک نیا پیغام شائع ہوا ہے۔ + +آخر میں، آئیے اپنے `useEffect` فنکشن میں اپنے سننے والے کو کال کریں تاکہ یہ `HelloWorld.js` جزو کے پہلے رینڈر پر شروع ہو۔ مجموعی طور پر، آپ کا `useEffect` فنکشن اس طرح نظر آنا چاہیے: + +```javascript +// HelloWorld.js + +useEffect(async () => { + const message = await loadCurrentMessage() + setMessage(message) + addSmartContractListener() +}, []) +``` + +اب جب کہ ہم اپنے اسمارٹ کنٹریکٹ سے پڑھنے کے قابل ہیں، یہ بہت اچھا ہوگا کہ یہ معلوم کیا جائے کہ اس پر کیسے لکھا جائے! تاہم، اپنے dapp پر لکھنے کے لیے، ہمارے پاس پہلے ایک Ethereum والیٹ اس سے جڑا ہونا چاہیے۔ + +لہذا، اگلا ہم اپنا Ethereum والیٹ (MetaMask) سیٹ اپ کرنے اور پھر اسے اپنے dapp سے جوڑنے کا کام کریں گے! + +### مرحلہ 4: اپنا Ethereum والیٹ سیٹ اپ کریں {#step-4-set-up-your-ethereum-wallet} + +Ethereum چین پر کچھ بھی لکھنے کے لیے، صارفین کو اپنی ورچوئل والیٹ کی پرائیویٹ کیز کا استعمال کرتے ہوئے ٹرانزیکشنز پر دستخط کرنا ہوگا۔ اس ٹیوٹوریل کے لیے، ہم [MetaMask](https://metamask.io/) کا استعمال کریں گے، جو براؤزر میں ایک ورچوئل والیٹ ہے جو آپ کے Ethereum اکاؤنٹ کے پتے کا انتظام کرنے کے لیے استعمال ہوتا ہے، کیونکہ یہ اس ٹرانزیکشن پر دستخط کو آخری صارف کے لیے بہت آسان بنا دیتا ہے۔ + +اگر آپ یہ سمجھنا چاہتے ہیں کہ Ethereum پر ٹرانزیکشنز کیسے کام کرتی ہیں، تو Ethereum فاؤنڈیشن کا [یہ صفحہ](/developers/docs/transactions/) دیکھیں۔ + +#### MetaMask ڈاؤن لوڈ کریں {#download-metamask} + +آپ [یہاں](https://metamask.io/download) مفت میں MetaMask اکاؤنٹ ڈاؤن لوڈ اور بنا سکتے ہیں۔ جب آپ ایک اکاؤنٹ بنا رہے ہوں، یا اگر آپ کے پاس پہلے سے ہی ایک اکاؤنٹ ہے، تو یقینی بنائیں کہ اوپری دائیں کونے میں "Goerli ٹیسٹ نیٹ ورک" پر سوئچ کریں (تاکہ ہم اصلی پیسے سے نمٹ نہ رہے ہوں)۔ + +#### ایک فوسیٹ سے ایتھر شامل کریں {#add-ether-from-a-faucet} + +Ethereum بلاک چین پر ایک ٹرانزیکشن پر دستخط کرنے کے لیے، ہمیں کچھ جعلی Eth کی ضرورت ہوگی۔ Eth حاصل کرنے کے لیے آپ [FaucETH](https://fauceth.komputing.org) پر جا سکتے ہیں اور اپنا Goerli اکاؤنٹ ایڈریس درج کر سکتے ہیں، "فنڈز کی درخواست کریں" پر کلک کریں، پھر ڈراپ ڈاؤن میں "Ethereum Testnet Goerli" منتخب کریں اور آخر میں "فنڈز کی درخواست کریں" بٹن کو دوبارہ کلک کریں۔ اس کے فوراً بعد آپ کو اپنے MetaMask اکاؤنٹ میں Eth نظر آنا چاہیے! + +#### اپنا بیلنس چیک کریں {#check-your-balance} + +ہمارا بیلنس موجود ہے یا نہیں اس کی دوبارہ جانچ کرنے کے لیے، آئیے [Alchemy کے کمپوزر ٹول](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) کا استعمال کرتے ہوئے ایک [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) کی درخواست کریں۔ یہ ہمارے والیٹ میں Eth کی رقم واپس کرے گا۔ اپنے MetaMask اکاؤنٹ کا ایڈریس درج کرنے اور "Send Request" پر کلک کرنے کے بعد، آپ کو اس طرح کا جواب نظر آنا چاہیے: + +```text +{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} +``` + +**نوٹ:** یہ نتیجہ wei میں ہے eth میں نہیں۔ Wei کو ایتھر کی سب سے چھوٹی اکائی کے طور پر استعمال کیا جاتا ہے۔ wei سے eth میں تبدیلی یہ ہے: 1 eth = 10¹⁸ wei۔ تو اگر ہم 0xde0b6b3a7640000 کو اعشاریہ میں تبدیل کرتے ہیں تو ہمیں 1\*10¹⁸ ملتا ہے جو 1 eth کے برابر ہے۔ + +اف! ہمارا جعلی پیسہ سب وہیں ہے! 🤑 + +### مرحلہ 5: MetaMask کو اپنے UI سے جوڑیں {#step-5-connect-metamask-to-your-UI} + +اب جب کہ ہمارا MetaMask والیٹ سیٹ اپ ہو گیا ہے، آئیے اپنے dApp کو اس سے جوڑتے ہیں! + +#### `connectWallet` فنکشن {#the-connectWallet-function} + +ہماری `interact.js` فائل میں، آئیے `connectWallet` فنکشن کو نافذ کریں، جسے ہم پھر اپنے `HelloWorld.js` جزو میں کال کر سکتے ہیں۔ + +آئیے `connectWallet` کو درج ذیل میں تبدیل کریں: + +```javascript +// interact.js + +export const connectWallet = async () => { + if (window.ethereum) { + try { + const addressArray = await window.ethereum.request({ + method: "eth_requestAccounts", + }) + const obj = { + status: "👆🏽 اوپر ٹیکسٹ فیلڈ میں ایک پیغام لکھیں۔", + address: addressArray[0], + } + return obj + } catch (err) { + return { + address: "", + status: "😥 " + err.message, + } + } + } else { + return { + address: "", + status: ( + +

+ {" "} + 🦊 + آپ کو اپنے براؤزر میں MetaMask، ایک ورچوئل Ethereum والیٹ، انسٹال کرنا ہوگا۔ + +

+
+ ), + } + } +} +``` + +تو کوڈ کا یہ بڑا بلاک بالکل کیا کرتا ہے؟ + +پہلے، یہ چیک کرتا ہے کہ آیا آپ کے براؤزر میں `window.ethereum` فعال ہے۔ + +`window.ethereum` MetaMask اور دیگر والیٹ فراہم کنندگان کے ذریعے انجیکٹ کردہ ایک عالمی API ہے جو ویب سائٹس کو صارفین کے Ethereum اکاؤنٹس کی درخواست کرنے کی اجازت دیتا ہے۔ اگر منظور ہو جائے، تو یہ ان بلاک چینز سے ڈیٹا پڑھ سکتا ہے جن سے صارف جڑا ہوا ہے، اور صارف کو پیغامات اور ٹرانزیکشنز پر دستخط کرنے کا مشورہ دے سکتا ہے۔ مزید معلومات کے لیے [MetaMask دستاویزات](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) دیکھیں! + +اگر `window.ethereum` موجود _نہیں_ ہے، تو اس کا مطلب ہے کہ MetaMask انسٹال نہیں ہے۔ اس کے نتیجے میں ایک JSON آبجیکٹ واپس کیا جاتا ہے، جہاں واپس کیا گیا `address` ایک خالی اسٹرنگ ہوتا ہے، اور `status` JSX آبجیکٹ یہ بتاتا ہے کہ صارف کو MetaMask انسٹال کرنا ہوگا۔ + +اب اگر `window.ethereum` موجود _ہے_، تو یہ وہ جگہ ہے جہاں چیزیں دلچسپ ہو جاتی ہیں۔ + +ایک try/catch لوپ کا استعمال کرتے ہوئے، ہم [`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts) کو کال کرکے MetaMask سے جڑنے کی کوشش کریں گے۔ اس فنکشن کو کال کرنے سے براؤزر میں MetaMask کھل جائے گا، جس کے تحت صارف سے اپنے والیٹ کو آپ کے dApp سے جوڑنے کا کہا جائے گا۔ + +- اگر صارف جڑنے کا انتخاب کرتا ہے، تو `method: "eth_requestAccounts"` ایک سرنی واپس کرے گا جس میں صارف کے تمام اکاؤنٹ پتے شامل ہوں گے جو dapp سے جڑے ہوئے ہیں۔ مجموعی طور پر، ہمارا `connectWallet` فنکشن ایک JSON آبجیکٹ واپس کرے گا جس میں اس اری کا _پہلا_ `address` (لائن 9 دیکھیں) اور ایک `status` پیغام ہوگا جو صارف کو اسمارٹ کنٹریکٹ کے لیے ایک پیغام لکھنے کا کہے گا۔ +- اگر صارف کنکشن کو مسترد کر دیتا ہے، تو JSON آبجیکٹ میں واپس کیے گئے `address` کے لیے ایک خالی اسٹرنگ اور ایک `status` پیغام ہوگا جو یہ ظاہر کرے گا کہ صارف نے کنکشن کو مسترد کر دیا ہے۔ + +اب جب کہ ہم نے یہ `connectWallet` فنکشن لکھ لیا ہے، اگلا مرحلہ اسے اپنے `HelloWorld.js` جزو میں کال کرنا ہے۔ + +#### `connectWallet` فنکشن کو اپنے `HelloWorld.js` UI جزو میں شامل کریں {#add-the-connectWallet-function-to-your-HelloWorld-js-ui-component} + +`HelloWorld.js` میں `connectWalletPressed` فنکشن پر جائیں، اور اسے درج ذیل میں اپ ڈیٹ کریں: + +```javascript +// HelloWorld.js + +const connectWalletPressed = async () => { + const walletResponse = await connectWallet() + setStatus(walletResponse.status) + setWallet(walletResponse.address) +} +``` + +نوٹ کریں کہ ہماری زیادہ تر فعالیت `interact.js` فائل سے ہمارے `HelloWorld.js` جزو سے کس طرح تجرید کی گئی ہے؟ یہ اس لیے ہے تاکہ ہم M-V-C پیراڈائم کی تعمیل کریں! + +`connectWalletPressed` میں، ہم صرف اپنے امپورٹ کردہ `connectWallet` فنکشن پر ایک await کال کرتے ہیں، اور اس کے جواب کا استعمال کرتے ہوئے، ہم اپنے `status` اور `walletAddress` متغیرات کو ان کے اسٹیٹ ہکس کے ذریعے اپ ڈیٹ کرتے ہیں۔ + +اب، آئیے دونوں فائلیں (`HelloWorld.js` اور `interact.js`) محفوظ کریں اور اب تک اپنے UI کی جانچ کریں۔ + +[http://localhost:3000/](http://localhost:3000/) صفحے پر اپنا براؤزر کھولیں، اور صفحے کے اوپری دائیں کونے میں "والیٹ جوڑیں" بٹن دبائیں۔ + +اگر آپ نے MetaMask انسٹال کیا ہوا ہے، تو آپ سے اپنے والیٹ کو اپنے dApp سے جوڑنے کا کہا جائے گا۔ جڑنے کی دعوت قبول کریں۔ + +آپ کو دیکھنا چاہئے کہ والیٹ بٹن اب یہ ظاہر کرتا ہے کہ آپ کا پتہ جڑا ہوا ہے! بہت خوب 🔥 + +اگلا، صفحہ کو ریفریش کرنے کی کوشش کریں... یہ عجیب ہے۔ ہمارا والیٹ بٹن ہمیں MetaMask سے جڑنے کا کہہ رہا ہے، حالانکہ یہ پہلے سے ہی جڑا ہوا ہے... + +تاہم، کوئی خوف نہیں! ہم اسے آسانی سے حل کر سکتے ہیں (سمجھے؟) `getCurrentWalletConnected` کو نافذ کرکے، جو یہ چیک کرے گا کہ آیا کوئی پتہ پہلے سے ہی ہمارے dapp سے جڑا ہوا ہے اور ہمارے UI کو اسی کے مطابق اپ ڈیٹ کرے گا! + +#### `getCurrentWalletConnected` فنکشن {#the-getcurrentwalletconnected-function} + +`interact.js` فائل میں اپنے `getCurrentWalletConnected` فنکشن کو درج ذیل میں اپ ڈیٹ کریں: + +```javascript +// interact.js + +export const getCurrentWalletConnected = async () => { + if (window.ethereum) { + try { + const addressArray = await window.ethereum.request({ + method: "eth_accounts", + }) + if (addressArray.length > 0) { + return { + address: addressArray[0], + status: "👆🏽 اوپر ٹیکسٹ فیلڈ میں ایک پیغام لکھیں۔", + } + } else { + return { + address: "", + status: "🦊 اوپر دائیں بٹن کا استعمال کرتے ہوئے MetaMask سے جڑیں۔", + } + } + } catch (err) { + return { + address: "", + status: "😥 " + err.message, + } + } + } else { + return { + address: "", + status: ( + +

+ {" "} + 🦊 + آپ کو اپنے براؤزر میں MetaMask، ایک ورچوئل Ethereum والیٹ، انسٹال کرنا ہوگا۔ + +

+
+ ), + } + } +} +``` + +یہ کوڈ _بہت_ ملتا جلتا ہے `connectWallet` فنکشن سے جو ہم نے پچھلے مرحلے میں لکھا تھا۔ + +بنیادی فرق یہ ہے کہ `eth_requestAccounts` میتھڈ کو کال کرنے کے بجائے، جو صارف کے لیے اپنے والیٹ کو جوڑنے کے لیے MetaMask کھولتا ہے، یہاں ہم `eth_accounts` میتھڈ کو کال کرتے ہیں، جو صرف ایک اری واپس کرتا ہے جس میں فی الحال ہمارے dApp سے جڑے ہوئے MetaMask پتے ہوتے ہیں۔ + +اس فنکشن کو عمل میں دیکھنے کے لیے، آئیے اسے اپنے `HelloWorld.js` جزو کے `useEffect` فنکشن میں کال کریں: + +```javascript +// HelloWorld.js + +useEffect(async () => { + const message = await loadCurrentMessage() + setMessage(message) + addSmartContractListener() + + const { address, status } = await getCurrentWalletConnected() + setWallet(address) + setStatus(status) +}, []) +``` + +نوٹ کریں، ہم اپنے `walletAddress` اور `status` اسٹیٹ متغیرات کو اپ ڈیٹ کرنے کے لیے `getCurrentWalletConnected` پر اپنی کال کے جواب کا استعمال کرتے ہیں۔ + +اب جب کہ آپ نے یہ کوڈ شامل کر دیا ہے، آئیے اپنے براؤزر ونڈو کو ریفریش کرنے کی کوشش کریں۔ + +بہت اچھے! بٹن کو کہنا چاہیے کہ آپ جڑے ہوئے ہیں، اور آپ کے جڑے ہوئے والیٹ کے پتے کا ایک پیش نظارہ دکھانا چاہیے - یہاں تک کہ آپ کے ریفریش کرنے کے بعد بھی! + +#### `addWalletListener` نافذ کریں {#implement-addwalletlistener} + +ہمارے dApp والیٹ سیٹ اپ کا آخری مرحلہ والیٹ لسنر کو نافذ کرنا ہے تاکہ جب ہمارے والیٹ کی حالت تبدیل ہو تو ہمارا UI اپ ڈیٹ ہو، جیسے جب صارف منقطع ہوتا ہے یا اکاؤنٹس تبدیل کرتا ہے۔ + +اپنی `HelloWorld.js` فائل میں، اپنے `addWalletListener` فنکشن کو درج ذیل میں تبدیل کریں: + +```javascript +// HelloWorld.js + +function addWalletListener() { + if (window.ethereum) { + window.ethereum.on("accountsChanged", (accounts) => { + if (accounts.length > 0) { + setWallet(accounts[0]) + setStatus("👆🏽 اوپر ٹیکسٹ فیلڈ میں ایک پیغام لکھیں۔") + } else { + setWallet("") + setStatus("🦊 اوپر دائیں بٹن کا استعمال کرتے ہوئے MetaMask سے جڑیں۔") + } + }) + } else { + setStatus( +

+ {" "} + 🦊 + آپ کو اپنے براؤزر میں MetaMask، ایک ورچوئل Ethereum والیٹ، انسٹال کرنا ہوگا۔ + +

+ ) + } +} +``` + +مجھے شرط ہے کہ آپ کو اس مقام پر کیا ہو رہا ہے یہ سمجھنے کے لیے ہماری مدد کی بھی ضرورت نہیں ہے، لیکن مکمل ہونے کی خاطر، آئیے اسے جلدی سے توڑتے ہیں: + +- سب سے پہلے، ہمارا فنکشن چیک کرتا ہے کہ آیا `window.ethereum` فعال ہے (یعنی، MetaMask انسٹال ہے)۔ + - اگر ایسا نہیں ہے، تو ہم صرف اپنے `status` اسٹیٹ متغیر کو ایک JSX اسٹرنگ پر سیٹ کرتے ہیں جو صارف کو MetaMask انسٹال کرنے کا کہتا ہے۔ + - اگر یہ فعال ہے، تو ہم لائن 3 پر لسنر `window.ethereum.on("accountsChanged")` سیٹ اپ کرتے ہیں جو MetaMask والیٹ میں اسٹیٹ تبدیلیوں کو سنتا ہے، جس میں یہ شامل ہے کہ جب صارف dApp سے ایک اضافی اکاؤنٹ جوڑتا ہے، اکاؤنٹس تبدیل کرتا ہے، یا ایک اکاؤنٹ منقطع کرتا ہے۔ اگر کم از کم ایک اکاؤنٹ جڑا ہوا ہے، تو `walletAddress` اسٹیٹ متغیر کو لسنر کے ذریعے واپس کیے گئے `accounts` اری میں پہلے اکاؤنٹ کے طور پر اپ ڈیٹ کیا جاتا ہے۔ ورنہ، `walletAddress` کو ایک خالی اسٹرنگ کے طور پر سیٹ کیا جاتا ہے۔ + +آخری لیکن کم از کم، ہمیں اسے اپنے `useEffect` فنکشن میں کال کرنا ہوگا: + +```javascript +// HelloWorld.js + +useEffect(async () => { + const message = await loadCurrentMessage() + setMessage(message) + addSmartContractListener() + + const { address, status } = await getCurrentWalletConnected() + setWallet(address) + setStatus(status) + + addWalletListener() +}, []) +``` + +اور بس! ہم نے کامیابی سے اپنی تمام والیٹ کی فعالیت کی پروگرامنگ مکمل کر لی ہے! اب اپنے آخری کام کی طرف: اپنے اسمارٹ کنٹریکٹ میں محفوظ پیغام کو اپ ڈیٹ کرنا! + +### مرحلہ 6: `updateMessage` فنکشن نافذ کریں {#step-6-implement-the-updateMessage-function} + +ٹھیک ہے فیم، ہم آخری مرحلے پر پہنچ گئے ہیں! اپنی `interact.js` فائل کے `updateMessage` میں، ہم درج ذیل کام کرنے جا رہے ہیں: + +1. یقینی بنائیں کہ وہ پیغام جسے ہم اپنے اسمارٹ رابطہ میں شائع کرنا چاہتے ہیں، درست ہے +2. MetaMask کا استعمال کرتے ہوئے اپنے ٹرانزیکشن پر دستخط کریں +3. اس فنکشن کو ہمارے `HelloWorld.js` فرنٹ اینڈ جزو سے کال کریں + +اس میں زیادہ وقت نہیں لگے گا؛ آئیے اس dapp کو مکمل کریں! + +#### ان پٹ کی خرابی کو ہینڈل کرنا {#input-error-handling} + +فطری طور پر، فنکشن کے آغاز میں کسی قسم کا ان پٹ ایرر ہینڈلنگ ہونا معنی خیز ہے۔ + +ہم چاہیں گے کہ ہمارا فنکشن جلد واپس آ جائے اگر کوئی MetaMask ایکسٹینشن انسٹال نہیں ہے، کوئی والیٹ جڑا ہوا نہیں ہے (یعنی، پاس کیا گیا `address` ایک خالی اسٹرنگ ہے)، یا `message` ایک خالی اسٹرنگ ہے۔ آئیے `updateMessage` میں درج ذیل ایرر ہینڈلنگ شامل کریں: + +```javascript +// interact.js + +export const updateMessage = async (address, message) => { + if (!window.ethereum || address === null) { + return { + status: + "💡 بلاک چین پر پیغام کو اپ ڈیٹ کرنے کے لیے اپنا MetaMask والیٹ جوڑیں۔", + } + } + + if (message.trim() === "") { + return { + status: "❌ آپ کا پیغام خالی اسٹرنگ نہیں ہو سکتا۔", + } + } +} +``` + +اب جب کہ اس میں مناسب ان پٹ ایرر ہینڈلنگ ہے، اب وقت آگیا ہے کہ MetaMask کے ذریعے ٹرانزیکشن پر دستخط کریں! + +#### ہمارے ٹرانزیکشن پر دستخط کرنا {#signing-our-transaction} + +اگر آپ پہلے سے ہی روایتی web3 Ethereum ٹرانزیکشنز کے ساتھ آرام دہ ہیں، تو جو کوڈ ہم اگلا لکھیں گے وہ بہت مانوس ہوگا۔ اپنے ان پٹ ایرر ہینڈلنگ کوڈ کے نیچے، `updateMessage` میں درج ذیل شامل کریں: + +```javascript +// interact.js + +//ٹرانزیکشن پیرامیٹرز سیٹ اپ کریں +const transactionParameters = { + to: contractAddress, // کنٹریکٹ کی اشاعت کے دوران کے علاوہ ضروری ہے۔ + from: address, // صارف کے فعال پتے سے مماثل ہونا چاہئے۔ + data: helloWorldContract.methods.update(message).encodeABI(), +} + +//ٹرانزیکشن پر دستخط کریں +try { + const txHash = await window.ethereum.request({ + method: "eth_sendTransaction", + params: [transactionParameters], + }) + return { + status: ( + + ✅{" "} + + Etherscan پر اپنے ٹرانزیکشن کی حیثیت دیکھیں! + +
+ ℹ️ ایک بار جب ٹرانزیکشن نیٹ ورک کے ذریعے تصدیق ہو جائے گی، پیغام خود بخود اپ ڈیٹ ہو جائے گا۔ +
+ ), + } +} catch (error) { + return { + status: "😥 " + error.message, + } +} +``` + +آئیے دیکھتے ہیں کہ کیا ہو رہا ہے۔ پہلے، ہم اپنے ٹرانزیکشنز پیرامیٹرز سیٹ اپ کرتے ہیں، جہاں: + +- `to` وصول کنندہ کا پتہ (ہمارا اسمارٹ کنٹریکٹ) بتاتا ہے +- `from` ٹرانزیکشن کے دستخط کنندہ کی وضاحت کرتا ہے، `address` متغیر جسے ہم نے اپنے فنکشن میں پاس کیا تھا +- `data` ہمارے ہیلو ورلڈ اسمارٹ کنٹریکٹ کے `update` میتھڈ کی کال پر مشتمل ہے، جو ہمارے `message` اسٹرنگ متغیر کو ان پٹ کے طور پر حاصل کرتا ہے + +پھر، ہم ایک `window.ethereum.request` کال کا انتظار کرتے ہیں، جہاں ہم MetaMask سے ٹرانزیکشن پر دستخط کرنے کے لیے کہتے ہیں۔ نوٹ کریں، لائن 11 اور 12 پر، ہم اپنے eth میتھڈ، `eth_sendTransaction` کی وضاحت کر رہے ہیں اور اپنے `transactionParameters` کو پاس کر رہے ہیں۔ + +اس مقام پر، MetaMask براؤزر میں کھل جائے گا، اور صارف سے ٹرانزیکشن پر دستخط کرنے یا مسترد کرنے کا کہے گا۔ + +- اگر ٹرانزیکشن کامیاب ہو جاتی ہے، تو فنکشن ایک JSON آبجیکٹ واپس کرے گا جہاں `status` JSX اسٹرنگ صارف کو اپنے ٹرانزیکشن کے بارے میں مزید معلومات کے لیے Etherscan چیک کرنے کا اشارہ دیتی ہے۔ +- اگر ٹرانزیکشن ناکام ہو جاتی ہے، تو فنکشن ایک JSON آبجیکٹ واپس کرے گا جہاں `status` اسٹرنگ خرابی کا پیغام پہنچاتی ہے۔ + +مجموعی طور پر، ہمارا `updateMessage` فنکشن اس طرح نظر آنا چاہیے: + +```javascript +// interact.js + +export const updateMessage = async (address, message) => { + //ان پٹ ایرر ہینڈلنگ + if (!window.ethereum || address === null) { + return { + status: + "💡 بلاک چین پر پیغام کو اپ ڈیٹ کرنے کے لیے اپنا MetaMask والیٹ جوڑیں۔", + } + } + + if (message.trim() === "") { + return { + status: "❌ آپ کا پیغام خالی اسٹرنگ نہیں ہو سکتا۔", + } + } + + //ٹرانزیکشن پیرامیٹرز سیٹ اپ کریں + const transactionParameters = { + to: contractAddress, // کنٹریکٹ کی اشاعت کے دوران کے علاوہ ضروری ہے۔ + from: address, // صارف کے فعال پتے سے مماثل ہونا چاہئے۔ + data: helloWorldContract.methods.update(message).encodeABI(), + } + + //ٹرانزیکشن پر دستخط کریں + try { + const txHash = await window.ethereum.request({ + method: "eth_sendTransaction", + params: [transactionParameters], + }) + return { + status: ( + + ✅{" "} + + Etherscan پر اپنے ٹرانزیکشن کی حیثیت دیکھیں! + +
+ ℹ️ ایک بار جب ٹرانزیکشن نیٹ ورک کے ذریعے تصدیق ہو جائے گی، پیغام خود بخود اپ ڈیٹ ہو جائے گا۔ +
+ ), + } + } catch (error) { + return { + status: "😥 " + error.message, + } + } +} +``` + +آخری لیکن کم از کم، ہمیں اپنے `updateMessage` فنکشن کو اپنے `HelloWorld.js` جزو سے جوڑنے کی ضرورت ہے۔ + +#### `updateMessage` کو `HelloWorld.js` فرنٹ اینڈ سے جوڑیں {#connect-updatemessage-to-the-helloworld-js-frontend} + +ہمارے `onUpdatePressed` فنکشن کو درآمد شدہ `updateMessage` فنکشن پر ایک await کال کرنی چاہیے اور `status` ریاستی متغیر میں ترمیم کرنی چاہیے تاکہ یہ ظاہر ہو کہ آیا ہمارا ٹرانزیکشن کامیاب ہوا یا ناکام: + +```javascript +// HelloWorld.js + +const onUpdatePressed = async () => { + const { status } = await updateMessage(walletAddress, newMessage) + setStatus(status) +} +``` + +یہ بہت صاف اور سادہ ہے۔ اور اندازہ لگائیں کیا... آپ کا DAPP مکمل ہے!!! + +آگے بڑھیں اور **اپ ڈیٹ** بٹن کو آزمائیں! + +### اپنا کسٹم dapp بنائیں {#make-your-own-custom-dapp} + +واہ، آپ ٹیوٹوریل کے آخر تک پہنچ گئے! خلاصہ کرنے کے لیے، آپ نے سیکھا کہ کیسے: + +- MetaMask والیٹ کو اپنے dapp پروجیکٹ سے جوڑیں +- [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) API کا استعمال کرتے ہوئے اپنے اسمارٹ کنٹریکٹ سے ڈیٹا پڑھیں +- MetaMask کا استعمال کرتے ہوئے Ethereum ٹرانزیکشنز پر دستخط کریں + +اب آپ اس ٹیوٹوریل کی مہارتوں کو اپنے کسٹم dapp پروجیکٹ کی تعمیر کے لیے استعمال کرنے کے لیے پوری طرح سے لیس ہیں! ہمیشہ کی طرح، اگر آپ کے کوئی سوالات ہیں، تو [Alchemy Discord](https://discord.gg/gWuC7zB) میں مدد کے لیے ہم سے رابطہ کرنے میں ہچکچاہٹ نہ کریں۔ 🧙‍♂️ + +ایک بار جب آپ یہ ٹیوٹوریل مکمل کر لیں، تو ہمیں بتائیں کہ آپ کا تجربہ کیسا رہا یا اگر آپ کے پاس کوئی رائے ہے تو ہمیں ٹویٹر پر [@alchemyplatform](https://twitter.com/AlchemyPlatform) پر ٹیگ کرکے بتائیں! diff --git a/public/content/translations/ur/developers/tutorials/hello-world-smart-contract/index.md b/public/content/translations/ur/developers/tutorials/hello-world-smart-contract/index.md new file mode 100644 index 00000000000..9fbaff1d609 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/hello-world-smart-contract/index.md @@ -0,0 +1,366 @@ +--- +title: "ابتدائی افراد کے لیے ہیلو ورلڈ اسمارٹ کنٹریکٹ" +description: "Ethereum پر ایک سادہ اسمارٹ کنٹریکٹ لکھنے اور اسے ڈیپلائے کرنے کے بارے میں تعارفی ٹیوٹوریل۔" +author: "elanh" +tags: + [ + "solidity", + "hardhat", + "alchemy", + "اسمارٹ معاہدات", + "تعینات کرنا" + ] +skill: beginner +lang: ur-in +published: 2021-03-31 +--- + +اگر آپ بلاک چین ڈیولپمنٹ میں نئے ہیں اور نہیں جانتے کہ کہاں سے شروع کریں، یا اگر آپ صرف یہ سمجھنا چاہتے ہیں کہ اسمارٹ کنٹریکٹس کو کیسے ڈیپلائے اور ان کے ساتھ کیسے انٹریکٹ کیا جائے، تو یہ گائیڈ آپ کے لیے ہے۔ ہم ایک ورچوئل والیٹ [MetaMask](https://metamask.io/)، [Solidity](https://docs.soliditylang.org/en/v0.8.0/)، [Hardhat](https://hardhat.org/)، اور [Alchemy](https://www.alchemy.com/eth) کا استعمال کرتے ہوئے Sepolia ٹیسٹ نیٹ ورک پر ایک سادہ اسمارٹ کنٹریکٹ بنانے اور اسے ڈیپلائے کرنے کے عمل سے گزریں گے (اگر آپ ابھی تک یہ نہیں سمجھ پائے ہیں کہ ان میں سے کسی کا کیا مطلب ہے تو فکر نہ کریں، ہم اس کی وضاحت کریں گے)۔ + +اس ٹیوٹوریل کے [حصہ 2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract) میں ہم یہ دیکھیں گے کہ ایک بار یہاں ڈیپلائے ہونے کے بعد ہم اپنے اسمارٹ کنٹریکٹ کے ساتھ کیسے انٹریکٹ کر سکتے ہیں، اور [حصہ 3](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) میں ہم اسے Etherscan پر کیسے پبلش کرنا ہے اس پر بات کریں گے۔ + +اگر کسی بھی وقت آپ کے سوالات ہوں تو [Alchemy Discord](https://discord.gg/gWuC7zB) میں بلا جھجھک رابطہ کریں! + +## مرحلہ 1: Ethereum نیٹ ورک سے جڑیں {#step-1} + +Ethereum چین سے درخواستیں کرنے کے بہت سے طریقے ہیں۔ سادگی کے لیے، ہم Alchemy پر ایک مفت اکاؤنٹ استعمال کریں گے، جو ایک بلاک چین ڈیولپر پلیٹ فارم اور API ہے جو ہمیں اپنے نوڈس چلائے بغیر Ethereum چین کے ساتھ بات چیت کرنے کی اجازت دیتا ہے۔ اس پلیٹ فارم میں نگرانی اور تجزیات کے لیے ڈیولپر ٹولز بھی ہیں جن سے ہم اس ٹیوٹوریل میں فائدہ اٹھائیں گے تاکہ یہ سمجھ سکیں کہ ہمارے اسمارٹ کنٹریکٹ کی ڈیپلائمنٹ میں پس پردہ کیا ہو رہا ہے۔ اگر آپ کے پاس پہلے سے Alchemy اکاؤنٹ نہیں ہے، تو [آپ یہاں مفت میں سائن اپ کر سکتے ہیں](https://dashboard.alchemy.com/signup)۔ + +## مرحلہ 2: اپنی ایپ (اور API کلید) بنائیں {#step-2} + +ایک بار جب آپ Alchemy اکاؤنٹ بنا لیں، تو آپ ایک ایپ بنا کر API کلید تیار کر سکتے ہیں۔ یہ ہمیں Sepolia ٹیسٹ نیٹ ورک سے درخواستیں کرنے کی اجازت دے گا۔ اگر آپ ٹیسٹ نیٹس سے واقف نہیں ہیں، تو [یہ صفحہ](/developers/docs/networks/) دیکھیں۔ + +1. نیو بار میں "Select an app" منتخب کرکے اور "Create new app" پر کلک کرکے اپنے Alchemy ڈیش بورڈ میں "Create new app" صفحہ پر جائیں۔ + +![Hello world create app](./hello-world-create-app.png) + +2. اپنی ایپ کو ”Hello World“ کا نام دیں، ایک مختصر تفصیل پیش کریں، اور ایک یوز کیس منتخب کریں، مثلاً، "Infra & Tooling"۔ اگلا، "Ethereum" تلاش کریں اور نیٹ ورک منتخب کریں۔ + +![create app view hello world](./create-app-view-hello-world.png) + +3. آگے بڑھنے کے لیے "Next" پر کلک کریں، پھر ”Create app“ اور بس! آپ کا کام ہو گیا۔ آپ کی ایپ نیو بار ڈراپ ڈاؤن مینو میں ظاہر ہونی چاہیے، جس میں کاپی کرنے کے لیے ایک API کلید دستیاب ہوگی۔ + +## مرحلہ 3: ایک Ethereum اکاؤنٹ (ایڈریس) بنائیں {#step-3} + +ٹرانزیکشنز بھیجنے اور وصول کرنے کے لیے ہمیں ایک Ethereum اکاؤنٹ کی ضرورت ہے۔ اس ٹیوٹوریل کے لیے، ہم MetaMask استعمال کریں گے، جو براؤزر میں ایک ورچوئل والیٹ ہے جو آپ کے Ethereum اکاؤنٹ ایڈریس کو منظم کرنے کے لیے استعمال ہوتا ہے۔ [لین دین](/developers/docs/transactions/) پر مزید۔ + +آپ [یہاں](https://metamask.io/download) سے MetaMask ڈاؤن لوڈ کر سکتے ہیں اور مفت میں ایک Ethereum اکاؤنٹ بنا سکتے ہیں۔ جب آپ ایک اکاؤنٹ بنا رہے ہوں، یا اگر آپ کے پاس پہلے سے ہی ایک اکاؤنٹ ہے، تو یقینی بنائیں کہ آپ نیٹ ورک ڈراپ ڈاؤن مینو کا استعمال کرکے "Sepolia" ٹیسٹ نیٹ ورک پر سوئچ کر لیں (تاکہ ہم حقیقی رقم سے نمٹ نہ رہے ہوں)۔ + +اگر آپ کو فہرست میں Sepolia نظر نہیں آتا، تو مینو میں جائیں، پھر ایڈوانسڈ میں جائیں اور "Show test networks" کو آن کرنے کے لیے نیچے اسکرول کریں۔ نیٹ ورک سلیکشن مینو میں، ٹیسٹ نیٹس کی فہرست تلاش کرنے کے لیے "Custom" ٹیب کا انتخاب کریں اور "Sepolia" کو منتخب کریں۔ + +![metamask sepolia example](./metamask-sepolia-example.png) + +## مرحلہ 4: ایک فوسیٹ سے ایتھر شامل کریں {#step-4} + +اپنے اسمارٹ کنٹریکٹ کو ٹیسٹ نیٹ ورک پر ڈیپلائے کرنے کے لیے، ہمیں کچھ جعلی Eth کی ضرورت ہوگی۔ Sepolia ETH حاصل کرنے کے لیے آپ مختلف فوسیٹس کی فہرست دیکھنے کے لیے [Sepolia نیٹ ورک کی تفصیلات](/developers/docs/networks/#sepolia) پر جا سکتے ہیں۔ اگر کوئی کام نہ کرے تو دوسرا آزمائیں کیونکہ وہ کبھی کبھی خالی ہو سکتے ہیں۔ نیٹ ورک ٹریفک کی وجہ سے آپ کو اپنا جعلی ETH حاصل کرنے میں کچھ وقت لگ سکتا ہے۔ آپ کو جلد ہی اپنے Metamask اکاؤنٹ میں ETH نظر آنا چاہیے! + +## مرحلہ 5: اپنا بیلنس چیک کریں {#step-5} + +یہ یقینی بنانے کے لیے کہ ہمارا بیلنس وہاں ہے، آئیے [Alchemy کے کمپوزر ٹول](https://sandbox.alchemy.com/?network=ETH_SEPOLIA&method=eth_getBalance&body.id=1&body.jsonrpc=2.0&body.method=eth_getBalance&body.params%5B0%5D=&body.params%5B1%5D=latest) کا استعمال کرتے ہوئے ایک [eth_getBalance](/developers/docs/apis/json-rpc/#eth_getbalance) درخواست کریں۔ یہ ہمارے والیٹ میں ETH کی رقم واپس کرے گا۔ اپنے MetaMask اکاؤنٹ کا ایڈریس درج کرنے اور "Send Request" پر کلک کرنے کے بعد، آپ کو اس طرح کا جواب نظر آنا چاہیے: + +```json +{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" } +``` + +> **نوٹ:** یہ نتیجہ ETH میں نہیں بلکہ wei میں ہے۔ Wei کو ایتھر کی سب سے چھوٹی اکائی کے طور پر استعمال کیا جاتا ہے۔ wei سے ETH میں تبدیلی یہ ہے: 1 eth = 1018 wei۔ لہذا اگر ہم 0x2B5E3AF16B1880000 کو ڈیسیمل میں تبدیل کریں تو ہمیں 5\*10¹⁸ ملتا ہے جو 5 ETH کے برابر ہے۔ +> +> اف! ہمارے جعلی پیسے سب وہاں ہیں ۔ + +## مرحلہ 6: ہمارے پروجیکٹ کو شروع کریں {#step-6} + +سب سے پہلے، ہمیں اپنے پروجیکٹ کے لیے ایک فولڈر بنانا ہوگا۔ اپنی کمانڈ لائن پر جائیں اور ٹائپ کریں: + +``` +mkdir hello-world +cd hello-world +``` + +اب جب کہ ہم اپنے پروجیکٹ فولڈر کے اندر ہیں، ہم پروجیکٹ کو شروع کرنے کے لیے `npm init` استعمال کریں گے۔ اگر آپ کے پاس پہلے سے npm انسٹال نہیں ہے، تو [ان ہدایات](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) پر عمل کریں (ہمیں Node.js کی بھی ضرورت ہوگی لہذا اسے بھی ڈاؤن لوڈ کریں!)۔ + +``` +npm init +``` + +اس سے کوئی فرق نہیں پڑتا کہ آپ انسٹالیشن کے سوالات کا جواب کیسے دیتے ہیں، یہاں حوالہ کے لیے ہم نے اسے کیسے کیا: + +``` +پیکیج کا نام: (hello-world) +ورژن: (1.0.0) +تفصیل: hello world smart contract +اینٹری پوائنٹ: (index.js) +ٹیسٹ کمانڈ: +گٹ ریپوزٹری: +کلیدی الفاظ: +مصنف: +لائسنس: (ISC) +/Users/.../.../.../hello-world/package.json میں لکھنے کے بارے میں: + +{ + "name": "hello-world", + "version": "1.0.0", + "description": "hello world smart contract", + "main": "index.js", + "scripts": { + "test": "echo \\"Error: no test specified\\" && exit 1" + }, + "author": "", + "license": "ISC" +} +``` + +package.json کو منظور کریں اور ہم تیار ہیں! + +## مرحلہ 7: [Hardhat](https://hardhat.org/getting-started/#overview) ڈاؤن لوڈ کریں {#step-7} + +Hardhat آپ کے Ethereum سافٹ ویئر کو کمپائل، ڈیپلوئے، ٹیسٹ اور ڈیبگ کرنے کے لیے ایک ڈیولپمنٹ ماحول ہے۔ یہ ڈیولپرز کو لائیو چین پر ڈیپلوئے کرنے سے پہلے مقامی طور پر اسمارٹ کنٹریکٹس اور dapps بنانے میں مدد کرتا ہے۔ + +ہمارے `hello-world` پروجیکٹ کے اندر چلائیں: + +``` +npm install --save-dev hardhat +``` + +[انسٹالیشن کی ہدایات](https://hardhat.org/getting-started/#overview) پر مزید تفصیلات کے لیے یہ صفحہ دیکھیں۔ + +## مرحلہ 8: Hardhat پروجیکٹ بنائیں {#step-8} + +ہمارے پروجیکٹ فولڈر کے اندر چلائیں: + +``` +npx hardhat +``` + +پھر آپ کو ایک خوش آمدیدی پیغام اور یہ منتخب کرنے کا آپشن نظر آئے گا کہ آپ کیا کرنا چاہتے ہیں۔ “create an empty hardhat.config.js” منتخب کریں: + +``` +888 888 888 888 888 +888 888 888 888 888 +888 888 888 888 888 +8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 +888 888 "88b 888P" d88" 888 888 "88b "88b 888 +888 888 .d888888 888 888 888 888 888 .d888888 888 +888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. +888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 + +👷 Hardhat v2.0.11 میں خوش آمدید 👷‍? + +آپ کیا کرنا چاہتے ہیں؟ … +ایک نمونہ پروجیکٹ بنائیں +❯ ایک خالی hardhat.config.js بنائیں +باہر نکلیں +``` + +یہ ہمارے لیے ایک `hardhat.config.js` فائل بنائے گا جہاں ہم اپنے پروجیکٹ کے لیے تمام سیٹ اپ کی وضاحت کریں گے (مرحلہ 13 پر)۔ + +## مرحلہ 9: پروجیکٹ فولڈرز شامل کریں {#step-9} + +اپنے پروجیکٹ کو منظم رکھنے کے لیے ہم دو نئے فولڈر بنائیں گے۔ اپنی کمانڈ لائن میں اپنے پروجیکٹ کی روٹ ڈائرکٹری پر جائیں اور ٹائپ کریں: + +``` +mkdir contracts +mkdir scripts +``` + +- `contracts/` وہ جگہ ہے جہاں ہم اپنی ہیلو ورلڈ اسمارٹ کنٹریکٹ کوڈ فائل رکھیں گے۔ +- `scripts/` وہ جگہ ہے جہاں ہم اپنے کنٹریکٹ کو ڈیپلائے کرنے اور اس کے ساتھ انٹریکٹ کرنے کے لیے اسکرپٹس رکھیں گے۔ + +## مرحلہ 10: ہمارا کنٹریکٹ لکھیں {#step-10} + +آپ خود سے پوچھ رہے ہوں گے کہ آخر ہم کوڈ کب لکھیں گے؟ خیر، ہم یہاں ہیں، مرحلہ 10 پر۔ + +اپنے پسندیدہ ایڈیٹر میں ہیلو-ورلڈ پروجیکٹ کھولیں (ہمیں [VSCode](https://code.visualstudio.com/) پسند ہے)۔ اسمارٹ کنٹریکٹس Solidity نامی زبان میں لکھے جاتے ہیں جسے ہم اپنا HelloWorld.sol اسمارٹ کنٹریکٹ لکھنے کے لیے استعمال کریں گے۔ + +1. ”contracts“ فولڈر پر جائیں اور HelloWorld.sol نامی ایک نئی فائل بنائیں۔ +2. نیچے Ethereum فاؤنڈیشن کا ایک نمونہ ہیلو ورلڈ اسمارٹ کنٹریکٹ ہے جسے ہم اس ٹیوٹوریل کے لیے استعمال کریں گے۔ نیچے دیے گئے مواد کو اپنی HelloWorld.sol فائل میں کاپی اور پیسٹ کریں، اور یہ سمجھنے کے لیے تبصرے ضرور پڑھیں کہ یہ کنٹریکٹ کیا کرتا ہے: + +```solidity +// سیمنٹک ورژنگ کا استعمال کرتے ہوئے، Solidity کا ورژن بتاتا ہے۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +pragma solidity ^0.7.0; + +// `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) { + + // ایک سٹرنگ آرگیومنٹ `initMessage` کو قبول کرتا ہے اور ویلیو کو کنٹریکٹ کے `message` اسٹوریج ویری ایبل میں سیٹ کرتا ہے۔ + message = initMessage; + } + + // ایک پبلک فنکشن جو ایک سٹرنگ آرگیومنٹ کو قبول کرتا ہے اور `message` اسٹوریج ویری ایبل کو اپ ڈیٹ کرتا ہے۔ + function update(string memory newMessage) public { + message = newMessage; + } +} +``` + +یہ ایک انتہائی سادہ اسمارٹ کنٹریکٹ ہے جو بناتے وقت ایک پیغام اسٹور کرتا ہے اور `update` فنکشن کو کال کرکے اپ ڈیٹ کیا جاسکتا ہے۔ + +## مرحلہ 11: MetaMask اور Alchemy کو اپنے پروجیکٹ سے جوڑیں {#step-11} + +ہم نے ایک MetaMask والیٹ، Alchemy اکاؤنٹ بنایا ہے، اور اپنا اسمارٹ کنٹریکٹ لکھا ہے، اب ان تینوں کو جوڑنے کا وقت آگیا ہے۔ + +آپ کے ورچوئل والیٹ سے بھیجی گئی ہر ٹرانزیکشن کے لیے آپ کی منفرد پرائیویٹ کلید کا استعمال کرتے ہوئے ایک دستخط کی ضرورت ہوتی ہے۔ ہمارے پروگرام کو یہ اجازت فراہم کرنے کے لیے، ہم اپنی پرائیویٹ کلید (اور Alchemy API کلید) کو ایک ماحولیاتی فائل میں محفوظ طریقے سے اسٹور کر سکتے ہیں۔ + +> ٹرانزیکشنز بھیجنے کے بارے میں مزید جاننے کے لیے، web3 کا استعمال کرتے ہوئے ٹرانزیکشنز بھیجنے پر [یہ ٹیوٹوریل](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) دیکھیں۔ + +سب سے پہلے، اپنی پروجیکٹ ڈائرکٹری میں dotenv پیکیج انسٹال کریں: + +``` +npm install dotenv --save +``` + +پھر، ہمارے پروجیکٹ کی روٹ ڈائرکٹری میں ایک `.env` فائل بنائیں، اور اس میں اپنی MetaMask پرائیویٹ کلید اور HTTP Alchemy API URL شامل کریں۔ + +- اپنی پرائیویٹ کلید کو ایکسپورٹ کرنے کے لیے [ان ہدایات](https://support.metamask.io/configure/accounts/how-to-export-an-accounts-private-key/) پر عمل کریں۔ +- HTTP Alchemy API URL حاصل کرنے کے لیے نیچے دیکھیں + +![get alchemy api key](./get-alchemy-api-key.png) + +Alchemy API URL کاپی کریں + +آپ کا `.env` اس طرح نظر آنا چاہیے: + +``` +API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key" +PRIVATE_KEY = "your-metamask-private-key" +``` + +انہیں حقیقت میں ہمارے کوڈ سے جوڑنے کے لیے، ہم ان متغیرات کا حوالہ اپنی `hardhat.config.js` فائل میں مرحلہ 13 پر دیں گے۔ + + + + +.env کو کمٹ نہ کریں! براہ کرم یقینی بنائیں کہ آپ اپنی .env فائل کسی کے ساتھ شیئر یا ظاہر نہ کریں، کیونکہ ایسا کرنے سے آپ اپنے رازوں پر سمجھوتہ کر رہے ہیں۔ اگر آپ ورژن کنٹرول استعمال کر رہے ہیں، تو اپنی .env کو gitignore فائل میں شامل کریں۔ + + + + +## مرحلہ 12: Ethers.js انسٹال کریں {#step-12-install-ethersjs} + +Ethers.js ایک لائبریری ہے جو [معیاری JSON-RPC طریقوں](/developers/docs/apis/json-rpc/) کو زیادہ صارف دوست طریقوں کے ساتھ لپیٹ کر Ethereum کے ساتھ تعامل اور درخواستیں کرنا آسان بناتی ہے۔ + +Hardhat اضافی ٹولنگ اور توسیع شدہ فعالیت کے لیے [پلگ انز](https://hardhat.org/plugins/) کو ضم کرنا انتہائی آسان بناتا ہے۔ ہم کنٹریکٹ ڈیپلائمنٹ کے لیے [Ethers پلگ ان](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) سے فائدہ اٹھائیں گے ([Ethers.js](https://github.com/ethers-io/ethers.js/) میں کچھ انتہائی صاف کنٹریکٹ ڈیپلائمنٹ کے طریقے ہیں)۔ + +اپنی پروجیکٹ ڈائرکٹری میں ٹائپ کریں: + +``` +npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0" +``` + +ہمیں اگلے مرحلے میں اپنی `hardhat.config.js` میں بھی ethers کی ضرورت ہوگی۔ + +## مرحلہ 13: hardhat.config.js کو اپ ڈیٹ کریں {#step-13-update-hardhatconfigjs} + +ہم نے اب تک کئی انحصارات اور پلگ ان شامل کیے ہیں، اب ہمیں `hardhat.config.js` کو اپ ڈیٹ کرنے کی ضرورت ہے تاکہ ہمارے پروجیکٹ کو ان سب کے بارے میں معلوم ہو۔ + +اپنی `hardhat.config.js` کو اس طرح اپ ڈیٹ کریں: + +``` +require('dotenv').config(); + +require("@nomiclabs/hardhat-ethers"); +const { API_URL, PRIVATE_KEY } = process.env; + +/** +* @type import('hardhat/config').HardhatUserConfig +*/ +module.exports = { + solidity: "0.7.3", + defaultNetwork: "sepolia", + networks: { + hardhat: {}, + sepolia: { + url: API_URL, + accounts: [`0x${PRIVATE_KEY}`] + } + }, +} +``` + +## مرحلہ 14: ہمارے کنٹریکٹ کو کمپائل کریں {#step-14-compile-our-contracts} + +یہ یقینی بنانے کے لیے کہ اب تک سب کچھ کام کر رہا ہے، آئیے اپنے کنٹریکٹ کو کمپائل کریں۔ `compile` ٹاسک بلٹ ان ہارڈ ہیٹ ٹاسک میں سے ایک ہے۔ + +کمانڈ لائن سے چلائیں: + +``` +npx hardhat compile +``` + +آپ کو `SPDX license identifier not provided in source file` کے بارے میں ایک وارننگ مل سکتی ہے، لیکن اس کے بارے میں فکر کرنے کی ضرورت نہیں ہے — امید ہے کہ باقی سب کچھ اچھا لگے گا! اگر نہیں، تو آپ ہمیشہ [Alchemy discord](https://discord.gg/u72VCg3) میں پیغام بھیج سکتے ہیں۔ + +## مرحلہ 15: ہماری ڈیپلائے اسکرپٹ لکھیں {#step-15-write-our-deploy-scripts} + +اب جب کہ ہمارا کنٹریکٹ لکھا جا چکا ہے اور ہماری کنفیگریشن فائل تیار ہے، اب وقت آگیا ہے کہ ہم اپنی کنٹریکٹ ڈیپلوئے اسکرپٹ لکھیں۔ + +`scripts/` فولڈر پر جائیں اور `deploy.js` نامی ایک نئی فائل بنائیں، اس میں درج ذیل مواد شامل کریں: + +``` +async function main() { + const HelloWorld = await ethers.getContractFactory("HelloWorld"); + + // ڈیپلائمنٹ شروع کریں، ایک پرومس واپس کرتا ہے جو ایک کنٹریکٹ آبجیکٹ میں ریزولو ہوتا ہے + const hello_world = await HelloWorld.deploy("Hello World!"); + console.log("Contract deployed to address:", hello_world.address);} + +main() + .then(() => process.exit(0)) + .catch(error => { + console.error(error); + process.exit(1); + }); +``` + +Hardhat اپنے [کنٹریکٹس ٹیوٹوریل](https://hardhat.org/tutorial/testing-contracts.html#writing-tests) میں بہت اچھی طرح سے وضاحت کرتا ہے کہ کوڈ کی یہ ہر لائن کیا کرتی ہے، ہم نے یہاں ان کی وضاحتیں اپنائی ہیں۔ + +``` +const HelloWorld = await ethers.getContractFactory("HelloWorld"); +``` + +ethers.js میں ایک `ContractFactory` ایک ابسٹریکشن ہے جو نئے اسمارٹ کنٹریکٹس کو ڈیپلائے کرنے کے لیے استعمال ہوتی ہے، لہذا یہاں `HelloWorld` ہمارے ہیلو ورلڈ کنٹریکٹ کی مثالوں کے لیے ایک فیکٹری ہے۔ `hardhat-ethers` پلگ ان کا استعمال کرتے وقت `ContractFactory` اور `Contract` کی مثالیں پہلے دستخط کنندہ سے بطور ڈیفالٹ جڑی ہوتی ہیں۔ + +``` +const hello_world = await HelloWorld.deploy(); +``` + +ایک `ContractFactory` پر `deploy()` کو کال کرنے سے ڈیپلائمنٹ شروع ہو جائے گی، اور ایک `Promise` واپس آئے گا جو ایک `Contract` میں ریزولو ہوتا ہے۔ یہ وہ آبجیکٹ ہے جس میں ہمارے ہر اسمارٹ کنٹریکٹ فنکشن کے لیے ایک طریقہ ہے۔ + +## مرحلہ 16: ہمارا کنٹریکٹ ڈیپلائے کریں {#step-16-deploy-our-contract} + +ہم آخر کار اپنے اسمارٹ کنٹریکٹ کو ڈیپلوئے کرنے کے لیے تیار ہیں! کمانڈ لائن پر جائیں اور چلائیں: + +``` +npx hardhat run scripts/deploy.js --network sepolia +``` + +پھر آپ کو کچھ اس طرح نظر آنا چاہیے: + +``` +کنٹریکٹ اس ایڈریس پر ڈیپلائے کیا گیا: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 +``` + +اگر ہم [Sepolia etherscan](https://sepolia.etherscan.io/) پر جائیں اور اپنے کنٹریکٹ ایڈریس کو تلاش کریں تو ہمیں یہ دیکھنے کے قابل ہونا چاہیے کہ یہ کامیابی سے ڈیپلائے ہو گیا ہے۔ ٹرانزیکشن کچھ اس طرح نظر آئے گی: + +![etherscan contract](./etherscan-contract.png) + +`From` ایڈریس آپ کے MetaMask اکاؤنٹ کے ایڈریس سے مماثل ہونا چاہیے اور To ایڈریس پر ”Contract Creation“ لکھا ہوگا لیکن اگر ہم ٹرانزیکشن میں کلک کریں گے تو ہمیں `To` فیلڈ میں اپنا کنٹریکٹ ایڈریس نظر آئے گا: + +![etherscan transaction](./etherscan-transaction.png) + +مبارک ہو! آپ نے ابھی Ethereum چین پر ایک اسمارٹ کنٹریکٹ ڈیپلائے کیا ہے 🎉 + +یہ سمجھنے کے لیے کہ پس پردہ کیا ہو رہا ہے، آئیے اپنے [Alchemy ڈیش بورڈ](https://dashboard.alchemyapi.io/explorer) میں ایکسپلورر ٹیب پر جائیں۔ اگر آپ کے پاس متعدد Alchemy ایپس ہیں تو ایپ کے لحاظ سے فلٹر کرنا اور ”Hello World“ کو منتخب کرنا یقینی بنائیں۔ +![hello world explorer](./hello-world-explorer.png) + +یہاں آپ کو مٹھی بھر JSON-RPC کالز نظر آئیں گی جو Hardhat/Ethers نے ہمارے لیے پس پردہ کی تھیں جب ہم نے `.deploy()` فنکشن کو کال کیا تھا۔ یہاں دو اہم کالز ہیں [`eth_sendRawTransaction`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-send-raw-transaction)، جو دراصل ہمارے کنٹریکٹ کو Sepolia چین پر لکھنے کی درخواست ہے، اور [`eth_getTransactionByHash`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-get-transaction-by-hash) جو ہیش دیے جانے پر ہمارے ٹرانزیکشن کے بارے میں معلومات پڑھنے کی درخواست ہے (ٹرانزیکشنز کے وقت ایک عام پیٹرن)۔ ٹرانزیکشنز بھیجنے کے بارے میں مزید جاننے کے لیے، [Web3 اور Alchemy کا استعمال کرتے ہوئے ٹرانزیکشنز بھیجنے](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) پر یہ ٹیوٹوریل دیکھیں۔ + +اس ٹیوٹوریل کے حصہ 1 کے لیے بس اتنا ہی، حصہ 2 میں ہم اصل میں [اپنے اسمارٹ کنٹریکٹ کے ساتھ انٹریکٹ کریں گے](https://www.alchemy.com/docs/interacting-with-a-smart-contract) اپنے ابتدائی پیغام کو اپ ڈیٹ کرکے، اور حصہ 3 میں ہم [اپنے اسمارٹ کنٹریکٹ کو Etherscan پر پبلش کریں گے](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) تاکہ ہر کوئی جان سکے کہ اس کے ساتھ کیسے انٹریکٹ کرنا ہے۔ + +**Alchemy کے بارے میں مزید جاننا چاہتے ہیں؟ ہماری [ویب سائٹ](https://www.alchemy.com/eth) دیکھیں۔ کبھی بھی کوئی اپ ڈیٹ مس نہیں کرنا چاہتے؟ ہمارے نیوز لیٹر کو [یہاں](https://www.alchemy.com/newsletter) سبسکرائب کریں! ہمارے [Discord](https://discord.gg/u72VCg3) میں بھی شامل ہونا یقینی بنائیں۔**۔ diff --git a/public/content/translations/ur/developers/tutorials/how-to-implement-an-erc721-market/index.md b/public/content/translations/ur/developers/tutorials/how-to-implement-an-erc721-market/index.md new file mode 100644 index 00000000000..630e11769de --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-implement-an-erc721-market/index.md @@ -0,0 +1,145 @@ +--- +title: "ERC-721 مارکیٹ کو کیسے نافذ کریں" +description: "ایک غیر مرکزی کلاسیفائیڈ بورڈ پر ٹوکنائزڈ آئٹمز کو فروخت کے لیے کیسے پیش کریں" +author: "Alberto Cuesta Cañada" +tags: [ "اسمارٹ معاہدات", "erc-721", "solidity", "tokens" ] +skill: intermediate +lang: ur-in +published: 2020-03-19 +source: Hackernoon +sourceUrl: https://hackernoon.com/how-to-implement-an-erc721-market-1e1a32j9 +--- + +اس مضمون میں، میں آپ کو دکھانے جا رہا ہوں کہ Ethereum بلاک چین کے لیے Craigslist کو کیسے کوڈ کیا جائے۔ + +Gumtree، Ebay اور Craigslist سے پہلے، کلاسیفائیڈ بورڈز زیادہ تر کارک یا کاغذ کے بنے ہوتے تھے۔ اسکول کی راہداریوں، اخبارات، اسٹریٹ لائٹس، اور اسٹور فرنٹ پر کلاسیفائیڈ بورڈز لگے ہوتے تھے۔ + +انٹرنیٹ کے آنے سے یہ سب کچھ بدل گیا۔ ایک مخصوص کلاسیفائیڈ بورڈ کو دیکھنے والے لوگوں کی تعداد کئی گنا بڑھ گئی۔ اس کے ساتھ، وہ بازار جن کی وہ نمائندگی کرتے تھے، بہت زیادہ موثر ہو گئے اور عالمی سطح تک پھیل گئے۔ Ebay ایک بہت بڑا کاروبار ہے جس کی ابتدا ان فزیکل کلاسیفائیڈ بورڈز سے ہوتی ہے۔ + +بلاک چین کے ساتھ یہ بازار ایک بار پھر بدلنے کے لیے تیار ہیں، میں آپ کو دکھاتا ہوں کہ کیسے۔ + +## منیٹائزیشن {#monetization} + +ایک عوامی بلاک چین کلاسیفائیڈ بورڈ کے کاروباری ماڈل کو Ebay اور کمپنی کے ماڈل سے مختلف ہونا پڑے گا۔ + +سب سے پہلے، [غیر مرکزیت کا زاویہ](/developers/docs/web2-vs-web3/) ہے۔ موجودہ پلیٹ فارمز کو اپنے سرورز کو برقرار رکھنے کی ضرورت ہوتی ہے۔ ایک غیر مرکزی پلیٹ فارم کو اس کے صارفین کے ذریعے برقرار رکھا جاتا ہے، اس لیے بنیادی پلیٹ فارم کو چلانے کی لاگت پلیٹ فارم کے مالک کے لیے صفر ہو جاتی ہے۔ + +پھر فرنٹ اینڈ ہے، یعنی وہ ویب سائٹ یا انٹرفیس جو پلیٹ فارم تک رسائی فراہم کرتا ہے۔ یہاں بہت سے اختیارات ہیں۔ پلیٹ فارم کے مالکان رسائی کو محدود کر سکتے ہیں اور ہر کسی کو اپنا انٹرفیس استعمال کرنے پر مجبور کر سکتے ہیں، جس کے لیے وہ ایک فیس وصول کرتے ہیں۔ پلیٹ فارم کے مالکان رسائی کو کھلا رکھنے کا فیصلہ بھی کر سکتے ہیں (طاقت عوام کے ہاتھ میں!) اور کسی کو بھی پلیٹ فارم کے لیے انٹرفیس بنانے کی اجازت دے سکتے ہیں۔ یا مالکان ان انتہاؤں کے درمیان کوئی بھی طریقہ اختیار کرنے کا فیصلہ کر سکتے ہیں۔ + +_مجھ سے زیادہ وژن رکھنے والے کاروباری رہنما یہ جانتے ہوں گے کہ اسے کیسے منیٹائز کیا جائے۔_ _میں صرف یہ دیکھتا ہوں کہ یہ موجودہ صورتحال سے مختلف ہے اور شاید منافع بخش بھی ہے۔_ + +مزید برآں، آٹومیشن اور ادائیگیوں کا زاویہ بھی ہے۔ کچھ چیزوں کو بہت [مؤثر طریقے سے ٹوکنائزڈ](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) کیا جا سکتا ہے اور ایک کلاسیفائیڈ بورڈ پر ان کی تجارت کی جا سکتی ہے۔ ٹوکنائزڈ اثاثوں کو بلاک چین میں آسانی سے منتقل کیا جا سکتا ہے۔ انتہائی پیچیدہ ادائیگی کے طریقوں کو بلاک چین میں آسانی سے نافذ کیا جا سکتا ہے۔ + +مجھے یہاں کاروبار کا ایک موقع نظر آ رہا ہے۔ بغیر کسی چلانے کی لاگت والا ایک کلاسیفائیڈ بورڈ آسانی سے نافذ کیا جا سکتا ہے، جس میں ہر لین دین میں پیچیدہ ادائیگی کے راستے شامل ہوں۔ مجھے یقین ہے کہ کوئی نہ کوئی اس بارے میں ایک خیال لے کر آئے گا کہ اسے کس لیے استعمال کیا جائے۔ + +میں تو بس اسے بنا کر خوش ہوں۔ آئیے کوڈ پر ایک نظر ڈالتے ہیں۔ + +## عمل درآمد {#implementation} + +کچھ عرصہ پہلے ہم نے کاروباری کیس کی مثالوں کے نفاذ اور دیگر اچھی چیزوں کے ساتھ ایک [اوپن سورس ریپوزٹری](https://github.com/HQ20/contracts?ref=hackernoon.com) شروع کی تھی، براہ کرم اس پر ایک نظر ڈالیں۔ + +اس [Ethereum کلاسیفائیڈز بورڈ](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) کا کوڈ وہیں ہے، براہ کرم اسے استعمال کریں اور اس کا بھرپور فائدہ اٹھائیں۔ بس اس بات سے آگاہ رہیں کہ کوڈ کا آڈٹ نہیں کیا گیا ہے اور اس میں پیسہ لگانے سے پہلے آپ کو اپنی خود کی جانچ پڑتال کرنے کی ضرورت ہے۔ + +بورڈ کی بنیادی باتیں پیچیدہ نہیں ہیں۔ بورڈ میں موجود تمام اشتہارات صرف چند فیلڈز کے ساتھ ایک اسٹرکٹ ہوں گے: + +```solidity +struct Trade { + address poster; + uint256 item; + uint256 price; + bytes32 status; // کھلا، عملدرآمد، منسوخ +} +``` + +تو کوئی ہے جو اشتہار پوسٹ کر رہا ہے۔ فروخت کے لیے ایک آئٹم۔ آئٹم کی قیمت۔ ٹریڈ کی حیثیت جو کہ کھلی، عملدرآمد شدہ یا منسوخ ہو سکتی ہے۔ + +یہ تمام ٹریڈز ایک میپنگ میں رکھے جائیں گے۔ کیونکہ Solidity میں ہر چیز ایک میپنگ ہی لگتی ہے۔ اس لیے بھی کہ یہ آسان ہے۔ + +```solidity +mapping(uint256 => Trade) public trades; +``` + +میپنگ کا استعمال کرنے کا صرف یہ مطلب ہے کہ ہمیں ہر اشتہار کو پوسٹ کرنے سے پہلے اس کے لیے ایک آئی ڈی بنانی ہوگی، اور اس پر کام کرنے سے پہلے ہمیں اشتہار کی آئی ڈی جاننے کی ضرورت ہوگی۔ اس سے نمٹنے کے متعدد طریقے ہیں، چاہے وہ اسمارٹ کنٹریکٹ میں ہوں یا فرنٹ اینڈ میں۔ اگر آپ کو کچھ اشارے چاہئیں تو براہ کرم پوچھیں۔ + +اگلا سوال یہ پیدا ہوتا ہے کہ وہ کون سی اشیاء ہیں جن کا ہم لین دین کرتے ہیں، اور وہ کون سی کرنسی ہے جو لین دین کی ادائیگی کے لیے استعمال ہوتی ہے۔ + +آئٹمز کے لیے، ہم صرف یہ مطالبہ کرنے جا رہے ہیں کہ وہ [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com) انٹرفیس کو نافذ کریں، جو واقعی بلاک چین میں حقیقی دنیا کی اشیاء کی نمائندگی کرنے کا ایک طریقہ ہے، حالانکہ یہ [ڈیجیٹل اثاثوں کے ساتھ بہترین کام کرتا ہے](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com)۔ ہم کنسٹرکٹر میں اپنے ERC721 کنٹریکٹ کی وضاحت کرنے جا رہے ہیں، جس کا مطلب ہے کہ ہمارے کلاسیفائیڈ بورڈ میں موجود کسی بھی اثاثے کو پہلے سے ٹوکنائزڈ ہونا ضروری ہے۔ + +ادائیگیوں کے لیے، ہم کچھ ایسا ہی کرنے جا رہے ہیں۔ زیادہ تر بلاک چین پروجیکٹس اپنی خود کی [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com) کرپٹو کرنسی کی وضاحت کرتے ہیں۔ کچھ دوسرے DAI جیسی مرکزی دھارے کی کرنسی کا استعمال کرنا پسند کرتے ہیں۔ اس کلاسیفائیڈ بورڈ میں، آپ کو صرف تعمیر کے وقت یہ فیصلہ کرنا ہوگا کہ آپ کی کرنسی کیا ہوگی۔ آسان ہے۔ + +```solidity +constructor ( + address _currencyTokenAddress, address _itemTokenAddress +) public { + currencyToken = IERC20(_currencyTokenAddress); + itemToken = IERC721(_itemTokenAddress); + tradeCounter = 0; +} +``` + +ہم وہاں پہنچ رہے ہیں۔ ہمارے پاس اشتہارات، تجارت کے لیے آئٹمز اور ادائیگیوں کے لیے ایک کرنسی ہے۔ اشتہار بنانے کا مطلب ہے کسی آئٹم کو ایسکرو میں رکھنا تاکہ یہ دکھایا جا سکے کہ آپ کے پاس وہ آئٹم ہے اور آپ نے اسے دو بار پوسٹ نہیں کیا ہے، ممکنہ طور پر کسی مختلف بورڈ پر۔ + +نیچے دیا گیا کوڈ بالکل یہی کرتا ہے۔ آئٹم کو ایسکرو میں رکھتا ہے، اشتہار بناتا ہے، کچھ ہاؤس کیپنگ کرتا ہے۔ + +```solidity +function openTrade(uint256 _item, uint256 _price) + public +{ + itemToken.transferFrom(msg.sender, address(this), _item); + trades[tradeCounter] = Trade({ + poster: msg.sender, + item: _item, + price: _price, + status: "Open" + }); + tradeCounter += 1; + emit TradeStatusChange(tradeCounter - 1, "Open"); +} +``` + +ٹریڈ کو قبول کرنے کا مطلب ہے ایک اشتہار (ٹریڈ) کا انتخاب کرنا، قیمت ادا کرنا، اور آئٹم وصول کرنا۔ نیچے دیا گیا کوڈ ایک ٹریڈ کو بازیافت کرتا ہے۔ یہ چیک کرتا ہے کہ آیا یہ دستیاب ہے۔ آئٹم کی قیمت ادا کرتا ہے۔ آئٹم کو بازیافت کرتا ہے۔ اشتہار کو اپ ڈیٹ کرتا ہے۔ + +```solidity +function executeTrade(uint256 _trade) + public +{ + Trade memory trade = trades[_trade]; + require(trade.status == "Open", "ٹریڈ کھلی نہیں ہے۔"); + currencyToken.transferFrom(msg.sender, trade.poster, trade.price); + itemToken.transferFrom(address(this), msg.sender, trade.item); + trades[_trade].status = "Executed"; + emit TradeStatusChange(_trade, "Executed"); +} +``` + +آخر میں، ہمارے پاس بیچنے والوں کے لیے ایک آپشن ہے کہ وہ کسی خریدار کے قبول کرنے سے پہلے ٹریڈ سے پیچھے ہٹ سکتے ہیں۔ کچھ ماڈلز میں، اشتہارات ختم ہونے سے پہلے ایک مدت کے لیے لائیو رہتے ہیں۔ یہ آپ کی پسند ہے، جو آپ کے بازار کے ڈیزائن پر منحصر ہے۔ + +یہ کوڈ ٹریڈ کو انجام دینے کے لیے استعمال ہونے والے کوڈ سے بہت ملتا جلتا ہے، صرف اتنا فرق ہے کہ اس میں کرنسی کا تبادلہ نہیں ہوتا اور آئٹم اشتہار پوسٹ کرنے والے کے پاس واپس چلا جاتا ہے۔ + +```solidity +function cancelTrade(uint256 _trade) + public +{ + Trade memory trade = trades[_trade]; + require( + msg.sender == trade.poster, + "ٹریڈ کو صرف پوسٹر ہی منسوخ کر سکتا ہے۔" + ); + require(trade.status == "Open", "ٹریڈ کھلی نہیں ہے۔"); + itemToken.transferFrom(address(this), trade.poster, trade.item); + trades[_trade].status = "Cancelled"; + emit TradeStatusChange(_trade, "Cancelled"); +} +``` + +بس یہی ہے۔ آپ نفاذ کے اختتام تک پہنچ گئے ہیں۔ یہ کافی حیران کن ہے کہ کچھ کاروباری تصورات کوڈ میں ظاہر ہونے پر کتنے جامع ہوتے ہیں، اور یہ ان میں سے ایک معاملہ ہے۔ مکمل کنٹریکٹ کو [ہمارے ریپو میں](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol) چیک کریں۔ + +## نتیجہ {#conclusion} + +کلاسیفائیڈ بورڈز ایک عام مارکیٹ کنفیگریشن ہیں جو انٹرنیٹ کے ساتھ بڑے پیمانے پر پھیلے، اور چند اجارہ دار فاتحین کے ساتھ ایک بہت مقبول کاروباری ماڈل بن گئے۔ + +کلاسیفائیڈ بورڈز ایک بلاک چین ماحول میں نقل کرنے کے لیے ایک آسان ٹول بھی ہیں، جن میں بہت مخصوص خصوصیات ہیں جو موجودہ بڑے اداروں کے لیے ایک چیلنج کو ممکن بنائیں گی۔ + +اس مضمون میں، میں نے ایک کلاسیفائیڈ بورڈ کاروبار کی کاروباری حقیقت اور تکنیکی نفاذ کے درمیان ایک پل بنانے کی کوشش کی ہے۔ اگر آپ کے پاس صحیح مہارتیں ہیں تو یہ علم آپ کو نفاذ کے لیے ایک وژن اور روڈ میپ بنانے میں مدد کرے گا۔ + +ہمیشہ کی طرح، اگر آپ کچھ دلچسپ بنانے جا رہے ہیں اور کچھ مشورہ چاہتے ہیں، تو براہ کرم [مجھ سے رابطہ کریں](https://albertocuesta.es/)! مجھے مدد کرنے میں ہمیشہ خوشی ہوتی ہے۔ diff --git a/public/content/translations/ur/developers/tutorials/how-to-mint-an-nft/index.md b/public/content/translations/ur/developers/tutorials/how-to-mint-an-nft/index.md new file mode 100644 index 00000000000..acab008787e --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-mint-an-nft/index.md @@ -0,0 +1,329 @@ +--- +title: "NFT کیسے منٹ کریں (NFT ٹیوٹوریل سیریز کا حصہ 2/3)" +description: "اس ٹیوٹوریل میں بتایا گیا ہے کہ ہمارے اسمارٹ کنٹریکٹ اور Web3 کا استعمال کرتے ہوئے Ethereum بلاک چین پر NFT کیسے منٹ کیا جائے۔" +author: "Sumi Mudgil" +tags: [ "ERC-721", "alchemy", "solidity", "اسمارٹ معاہدات" ] +skill: beginner +lang: ur-in +published: 2021-04-22 +--- + +[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): $69 ملین +[3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): $11 ملین +[Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): $6 ملین + +ان سبھی نے Alchemy کے طاقتور API کا استعمال کرتے ہوئے اپنے NFTs منٹ کیے۔ اس ٹیوٹوریل میں، ہم آپ کو سکھائیں گے کہ یہی کام \<10 منٹ سے کم میں کیسے کیا جائے۔ + +”NFT منٹ کرنا“ بلاک چین پر آپ کے ERC-721 ٹوکن کا ایک منفرد انسٹینس شائع کرنے کا عمل ہے۔ [اس NFT ٹیوٹوریل سیریز کے حصہ 1](/developers/tutorials/how-to-write-and-deploy-an-nft/) سے ہمارے اسمارٹ کنٹریکٹ کا استعمال کرتے ہوئے، آئیے اپنی Web3 کی مہارتوں کا مظاہرہ کریں اور ایک NFT منٹ کریں۔ اس ٹیوٹوریل کے آخر میں، آپ اتنے NFTs منٹ کر سکیں گے جتنے آپ کا دل (اور والیٹ) چاہے! + +آئیں شروع کرتے ہیں! + +## مرحلہ 1: Web3 انسٹال کریں {#install-web3} + +اگر آپ نے اپنا NFT اسمارٹ کنٹریکٹ بنانے کے پہلے ٹیوٹوریل پر عمل کیا ہے، تو آپ کو پہلے سے ہی Ethers.js استعمال کرنے کا تجربہ ہے۔ Web3 بھی Ethers کی طرح ہی ہے، کیونکہ یہ ایک لائبریری ہے جو Ethereum بلاک چین کو درخواستیں بھیجنا آسان بنانے کے لیے استعمال ہوتی ہے۔ اس ٹیوٹوریل میں ہم [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3) کا استعمال کریں گے، جو ایک بہتر Web3 لائبریری ہے جو خودکار ری ٹرائی اور مضبوط WebSocket سپورٹ پیش کرتی ہے۔ + +اپنی پروجیکٹ ہوم ڈائریکٹری میں چلائیں: + +``` +npm install @alch/alchemy-web3 +``` + +## مرحلہ 2: ایک `mint-nft.js` فائل بنائیں {#create-mintnftjs} + +اپنی اسکرپٹس ڈائریکٹری کے اندر، ایک `mint-nft.js` فائل بنائیں اور کوڈ کی درج ذیل لائنیں شامل کریں: + +```js +require("dotenv").config() +const API_URL = process.env.API_URL +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(API_URL) +``` + +## مرحلہ 3: اپنے کنٹریکٹ کا ABI حاصل کریں {#contract-abi} + +ہمارا کنٹریکٹ ABI (ایپلی کیشن بائنری انٹرفیس) ہمارے اسمارٹ کنٹریکٹ کے ساتھ تعامل کرنے کا انٹرفیس ہے۔ آپ کنٹریکٹ ABIs کے بارے میں مزید [یہاں](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is) جان سکتے ہیں۔ Hardhat ہمارے لیے خود بخود ایک ABI بناتا ہے اور اسے `MyNFT.json` فائل میں محفوظ کرتا ہے۔ اسے استعمال کرنے کے لیے ہمیں اپنی `mint-nft.js` فائل میں کوڈ کی درج ذیل لائنیں شامل کرکے مواد کو پارس کرنا ہوگا۔ + +```js +const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json") +``` + +اگر آپ ABI دیکھنا چاہتے ہیں تو آپ اسے اپنے کنسول پر پرنٹ کر سکتے ہیں: + +```js +console.log(JSON.stringify(contract.abi)) +``` + +`mint-nft.js` چلانے اور اپنے ABI کو کنسول پر پرنٹ ہوتے دیکھنے کے لیے اپنے ٹرمینل پر جائیں اور چلائیں: + +```js +node scripts/mint-nft.js +``` + +## مرحلہ 4: IPFS کا استعمال کرتے ہوئے اپنے NFT کے لیے میٹا ڈیٹا کنفیگر کریں {#config-meta} + +اگر آپ کو حصہ 1 میں ہمارے ٹیوٹوریل سے یاد ہو، تو ہمارا `mintNFT` اسمارٹ کنٹریکٹ فنکشن ایک tokenURI پیرامیٹر لیتا ہے جسے NFT کے میٹا ڈیٹا کی وضاحت کرنے والے JSON دستاویز میں حل ہونا چاہیے— جو واقعی NFT کو زندہ کرتا ہے، جس سے اس میں قابلِ ترتیب خصوصیات جیسے نام، تفصیل، تصویر اور دیگر صفات شامل ہو سکتے ہیں۔ + +> _انٹرپلینیٹری فائل سسٹم (IPFS) تقسیم شدہ فائل سسٹم میں ڈیٹا کو اسٹور اور شیئر کرنے کے لیے ایک غیر مرکزی پروٹوکول اور پیئر ٹو پیئر نیٹ ورک ہے۔_ + +ہم اپنے NFT اثاثے اور میٹا ڈیٹا کو ذخیرہ کرنے کے لیے Pinata، ایک آسان IPFS API اور ٹول کٹ، کا استعمال کریں گے تاکہ یہ یقینی بنایا جا سکے کہ ہمارا NFT واقعی غیر مرکزی ہے۔ اگر آپ کا Pinata اکاؤنٹ نہیں ہے، تو [یہاں](https://app.pinata.cloud) ایک مفت اکاؤنٹ کے لیے سائن اپ کریں اور اپنی ای میل کی توثیق کرنے کے اقدامات مکمل کریں۔ + +ایک بار جب آپ اکاؤنٹ بنا لیں: + +- ”فائلز“ پیج پر جائیں اور صفحہ کے اوپر بائیں جانب نیلے "اپ لوڈ" بٹن پر کلک کریں۔ + +- Pinata پر ایک تصویر اپ لوڈ کریں — یہ آپ کے NFT کے لیے تصویری اثاثہ ہوگا۔ آپ اثاثے کو جو چاہیں نام دے سکتے ہیں + +- اپ لوڈ کرنے کے بعد، آپ کو "فائلز" پیج پر ٹیبل میں فائل کی معلومات نظر آئیں گی۔ آپ کو ایک CID کالم بھی نظر آئے گا۔ آپ اس کے ساتھ والے کاپی بٹن پر کلک کرکے CID کو کاپی کر سکتے ہیں۔ آپ اپنا اپ لوڈ یہاں دیکھ سکتے ہیں: `https://gateway.pinata.cloud/ipfs/`۔ مثال کے طور پر، آپ IPFS پر ہمارے ذریعہ استعمال کردہ تصویر کو [یہاں](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5) تلاش کر سکتے ہیں۔ + +زیادہ بصری سیکھنے والوں کے لیے، اوپر دیے گئے اقدامات کا خلاصہ یہاں دیا گیا ہے: + +![Pinata پر اپنی تصویر کیسے اپ لوڈ کریں](./instructionsPinata.gif) + +اب، ہم Pinata پر ایک اور دستاویز اپ لوڈ کرنا چاہیں گے۔ لیکن ایسا کرنے سے پہلے، ہمیں اسے بنانا ہوگا! + +اپنی روٹ ڈائریکٹری میں، `nft-metadata.json` نامی ایک نئی فائل بنائیں اور درج ذیل json کوڈ شامل کریں: + +```json +{ + "attributes": [ + { + "trait_type": "نسل", + "value": "مالٹیپو" + }, + { + "trait_type": "آنکھوں کا رنگ", + "value": "موکا" + } + ], + "description": "دنیا کا سب سے پیارا اور حساس پپی۔", + "image": "ipfs://QmWmvTJmJU3pozR9ZHFmQC2DNDwi2XJtf3QGyYiiagFSWb", + "name": "ریمسیز" +} +``` + +آپ json میں ڈیٹا تبدیل کرنے کے لیے آزاد ہیں۔ آپ صفات کے سیکشن سے ہٹا سکتے ہیں یا اس میں اضافہ کر سکتے ہیں۔ سب سے اہم بات، یقینی بنائیں کہ تصویر کا فیلڈ آپ کی IPFS تصویر کے مقام کی طرف اشارہ کرتا ہے — ورنہ، آپ کے NFT میں ایک (بہت پیارے!) کی تصویر شامل ہوگی کتے کی۔ + +ایک بار جب آپ JSON فائل کی ترمیم مکمل کر لیں، تو اسے محفوظ کریں اور Pinata پر اپ لوڈ کریں، اسی طرح کے اقدامات پر عمل کرتے ہوئے جو ہم نے تصویر اپ لوڈ کرنے کے لیے کیے تھے۔ + +![Pinata پر اپنی nft-metadata.json کیسے اپ لوڈ کریں](./uploadPinata.gif) + +## مرحلہ 5: اپنے کنٹریکٹ کا ایک انسٹینس بنائیں {#instance-contract} + +اب، اپنے کنٹریکٹ کے ساتھ تعامل کرنے کے لیے، ہمیں اپنے کوڈ میں اس کا ایک انسٹینس بنانا ہوگا۔ ایسا کرنے کے لیے ہمیں اپنے کنٹریکٹ ایڈریس کی ضرورت ہوگی جسے ہم ڈیپلائمنٹ یا [Blockscout](https://eth-sepolia.blockscout.com/) سے اس ایڈریس کو تلاش کرکے حاصل کر سکتے ہیں جسے آپ نے کنٹریکٹ ڈیپلائے کرنے کے لیے استعمال کیا تھا۔ + +![Etherscan پر اپنا کنٹریکٹ ایڈریس دیکھیں](./view-contract-etherscan.png) + +مندرجہ بالا مثال میں، ہمارا کنٹریکٹ ایڈریس 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778 ہے۔ + +اگلا ہم ABI اور ایڈریس کا استعمال کرکے اپنا کنٹریکٹ بنانے کے لیے Web3 [کنٹریکٹ میتھڈ](https://docs.web3js.org/api/web3-eth-contract/class/Contract) کا استعمال کریں گے۔ اپنی `mint-nft.js` فائل میں، درج ذیل شامل کریں: + +```js +const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" + +const nftContract = new web3.eth.Contract(contract.abi, contractAddress) +``` + +## مرحلہ 6: `.env` فائل کو اپ ڈیٹ کریں {#update-env} + +اب، Ethereum چین پر ٹرانزیکشنز بنانے اور بھیجنے کے لیے، ہم اکاؤنٹ نانس حاصل کرنے کے لیے آپ کے عوامی Ethereum اکاؤنٹ ایڈریس کا استعمال کریں گے (نیچے وضاحت کی جائے گی)۔ + +اپنی پبلک کی کو اپنی `.env` فائل میں شامل کریں — اگر آپ نے ٹیوٹوریل کا حصہ 1 مکمل کر لیا ہے، تو ہماری `.env` فائل اب کچھ اس طرح نظر آنی چاہیے: + +```js +API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key" +PRIVATE_KEY = "your-private-account-address" +PUBLIC_KEY = "your-public-account-address" +``` + +## مرحلہ 7: اپنی ٹرانزیکشن بنائیں {#create-txn} + +سب سے پہلے، آئیے `mintNFT(tokenData)` نامی ایک فنکشن کی وضاحت کریں اور درج ذیل کام کرکے اپنی ٹرانزیکشن بنائیں: + +1. `.env` فائل سے اپنی _PRIVATE_KEY_ اور _PUBLIC_KEY_ حاصل کریں۔ + +2. اگلا، ہمیں اکاؤنٹ نانس کا پتہ لگانے کی ضرورت ہوگی۔ نانس کی تفصیلات آپ کے ایڈریس سے بھیجی گئی ٹرانزیکشنز کی تعداد پر نظر رکھنے کے لیے استعمال ہوتی ہیں — جس کی ہمیں سیکیورٹی مقاصد اور [ری پلے حملوں](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce) کو روکنے کے لیے ضرورت ہے۔ اپنے ایڈریس سے بھیجی گئی ٹرانزیکشنز کی تعداد حاصل کرنے کے لیے، ہم [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount) کا استعمال کرتے ہیں۔ + +3. آخر میں ہم درج ذیل معلومات کے ساتھ اپنی ٹرانزیکشن ترتیب دیں گے: + +- `'from': PUBLIC_KEY` — ہماری ٹرانزیکشن کا ماخذ ہمارا پبلک ایڈریس ہے + +- `'to': contractAddress` — وہ کنٹریکٹ جس کے ساتھ ہم تعامل کرنا اور ٹرانزیکشن بھیجنا چاہتے ہیں + +- `'nonce': nonce` — ہمارے ایڈریس سے بھیجی گئی ٹرانزیکشنز کی تعداد کے ساتھ اکاؤنٹ نانس + +- `'gas': estimatedGas` — ٹرانزیکشن مکمل کرنے کے لیے درکار تخمینہ شدہ گیس + +- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — وہ حساب جو ہم اس ٹرانزیکشن میں انجام دینا چاہتے ہیں — جو اس معاملے میں ایک NFT منٹ کرنا ہے + +آپ کی `mint-nft.js` فائل اب اس طرح نظر آنی چاہیے: + +```js + require('dotenv').config(); + const API_URL = process.env.API_URL; + const PUBLIC_KEY = process.env.PUBLIC_KEY; + const PRIVATE_KEY = process.env.PRIVATE_KEY; + + const { createAlchemyWeb3 } = require("@alch/alchemy-web3"); + const web3 = createAlchemyWeb3(API_URL); + + const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json"); + const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"; + const nftContract = new web3.eth.Contract(contract.abi, contractAddress); + + async function mintNFT(tokenURI) { + const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); // تازہ ترین نانس حاصل کریں + + // ٹرانزیکشن + const tx = { + 'from': PUBLIC_KEY, + 'to': contractAddress, + 'nonce': nonce, + 'gas': 500000, + 'data': nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI() + }; + }​ +``` + +## مرحلہ 8: ٹرانزیکشن پر دستخط کریں {#sign-txn} + +اب جب کہ ہم نے اپنی ٹرانزیکشن بنا لی ہے، ہمیں اسے بھیجنے کے لیے اس پر دستخط کرنے کی ضرورت ہے۔ یہ وہ جگہ ہے جہاں ہم اپنی پرائیویٹ کی کا استعمال کریں گے۔ + +`web3.eth.sendSignedTransaction` ہمیں ٹرانزیکشن ہیش دے گا، جسے ہم یہ یقینی بنانے کے لیے استعمال کر سکتے ہیں کہ ہماری ٹرانزیکشن مائن ہو گئی ہے اور نیٹ ورک کے ذریعے ڈراپ نہیں ہوئی ہے۔ آپ دیکھیں گے کہ ٹرانزیکشن پر دستخط کرنے والے سیکشن میں، ہم نے کچھ ایرر چیکنگ شامل کی ہے تاکہ ہمیں معلوم ہو کہ ہماری ٹرانزیکشن کامیابی سے گزر گئی ہے یا نہیں۔ + +```js +require("dotenv").config() +const API_URL = process.env.API_URL +const PUBLIC_KEY = process.env.PUBLIC_KEY +const PRIVATE_KEY = process.env.PRIVATE_KEY + +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(API_URL) + +const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json") +const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" +const nftContract = new web3.eth.Contract(contract.abi, contractAddress) + +async function mintNFT(tokenURI) { + const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") // تازہ ترین نانس حاصل کریں + + // ٹرانزیکشن + const tx = { + from: PUBLIC_KEY, + to: contractAddress, + nonce: nonce, + gas: 500000, + data: nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI(), + } + + const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY) + signPromise + .then((signedTx) => { + web3.eth.sendSignedTransaction( + signedTx.rawTransaction, + function (err, hash) { + if (!err) { + console.log( + "آپ کی ٹرانزیکشن کا ہیش ہے: ", + hash, + "\nاپنی ٹرانزیکشن کی حیثیت دیکھنے کے لیے Alchemy's Mempool کو چیک کریں!" + ) + } else { + console.log( + "آپ کی ٹرانزیکشن جمع کرتے وقت کچھ غلط ہو گیا:", + err + ) + } + } + ) + }) + .catch((err) => { + console.log(" وعدہ ناکام رہا:", err) + }) +} +``` + +## مرحلہ 9: `mintNFT` کو کال کریں اور node `mint-nft.js` چلائیں {#call-mintnft-fn} + +کیا آپ کو وہ `metadata.json` یاد ہے جسے آپ نے Pinata پر اپ لوڈ کیا تھا؟ Pinata سے اس کا ہیش کوڈ حاصل کریں اور `mintNFT` فنکشن میں پیرامیٹر کے طور پر درج ذیل کو پاس کریں `https://gateway.pinata.cloud/ipfs/` + +ہیش کوڈ حاصل کرنے کا طریقہ یہاں ہے: + +![Pinata پر اپنے nft میٹا ڈیٹا کا ہیش کوڈ کیسے حاصل کریں](./metadataPinata.gif)_Pinata پر اپنے nft میٹا ڈیٹا کا ہیش کوڈ کیسے حاصل کریں_ + +> اس بات کو یقینی بنانے کے لیے دو بار چیک کریں کہ آپ نے جو ہیش کوڈ کاپی کیا ہے وہ آپ کی **metadata.json** سے لنک کرتا ہے، اس کے لیے `https://gateway.pinata.cloud/ipfs/` کو ایک الگ ونڈو میں لوڈ کریں۔ صفحہ نیچے دیے گئے اسکرین شاٹ کی طرح نظر آنا چاہیے: + +![آپ کے صفحے پر json میٹا ڈیٹا ظاہر ہونا چاہیے](./metadataJSON.png)_آپ کے صفحے پر json میٹا ڈیٹا ظاہر ہونا چاہیے_ + +مجموعی طور پر، آپ کا کوڈ کچھ اس طرح نظر آنا چاہیے: + +```js +require("dotenv").config() +const API_URL = process.env.API_URL +const PUBLIC_KEY = process.env.PUBLIC_KEY +const PRIVATE_KEY = process.env.PRIVATE_KEY + +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(API_URL) + +const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json") +const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" +const nftContract = new web3.eth.Contract(contract.abi, contractAddress) + +async function mintNFT(tokenURI) { + const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") // تازہ ترین نانس حاصل کریں + + // ٹرانزیکشن + const tx = { + from: PUBLIC_KEY, + to: contractAddress, + nonce: nonce, + gas: 500000, + data: nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI(), + } + + const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY) + signPromise + .then((signedTx) => { + web3.eth.sendSignedTransaction( + signedTx.rawTransaction, + function (err, hash) { + if (!err) { + console.log( + "آپ کی ٹرانزیکشن کا ہیش ہے: ", + hash, + "\nاپنی ٹرانزیکشن کی حیثیت دیکھنے کے لیے Alchemy's Mempool کو چیک کریں!" + ) + } else { + console.log( + "آپ کی ٹرانزیکشن جمع کرتے وقت کچھ غلط ہو گیا:", + err + ) + } + } + ) + }) + .catch((err) => { + console.log("وعدہ ناکام رہا:", err) + }) +} + +mintNFT("ipfs://QmYueiuRNmL4MiA2GwtVMm6ZagknXnSpQnB3z2gWbz36hP") +``` + +اب، اپنا NFT ڈیپلائے کرنے کے لیے `node scripts/mint-nft.js` چلائیں۔ چند سیکنڈ کے بعد، آپ کو اپنے ٹرمینل میں اس طرح کا جواب نظر آنا چاہیے: + + ``` + آپ کی ٹرانزیکشن کا ہیش ہے: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8 + + اپنی ٹرانزیکشن کا اسٹیٹس دیکھنے کے لیے Alchemy کا Mempool چیک کریں! + ``` + +اگلا، اپنی ٹرانزیکشن کا اسٹیٹس دیکھنے کے لیے اپنے [Alchemy mempool](https://dashboard.alchemyapi.io/mempool) پر جائیں (چاہے وہ پینڈنگ ہو، مائن ہو گیا ہو، یا نیٹ ورک کے ذریعے ڈراپ ہو گیا ہو)۔ اگر آپ کی ٹرانزیکشن ڈراپ ہو گئی ہے، تو [Blockscout](https://eth-sepolia.blockscout.com/) کو چیک کرنا اور اپنی ٹرانزیکشن ہیش کو تلاش کرنا بھی مددگار ہے۔ + +![Etherscan پر اپنے NFT ٹرانزیکشن ہیش کو دیکھیں](./view-nft-etherscan.png)_Etherscan پر اپنے NFT ٹرانزیکشن ہیش کو دیکھیں_ + +اور بس ہو گیا! اب آپ نے Ethereum بلاک چین پر ایک NFT ڈیپلائے اور منٹ کر لیا ہے + +`mint-nft.js` کا استعمال کرتے ہوئے آپ اتنے NFTs منٹ کر سکتے ہیں جتنے آپ کا دل (اور والیٹ) چاہے! بس یہ یقینی بنائیں کہ آپ NFT کے میٹا ڈیٹا کی وضاحت کرنے والا ایک نیا tokenURI پاس کریں (ورنہ، آپ مختلف IDs کے ساتھ بہت سارے یکساں بنا لیں گے)۔ + +یقیناً، آپ اپنے NFT کو اپنے والیٹ میں دکھانا چاہیں گے — تو [حصہ 3: اپنے والیٹ میں اپنا NFT کیسے دیکھیں](/developers/tutorials/how-to-view-nft-in-metamask/) ضرور دیکھیں! diff --git a/public/content/translations/ur/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md b/public/content/translations/ur/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md new file mode 100644 index 00000000000..302ae22ea42 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md @@ -0,0 +1,102 @@ +--- +title: "ٹیسٹنگ کے لیے Solidity اسمارٹ کنٹریکٹس کو کیسے موک کریں" +description: "ٹیسٹنگ کے دوران آپ کو اپنے کنٹریکٹس کا مذاق کیوں اڑانا چاہئے" +author: Markus Waas +lang: ur-in +tags: [ "solidity", "اسمارٹ معاہدات", "testing", "mocking" ] +skill: intermediate +published: 2020-05-02 +source: soliditydeveloper.com +sourceUrl: https://soliditydeveloper.com/mocking-contracts +--- + +[موک آبجیکٹس](https://wikipedia.org/wiki/Mock_object) آبجیکٹ اورینٹڈ پروگرامنگ میں ایک عام ڈیزائن پیٹرن ہیں۔ پرانے فرانسیسی لفظ 'mocquer' سے ماخوذ ہے جس کا مطلب ہے 'مذاق اڑانا'، یہ 'کسی حقیقی چیز کی نقل کرنے' میں تبدیل ہو گیا جو دراصل وہی ہے جو ہم پروگرامنگ میں کرتے ہیں۔ براہ کرم اپنے اسمارٹ کنٹریکٹس کا مذاق صرف تب ہی اڑائیں جب آپ چاہیں، لیکن جب بھی ممکن ہو انہیں موک کریں۔ یہ آپ کی زندگی کو آسان بناتا ہے۔ + +## موکس کے ساتھ کنٹریکٹس کی یونٹ ٹیسٹنگ {#unit-testing-contracts-with-mocks} + +ایک کنٹریکٹ کو موک کرنے کا بنیادی طور پر مطلب اس کنٹریکٹ کا دوسرا ورژن بنانا ہے جو اصل والے سے بہت ملتا جلتا برتاؤ کرتا ہے، لیکن اس طریقے سے جسے ڈیولپر آسانی سے کنٹرول کر سکتا ہے۔ آپ اکثر پیچیدہ کنٹریکٹس کے ساتھ کام کرتے ہیں جہاں آپ صرف [کنٹریکٹ کے چھوٹے حصوں کی یونٹ ٹیسٹنگ](/developers/docs/smart-contracts/testing/) کرنا چاہتے ہیں۔ مسئلہ یہ ہے کہ اگر اس چھوٹے حصے کی ٹیسٹنگ کے لیے ایک بہت ہی مخصوص کنٹریکٹ اسٹیٹ کی ضرورت ہو جس تک پہنچنا مشکل ہو تو کیا ہوگا؟ + +آپ ہر بار پیچیدہ ٹیسٹ سیٹ اپ لاجک لکھ سکتے ہیں جو کنٹریکٹ کو مطلوبہ اسٹیٹ میں لاتا ہے یا آپ ایک موک لکھتے ہیں۔ انہیریٹنس کے ساتھ ایک کنٹریکٹ کو موک کرنا آسان ہے۔ بس ایک دوسرا موک کنٹریکٹ بنائیں جو اصل والے سے انہیریٹ کرتا ہو۔ اب آپ اپنے موک کے فنکشنز کو اوور رائڈ کر سکتے ہیں۔ آئیے اسے ایک مثال سے دیکھتے ہیں۔ + +## مثال: پرائیویٹ ERC20 {#example-private-erc20} + +ہم ایک مثال ERC-20 کنٹریکٹ استعمال کرتے ہیں جس کا ایک ابتدائی پرائیویٹ ٹائم ہوتا ہے۔ مالک پرائیویٹ یوزرس کا نظم کر سکتا ہے اور شروع میں صرف انہیں ہی ٹوکنز حاصل کرنے کی اجازت ہوگی۔ ایک خاص وقت گزر جانے کے بعد، ہر کسی کو ٹوکنز استعمال کرنے کی اجازت ہوگی۔ اگر آپ کو تجسس ہے، تو ہم نئے OpenZeppelin کنٹریکٹس v3 سے [`_beforeTokenTransfer`](https://docs.openzeppelin.com/contracts/5.x/extending-contracts#using-hooks) ہک استعمال کر رہے ہیں۔ + +```solidity +pragma solidity ^0.6.0; + +import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; +import "@openzeppelin/contracts/access/Ownable.sol"; + +contract PrivateERC20 is ERC20, Ownable { + mapping (address => bool) public isPrivateUser; + uint256 private publicAfterTime; + + constructor(uint256 privateERC20timeInSec) ERC20("PrivateERC20", "PRIV") public { + publicAfterTime = now + privateERC20timeInSec; + } + + function addUser(address user) external onlyOwner { + isPrivateUser[user] = true; + } + + function isPublic() public view returns (bool) { + return now >= publicAfterTime; + } + + function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override { + super._beforeTokenTransfer(from, to, amount); + + require(_validRecipient(to), "PrivateERC20: invalid recipient"); + } + + function _validRecipient(address to) private view returns (bool) { + if (isPublic()) { + return true; + } + + return isPrivateUser[to]; + } +} +``` + +اور اب آئیے اسے موک کرتے ہیں۔ + +```solidity +pragma solidity ^0.6.0; +import "../PrivateERC20.sol"; + +contract PrivateERC20Mock is PrivateERC20 { + bool isPublicConfig; + + constructor() public PrivateERC20(0) {} + + function setIsPublic(bool isPublic) external { + isPublicConfig = isPublic; + } + + function isPublic() public view returns (bool) { + return isPublicConfig; + } +} +``` + +آپ کو مندرجہ ذیل میں سے ایک ایرر میسیج ملے گا: + +- `PrivateERC20Mock.sol: TypeError: Overriding function is missing "override" specifier.` +- `PrivateERC20.sol: TypeError: Trying to override non-virtual function.` `Did you forget to add "virtual"?.` + +چونکہ ہم نیا 0.6 Solidity ورژن استعمال کر رہے ہیں، ہمیں ان فنکشنز کے لیے `virtual` کی ورڈ شامل کرنا ہوگا جنہیں اوور رائڈ کیا جا سکتا ہے اور اوور رائڈ کرنے والے فنکشن کے لیے `override` شامل کرنا ہوگا۔ تو آئیے انہیں دونوں `isPublic` فنکشنز میں شامل کرتے ہیں۔ + +اب اپنے یونٹ ٹیسٹس میں، آپ اس کے بجائے `PrivateERC20Mock` استعمال کر سکتے ہیں۔ جب آپ پرائیویٹ استعمال کے وقت کے دوران برتاؤ کی ٹیسٹنگ کرنا چاہتے ہیں، تو `setIsPublic(false)` استعمال کریں اور اسی طرح پبلک استعمال کے وقت کی ٹیسٹنگ کے لیے `setIsPublic(true)` استعمال کریں۔ یقیناً ہماری مثال میں، ہم وقت کو اسی کے مطابق تبدیل کرنے کے لیے [ٹائم ہیلپرز](https://docs.openzeppelin.com/test-helpers/0.5/api#increase) بھی استعمال کر سکتے ہیں۔ لیکن موکنگ کا آئیڈیا اب واضح ہو جانا چاہیے اور آپ ایسے منظرناموں کا تصور کر سکتے ہیں جہاں یہ صرف وقت کو آگے بڑھانے جتنا آسان نہیں ہوتا۔ + +## بہت سے کنٹریکٹس کو موک کرنا {#mocking-many-contracts} + +اگر آپ کو ہر ایک موک کے لیے ایک اور کنٹریکٹ بنانا پڑے تو یہ گڑبڑ ہو سکتا ہے۔ اگر یہ آپ کو پریشان کرتا ہے، تو آپ [MockContract](https://github.com/gnosis/mock-contract) لائبریری کو دیکھ سکتے ہیں۔ یہ آپ کو کنٹریکٹس کے برتاؤ کو فوری طور پر اوور رائڈ کرنے اور تبدیل کرنے کی اجازت دیتا ہے۔ تاہم، یہ صرف دوسرے کنٹریکٹ پر کالز کو موک کرنے کے لیے کام کرتا ہے، لہذا یہ ہماری مثال کے لیے کام نہیں کرے گا۔ + +## موکنگ اور بھی زیادہ طاقتور ہو سکتی ہے {#mocking-can-be-even-more-powerful} + +موکنگ کی طاقتیں یہیں ختم نہیں ہوتیں۔ + +- فنکشنز شامل کرنا: نہ صرف کسی مخصوص فنکشن کو اوور رائڈ کرنا مفید ہے، بلکہ اضافی فنکشنز شامل کرنا بھی مفید ہے۔ ٹوکنز کے لیے ایک اچھی مثال ایک اضافی `mint` فنکشن رکھنا ہے تاکہ کسی بھی یوزر کو مفت میں نئے ٹوکنز حاصل کرنے کی اجازت مل سکے۔ +- ٹیسٹ نیٹس میں استعمال: جب آپ اپنے ڈیپ (dapp) کے ساتھ اپنے کنٹریکٹس کو ٹیسٹ نیٹس پر ڈیپلائے اور ٹیسٹ کرتے ہیں، تو ایک موکڈ ورژن استعمال کرنے پر غور کریں۔ فنکشنز کو اوور رائڈ کرنے سے گریز کریں جب تک کہ آپ کو واقعی ایسا کرنے کی ضرورت نہ ہو۔ آخرکار آپ اصلی لاجک کی ٹیسٹنگ کرنا چاہتے ہیں۔ لیکن مثال کے طور پر ایک ری سیٹ فنکشن شامل کرنا مفید ہو سکتا ہے جو صرف کنٹریکٹ اسٹیٹ کو شروع میں ری سیٹ کر دیتا ہے، کسی نئے ڈیپلائمنٹ کی ضرورت نہیں ہوتی۔ ظاہر ہے کہ آپ ایک Mainnet کنٹریکٹ میں ایسا نہیں چاہیں گے۔ diff --git a/public/content/translations/ur/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/ur/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md new file mode 100644 index 00000000000..d38dc406313 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md @@ -0,0 +1,705 @@ +--- +title: "اسمارٹ کنٹریکٹس کو ٹیسٹ کرنے کے لیے Echidna کا استعمال کیسے کریں" +description: "اسمارٹ کنٹریکٹس کو خود بخود ٹیسٹ کرنے کے لیے Echidna کا استعمال کیسے کریں" +author: "Trailofbits" +lang: ur-in +tags: + [ + "solidity", + "اسمارٹ معاہدات", + "سیکورٹی", + "testing", + "fuzzing" + ] +skill: advanced +published: 2020-04-10 +source: Building secure contracts +sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna +--- + +## انسٹالیشن {#installation} + +Echidna کو docker کے ذریعے یا پہلے سے کمپائل شدہ بائنری کا استعمال کرکے انسٹال کیا جا سکتا ہے۔ + +### docker کے ذریعے Echidna {#echidna-through-docker} + +```bash +docker pull trailofbits/eth-security-toolbox +docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox +``` + +_آخری کمانڈ eth-security-toolbox کو ایک docker میں چلاتا ہے جس کی آپ کی موجودہ ڈائریکٹری تک رسائی ہے۔ آپ اپنے ہوسٹ سے فائلیں تبدیل کر سکتے ہیں، اور docker سے فائلوں پر ٹولز چلا سکتے ہیں_ + +docker کے اندر، چلائیں: + +```bash +solc-select 0.5.11 +cd /home/training +``` + +### بائنری {#binary} + +[https://github.com/crytic/echidna/releases/tag/v1.4.0.0](https://github.com/crytic/echidna/releases/tag/v1.4.0.0) + +## پراپرٹی پر مبنی فزنگ کا تعارف {#introduction-to-property-based-fuzzing} + +Echidna ایک پراپرٹی پر مبنی fuzzer ہے، جس کی تفصیل ہم نے اپنی پچھلی بلاگ پوسٹس میں بیان کی ہے ([1](https://blog.trailofbits.com/2018/03/09/echidna-a-smart-fuzzer-for-ethereum/), [2](https://blog.trailofbits.com/2018/05/03/state-machine-testing-with-echidna/), [3](https://blog.trailofbits.com/2020/03/30/an-echidna-for-all-seasons/)). + +### Fuzzing {#fuzzing} + +[Fuzzing](https://wikipedia.org/wiki/Fuzzing) سیکورٹی کمیونٹی میں ایک معروف تکنیک ہے۔ یہ پروگرام میں کیڑے تلاش کرنے کے لیے کم و بیش بے ترتیب ان پٹس پیدا کرنے پر مشتمل ہے۔ روایتی سافٹ ویئر کے لیے Fuzzers (جیسے کہ [AFL](http://lcamtuf.coredump.cx/afl/) یا [LibFuzzer](https://llvm.org/docs/LibFuzzer.html)) کیڑے تلاش کرنے کے لیے موثر ٹولز کے طور پر جانے جاتے ہیں۔ + +ان پٹس کی خالصتاً بے ترتیب جنریشن سے ہٹ کر، اچھے ان پٹس پیدا کرنے کے لیے بہت سی تکنیکیں اور حکمت عملیاں ہیں، جن میں شامل ہیں: + +- ہر ایگزیکیوشن سے فیڈ بیک حاصل کریں اور اس کا استعمال کرتے ہوئے جنریشن کی رہنمائی کریں۔ مثال کے طور پر، اگر کوئی نیا تیار کردہ ان پٹ کسی نئے راستے کی دریافت کا باعث بنتا ہے، تو اس کے قریب نئے ان پٹ تیار کرنا سمجھ میں آ سکتا ہے۔ +- ساختی رکاوٹ کا احترام کرتے ہوئے ان پٹ تیار کرنا۔ مثال کے طور پر، اگر آپ کے ان پٹ میں چیک سم کے ساتھ ہیڈر ہے، تو یہ سمجھ میں آئے گا کہ fuzzer کو چیک سم کی توثیق کرنے والا ان پٹ تیار کرنے دیا جائے۔ +- نئے ان پٹس تیار کرنے کے لیے معروف ان پٹس کا استعمال: اگر آپ کے پاس درست ان پٹ کے بڑے ڈیٹا سیٹ تک رسائی ہے، تو آپ کا fuzzer شروع سے اپنی جنریشن شروع کرنے کے بجائے ان سے نئے ان پٹ تیار کر سکتا ہے۔ ان کو عام طور پر _seeds_ کہا جاتا ہے۔ + +### پراپرٹی پر مبنی فزنگ {#property-based-fuzzing} + +Echidna کا تعلق fuzzer کے ایک مخصوص خاندان سے ہے: پراپرٹی پر مبنی فزنگ [QuickCheck](https://wikipedia.org/wiki/QuickCheck) سے بہت زیادہ متاثر ہے۔ کلاسک fuzzer کے برعکس جو کریشز تلاش کرنے کی کوشش کرے گا، Echidna صارف کی طرف سے بیان کردہ انویرینٹس کو توڑنے کی کوشش کرے گا۔ + +اسمارٹ کنٹریکٹس میں، انویرینٹس Solidity فنکشنز ہیں، جو کسی بھی غلط یا غلط اسٹیٹ کی نمائندگی کر سکتے ہیں جس تک کنٹریکٹ پہنچ سکتا ہے، بشمول: + +- غلط رسائی کنٹرول: حملہ آور کنٹریکٹ کا مالک بن گیا۔ +- غلط اسٹیٹ مشین: کنٹریکٹ کے موقوف ہونے کے دوران ٹوکنز منتقل کیے جا سکتے ہیں۔ +- غلط حساب: صارف اپنے بیلنس کو انڈر فلو کر سکتا ہے اور لامحدود مفت ٹوکن حاصل کر سکتا ہے۔ + +### Echidna کے ساتھ پراپرٹی کی جانچ کرنا {#testing-a-property-with-echidna} + +ہم دیکھیں گے کہ Echidna کے ساتھ اسمارٹ کنٹریکٹ کی جانچ کیسے کی جائے۔ ہدف درج ذیل اسمارٹ کنٹریکٹ ہے [`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol): + +```solidity +contract Token{ + mapping(address => uint) public balances; + function airdrop() public{ + balances[msg.sender] = 1000; + } + function consume() public{ + require(balances[msg.sender]>0); + balances[msg.sender] -= 1; + } + function backdoor() public{ + balances[msg.sender] += 1; + } +} +``` + +ہم یہ فرض کریں گے کہ اس ٹوکن میں درج ذیل خصوصیات ہونی چاہئیں: + +- کوئی بھی زیادہ سے زیادہ 1000 ٹوکنز رکھ سکتا ہے۔ +- ٹوکن منتقل نہیں کیا جا سکتا (یہ ERC20 ٹوکن نہیں ہے) + +### ایک پراپرٹی لکھیں {#write-a-property} + +Echidna خصوصیات Solidity فنکشنز ہیں۔ ایک پراپرٹی میں ہونا چاہئے: + +- کوئی آرگیومنٹ نہ ہو +- کامیاب ہونے پر `true` لوٹائیں +- اس کا نام `echidna` سے شروع ہو + +Echidna کرے گا: + +- پراپرٹی کو جانچنے کے لیے خود بخود صوابدیدی لین دین پیدا کریں۔ +- کسی بھی ایسے لین دین کی اطلاع دیں جس کی وجہ سے کوئی پراپرٹی `false` لوٹائے یا غلطی پیدا کرے۔ +- پراپرٹی کو کال کرتے وقت ضمنی اثر کو مسترد کریں (یعنی، اگر پراپرٹی کسی اسٹیٹ متغیر کو تبدیل کرتی ہے، تو اسے ٹیسٹ کے بعد مسترد کر دیا جاتا ہے) + +درج ذیل پراپرٹی جانچتی ہے کہ کالر کے پاس 1000 سے زیادہ ٹوکن نہیں ہیں: + +```solidity +function echidna_balance_under_1000() public view returns(bool){ + return balances[msg.sender] <= 1000; +} +``` + +اپنے کنٹریکٹ کو اپنی خصوصیات سے الگ کرنے کے لیے وراثت کا استعمال کریں: + +```solidity +contract TestToken is Token{ + function echidna_balance_under_1000() public view returns(bool){ + return balances[msg.sender] <= 1000; + } + } +``` + +[`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol) پراپرٹی کو نافذ کرتا ہے اور ٹوکن سے وراثت میں ملتا ہے۔ + +### ایک کنٹریکٹ شروع کریں {#initiate-a-contract} + +Echidna کو بغیر آرگیومنٹ کے ایک [constructor](/developers/docs/smart-contracts/anatomy/#constructor-functions) کی ضرورت ہے۔ اگر آپ کے کنٹریکٹ کو کسی مخصوص ابتداء کی ضرورت ہے، تو آپ کو اسے کنسٹرکٹر میں کرنا ہوگا۔ + +Echidna میں کچھ مخصوص ایڈریسز ہیں: + +- `0x00a329c0648769A73afAc7F9381E08FB43dBEA72` جو کنسٹرکٹر کو کال کرتا ہے۔ +- `0x10000`, `0x20000`، اور `0x00a329C0648769a73afAC7F9381e08fb43DBEA70` جو بے ترتیب طور پر دیگر فنکشنز کو کال کرتے ہیں۔ + +ہمیں اپنی موجودہ مثال میں کسی خاص ابتداء کی ضرورت نہیں ہے، نتیجے کے طور پر ہمارا کنسٹرکٹر خالی ہے۔ + +### Echidna چلائیں {#run-echidna} + +Echidna کو اس کے ساتھ لانچ کیا گیا ہے: + +```bash +echidna-test contract.sol +``` + +اگر contract.sol میں متعدد کنٹریکٹس ہیں، تو آپ ہدف کی وضاحت کر سکتے ہیں: + +```bash +echidna-test contract.sol --contract MyContract +``` + +### خلاصہ: ایک پراپرٹی کی جانچ {#summary-testing-a-property} + +درج ذیل ہماری مثال پر echidna کے چلانے کا خلاصہ کرتا ہے: + +```solidity +contract TestToken is Token{ + constructor() public {} + function echidna_balance_under_1000() public view returns(bool){ + return balances[msg.sender] <= 1000; + } + } +``` + +```bash +echidna-test testtoken.sol --contract TestToken +... + +echidna_balance_under_1000: failed!💥 + Call sequence, shrinking (1205/5000): + airdrop() + backdoor() + +... +``` + +Echidna نے پایا کہ اگر `backdoor` کو کال کیا جائے تو پراپرٹی کی خلاف ورزی ہوتی ہے۔ + +## فزنگ مہم کے دوران کال کرنے کے لیے فنکشنز کو فلٹر کرنا {#filtering-functions-to-call-during-a-fuzzing-campaign} + +ہم دیکھیں گے کہ fuzzed کیے جانے والے فنکشنز کو کیسے فلٹر کیا جائے۔ +ہدف درج ذیل اسمارٹ کنٹریکٹ ہے: + +```solidity +contract C { + bool state1 = false; + bool state2 = false; + bool state3 = false; + bool state4 = false; + + function f(uint x) public { + require(x == 12); + state1 = true; + } + + function g(uint x) public { + require(state1); + require(x == 8); + state2 = true; + } + + function h(uint x) public { + require(state2); + require(x == 42); + state3 = true; + } + + function i() public { + require(state3); + state4 = true; + } + + function reset1() public { + state1 = false; + state2 = false; + state3 = false; + return; + } + + function reset2() public { + state1 = false; + state2 = false; + state3 = false; + return; + } + + function echidna_state4() public returns (bool) { + return (!state4); + } +} +``` + +یہ چھوٹی سی مثال Echidna کو اسٹیٹ متغیر کو تبدیل کرنے کے لیے لین دین کا ایک خاص سلسلہ تلاش کرنے پر مجبور کرتی ہے۔ +یہ ایک fuzzer کے لیے مشکل ہے (یہ [Manticore](https://github.com/trailofbits/manticore) جیسے علامتی ایگزیکیوشن ٹول استعمال کرنے کی سفارش کی جاتی ہے)۔ +ہم اس کی تصدیق کے لیے Echidna چلا سکتے ہیں: + +```bash +echidna-test multi.sol +... +echidna_state4: passed! 🎉 +Seed: -3684648582249875403 +``` + +### فلٹرنگ فنکشنز {#filtering-functions} + +Echidna کو اس کنٹریکٹ کو جانچنے کے لیے صحیح ترتیب تلاش کرنے میں دشواری ہوتی ہے کیونکہ دو ری سیٹ فنکشنز (`reset1` اور `reset2`) تمام اسٹیٹ متغیرات کو `false` پر سیٹ کر دیں گے۔ +تاہم، ہم ری سیٹ فنکشن کو بلیک لسٹ کرنے یا صرف `f`، `g`، `h` اور `i` فنکشنز کو وائٹ لسٹ کرنے کے لیے ایک خاص Echidna فیچر استعمال کر سکتے ہیں۔ + +فنکشنز کو بلیک لسٹ کرنے کے لیے، ہم یہ کنفیگریشن فائل استعمال کر سکتے ہیں: + +```yaml +filterBlacklist: true +filterFunctions: ["reset1", "reset2"] +``` + +فنکشنز کو فلٹر کرنے کا دوسرا طریقہ وائٹ لسٹڈ فنکشنز کی فہرست بنانا ہے۔ ایسا کرنے کے لیے، ہم یہ کنفیگریشن فائل استعمال کر سکتے ہیں: + +```yaml +filterBlacklist: false +filterFunctions: ["f", "g", "h", "i"] +``` + +- `filterBlacklist` پہلے سے طے شدہ طور پر `true` ہے۔ +- فلٹرنگ صرف نام سے کی جائے گی (پیرامیٹرز کے بغیر)۔ اگر آپ کے پاس `f()` اور `f(uint256)` ہے، تو فلٹر `"f"` دونوں فنکشنز سے مماثل ہوگا۔ + +### Echidna چلائیں {#run-echidna-1} + +کنفیگریشن فائل `blacklist.yaml` کے ساتھ Echidna کو چلانے کے لیے: + +```bash +echidna-test multi.sol --config blacklist.yaml +... +echidna_state4: failed!💥 + Call sequence: + f(12) + g(8) + h(42) + i() +``` + +Echidna تقریباً فوراً پراپرٹی کو غلط ثابت کرنے کے لیے لین دین کا سلسلہ تلاش کر لے گا۔ + +### خلاصہ: فلٹرنگ فنکشنز {#summary-filtering-functions} + +Echidna فزنگ مہم کے دوران کال کرنے کے لیے فنکشنز کو بلیک لسٹ یا وائٹ لسٹ کر سکتا ہے: + +```yaml +filterBlacklist: true +filterFunctions: ["f1", "f2", "f3"] +``` + +```bash +echidna-test contract.sol --config config.yaml +... +``` + +Echidna ایک فزنگ مہم شروع کرتا ہے جو یا تو `f1`، `f2` اور `f3` کو بلیک لسٹ کرتا ہے یا صرف انہیں کال کرتا ہے، `filterBlacklist` بولین کی قدر کے مطابق۔ + +## Echidna کے ساتھ Solidity کے assert کی جانچ کیسے کریں {#how-to-test-soliditys-assert-with-echidna} + +اس مختصر ٹیوٹوریل میں، ہم یہ دکھانے جا رہے ہیں کہ کنٹریکٹس میں اسسرشن چیکنگ کو ٹیسٹ کرنے کے لیے Echidna کا استعمال کیسے کریں۔ آئیے فرض کریں کہ ہمارے پاس اس طرح کا ایک کنٹریکٹ ہے: + +```solidity +contract Incrementor { + uint private counter = 2**200; + + function inc(uint val) public returns (uint){ + uint tmp = counter; + counter += val; + // tmp <= counter + return (counter - tmp); + } +} +``` + +### ایک اسسرشن لکھیں {#write-an-assertion} + +ہم یہ یقینی بنانا چاہتے ہیں کہ `tmp` اس کے فرق کو واپس کرنے کے بعد `counter` سے کم یا اس کے برابر ہے۔ ہم ایک Echidna پراپرٹی لکھ سکتے ہیں، لیکن ہمیں `tmp` ویلیو کو کہیں ذخیرہ کرنے کی ضرورت ہوگی۔ اس کے بجائے، ہم اس طرح کا ایک اسسرشن استعمال کر سکتے ہیں: + +```solidity +contract Incrementor { + uint private counter = 2**200; + + function inc(uint val) public returns (uint){ + uint tmp = counter; + counter += val; + assert (tmp <= counter); + return (counter - tmp); + } +} +``` + +### Echidna چلائیں {#run-echidna-2} + +اسسرشن فیل ہونے کی جانچ کو فعال کرنے کے لیے، ایک [Echidna کنفیگریشن فائل](https://github.com/crytic/echidna/wiki/Config) `config.yaml` بنائیں: + +```yaml +checkAsserts: true +``` + +جب ہم Echidna میں اس کنٹریکٹ کو چلاتے ہیں، تو ہمیں متوقع نتائج ملتے ہیں: + +```bash +echidna-test assert.sol --config config.yaml +Analyzing contract: assert.sol:Incrementor +assertion in inc: failed!💥 + Call sequence, shrinking (2596/5000): + inc(21711016731996786641919559689128982722488122124807605757398297001483711807488) + inc(7237005577332262213973186563042994240829374041602535252466099000494570602496) + inc(86844066927987146567678238756515930889952488499230423029593188005934847229952) + +Seed: 1806480648350826486 +``` + +جیسا کہ آپ دیکھ سکتے ہیں، Echidna `inc` فنکشن میں کچھ اسسرشن فیل ہونے کی اطلاع دیتا ہے۔ فی فنکشن ایک سے زیادہ اسسرشن شامل کرنا ممکن ہے، لیکن Echidna یہ نہیں بتا سکتا کہ کون سا اسسرشن فیل ہوا۔ + +### اسسرشنز کا استعمال کب اور کیسے کریں {#when-and-how-use-assertions} + +اسسرشنز کو واضح خصوصیات کے متبادل کے طور پر استعمال کیا جا سکتا ہے، خاص طور پر اگر جانچ کی جانے والی شرائط براہ راست کچھ آپریشن `f` کے صحیح استعمال سے متعلق ہوں۔ کچھ کوڈ کے بعد اسسرشنز شامل کرنے سے اس بات کو یقینی بنایا جائے گا کہ چیک اس کے ایگزیکیوٹ ہونے کے فوراً بعد ہوگا: + +```solidity +function f(..) public { + // کچھ پیچیدہ کوڈ + ... + assert (condition); + ... +} + +``` + +اس کے برعکس، ایک واضح echidna پراپرٹی کا استعمال بے ترتیب طور پر ایگزیکیوشن لین دین کرے گا اور اس بات کو نافذ کرنے کا کوئی آسان طریقہ نہیں ہے کہ اسے کب چیک کیا جائے گا۔ یہ حل اب بھی ممکن ہے: + +```solidity +function echidna_assert_after_f() public returns (bool) { + f(..); + return(condition); +} +``` + +تاہم، کچھ مسائل ہیں: + +- یہ ناکام ہو جاتا ہے اگر `f` کو `internal` یا `external` کے طور پر قرار دیا گیا ہو۔ +- یہ واضح نہیں ہے کہ `f` کو کال کرنے کے لیے کون سے دلائل استعمال کیے جائیں۔ +- اگر `f` واپس آجاتا ہے، تو پراپرٹی ناکام ہو جائے گی۔ + +عام طور پر، ہم اسسرشنز کا استعمال کرنے کے طریقے پر [جان ریگیر کی سفارش](https://blog.regehr.org/archives/1091) پر عمل کرنے کی سفارش کرتے ہیں: + +- اسسرشن کی جانچ کے دوران کسی بھی ضمنی اثر پر مجبور نہ کریں۔ مثال کے طور پر: `assert(ChangeStateAndReturn() == 1)` +- واضح بیانات پر زور نہ دیں۔ مثال کے طور پر `assert(var >= 0)` جہاں `var` کو `uint` کے طور پر قرار دیا گیا ہے۔ + +آخر میں، براہ کرم `assert` کے بجائے `require` کا **استعمال نہ کریں**، کیونکہ Echidna اس کا پتہ نہیں لگا سکے گا (لیکن کنٹریکٹ بہرحال واپس آ جائے گا)۔ + +### خلاصہ: اسسرشن کی جانچ {#summary-assertion-checking} + +درج ذیل ہماری مثال پر echidna کے چلانے کا خلاصہ کرتا ہے: + +```solidity +contract Incrementor { + uint private counter = 2**200; + + function inc(uint val) public returns (uint){ + uint tmp = counter; + counter += val; + assert (tmp <= counter); + return (counter - tmp); + } +} +``` + +```bash +echidna-test assert.sol --config config.yaml +Analyzing contract: assert.sol:Incrementor +assertion in inc: failed!💥 + Call sequence, shrinking (2596/5000): + inc(21711016731996786641919559689128982722488122124807605757398297001483711807488) + inc(7237005577332262213973186563042994240829374041602535252466099000494570602496) + inc(86844066927987146567678238756515930889952488499230423029593188005934847229952) + +Seed: 1806480648350826486 +``` + +Echidna نے پایا کہ `inc` میں اسسرشن ناکام ہو سکتا ہے اگر اس فنکشن کو بڑے دلائل کے ساتھ متعدد بار کال کیا جائے۔ + +## Echidna کارپس کو جمع کرنا اور اس میں ترمیم کرنا {#collecting-and-modifying-an-echidna-corpus} + +ہم دیکھیں گے کہ Echidna کے ساتھ لین دین کے کارپس کو کیسے جمع کیا جائے اور استعمال کیا جائے۔ ہدف درج ذیل اسمارٹ کنٹریکٹ [`magic.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/magic.sol) ہے: + +```solidity +contract C { + bool value_found = false; + function magic(uint magic_1, uint magic_2, uint magic_3, uint magic_4) public { + require(magic_1 == 42); + require(magic_2 == 129); + require(magic_3 == magic_4+333); + value_found = true; + return; + } + + function echidna_magic_values() public returns (bool) { + return !value_found; + } + +} +``` + +یہ چھوٹی سی مثال Echidna کو اسٹیٹ متغیر کو تبدیل کرنے کے لیے کچھ مخصوص اقدار تلاش کرنے پر مجبور کرتی ہے۔ یہ ایک fuzzer کے لیے مشکل ہے +(یہ [Manticore](https://github.com/trailofbits/manticore) جیسے علامتی ایگزیکیوشن ٹول استعمال کرنے کی سفارش کی جاتی ہے)۔ +ہم اس کی تصدیق کے لیے Echidna چلا سکتے ہیں: + +```bash +echidna-test magic.sol +... + +echidna_magic_values: passed! 🎉 + +Seed: 2221503356319272685 +``` + +تاہم، ہم اب بھی اس فزنگ مہم کو چلاتے وقت کارپس جمع کرنے کے لیے Echidna کا استعمال کر سکتے ہیں۔ + +### کارپس جمع کرنا {#collecting-a-corpus} + +کارپس جمع کرنے کو فعال کرنے کے لیے، ایک کارپس ڈائریکٹری بنائیں: + +```bash +mkdir corpus-magic +``` + +اور ایک [Echidna کنفیگریشن فائل](https://github.com/crytic/echidna/wiki/Config) `config.yaml`: + +```yaml +coverage: true +corpusDir: "corpus-magic" +``` + +اب ہم اپنا ٹول چلا سکتے ہیں اور جمع شدہ کارپس کی جانچ کر سکتے ہیں: + +```bash +echidna-test magic.sol --config config.yaml +``` + +Echidna اب بھی صحیح جادوئی اقدار نہیں ڈھونڈ سکتا، لیکن ہم اس کے جمع کردہ کارپس پر ایک نظر ڈال سکتے ہیں۔ +مثال کے طور پر، ان میں سے ایک فائل یہ تھی: + +```json +[ + { + "_gas'": "0xffffffff", + "_delay": ["0x13647", "0xccf6"], + "_src": "00a329c0648769a73afac7f9381e08fb43dbea70", + "_dst": "00a329c0648769a73afac7f9381e08fb43dbea72", + "_value": "0x0", + "_call": { + "tag": "SolCall", + "contents": [ + "magic", + [ + { + "contents": [ + 256, + "93723985220345906694500679277863898678726808528711107336895287282192244575836" + ], + "tag": "AbiUInt" + }, + { + "contents": [256, "334"], + "tag": "AbiUInt" + }, + { + "contents": [ + 256, + "68093943901352437066264791224433559271778087297543421781073458233697135179558" + ], + "tag": "AbiUInt" + }, + { + "tag": "AbiUInt", + "contents": [256, "332"] + } + ] + ] + }, + "_gasprice'": "0xa904461f1" + } +] +``` + +واضح طور پر، یہ ان پٹ ہماری پراپرٹی میں ناکامی کو متحرک نہیں کرے گا۔ تاہم، اگلے مرحلے میں، ہم دیکھیں گے کہ اس کے لیے اسے کیسے تبدیل کیا جائے۔ + +### کارپس کو سیڈ کرنا {#seeding-a-corpus} + +`magic` فنکشن سے نمٹنے کے لیے Echidna کو کچھ مدد کی ضرورت ہے۔ ہم اس کے لیے موزوں پیرامیٹرز استعمال کرنے کے لیے ان پٹ کو کاپی اور ترمیم کرنے جا رہے ہیں: + +```bash +cp corpus/2712688662897926208.txt corpus/new.txt +``` + +ہم `new.txt` کو `magic(42,129,333,0)` کال کرنے کے لیے تبدیل کریں گے۔ اب، ہم Echidna کو دوبارہ چلا سکتے ہیں: + +```bash +echidna-test magic.sol --config config.yaml +... +echidna_magic_values: failed!💥 + Call sequence: + magic(42,129,333,0) + + +Unique instructions: 142 +Unique codehashes: 1 +Seed: -7293830866560616537 + +``` + +اس بار، اس نے پایا کہ پراپرٹی کی فوری طور پر خلاف ورزی ہوئی ہے۔ + +## زیادہ گیس کی کھپت والے لین دین کی تلاش {#finding-transactions-with-high-gas-consumption} + +ہم دیکھیں گے کہ Echidna کے ساتھ زیادہ گیس کی کھپت والے لین دین کو کیسے تلاش کیا جائے۔ ہدف درج ذیل اسمارٹ کنٹریکٹ ہے: + +```solidity +contract C { + uint state; + + function expensive(uint8 times) internal { + for(uint8 i=0; i < times; i++) + state = state + i; + } + + function f(uint x, uint y, uint8 times) public { + if (x == 42 && y == 123) + expensive(times); + else + state = 0; + } + + function echidna_test() public returns (bool) { + return true; + } + +} +``` + +یہاں `expensive` میں گیس کی بڑی کھپت ہو سکتی ہے۔ + +فی الحال، Echidna کو ہمیشہ جانچ کے لیے ایک پراپرٹی کی ضرورت ہوتی ہے: یہاں `echidna_test` ہمیشہ `true` لوٹاتا ہے۔ +ہم اس کی تصدیق کے لیے Echidna چلا سکتے ہیں: + +``` +echidna-test gas.sol +... +echidna_test: passed! 🎉 + +Seed: 2320549945714142710 +``` + +### گیس کی کھپت کی پیمائش {#measuring-gas-consumption} + +Echidna کے ساتھ گیس کی کھپت کو فعال کرنے کے لیے، ایک کنفیگریشن فائل `config.yaml` بنائیں: + +```yaml +estimateGas: true +``` + +اس مثال میں، ہم نتائج کو سمجھنے میں آسانی پیدا کرنے کے لیے لین دین کی ترتیب کے سائز کو بھی کم کریں گے: + +```yaml +seqLen: 2 +estimateGas: true +``` + +### Echidna چلائیں {#run-echidna-3} + +ایک بار جب ہم کنفیگریشن فائل بنا لیں، تو ہم Echidna کو اس طرح چلا سکتے ہیں: + +```bash +echidna-test gas.sol --config config.yaml +... +echidna_test: passed! 🎉 + +f used a maximum of 1333608 gas + Call sequence: + f(42,123,249) Gas price: 0x10d5733f0a Time delay: 0x495e5 Block delay: 0x88b2 + +Unique instructions: 157 +Unique codehashes: 1 +Seed: -325611019680165325 + +``` + +- دکھائی گئی گیس [HEVM](https://github.com/dapphub/dapptools/tree/master/src/hevm#hevm-) کے ذریعے فراہم کردہ ایک تخمینہ ہے۔ + +### گیس کم کرنے والی کالز کو فلٹر کرنا {#filtering-out-gas-reducing-calls} + +اوپر **فزنگ مہم کے دوران کال کرنے کے لیے فنکشنز کو فلٹر کرنے** پر ٹیوٹوریل دکھاتا ہے کہ آپ کی جانچ سے کچھ فنکشنز کو کیسے ہٹایا جائے۔ +گیس کا درست تخمینہ حاصل کرنے کے لیے یہ اہم ہو سکتا ہے۔ +درج ذیل مثال پر غور کریں: + +```solidity +contract C { + address [] addrs; + function push(address a) public { + addrs.push(a); + } + function pop() public { + addrs.pop(); + } + function clear() public{ + addrs.length = 0; + } + function check() public{ + for(uint256 i = 0; i < addrs.length; i++) + for(uint256 j = i+1; j < addrs.length; j++) + if (addrs[i] == addrs[j]) + addrs[j] = address(0x0); + } + function echidna_test() public returns (bool) { + return true; + } +} +``` + +اگر Echidna تمام فنکشنز کو کال کر سکتا ہے، تو اسے زیادہ گیس لاگت والے لین دین آسانی سے نہیں ملیں گے: + +``` +echidna-test pushpop.sol --config config.yaml +... +pop used a maximum of 10746 gas +... +check used a maximum of 23730 gas +... +clear used a maximum of 35916 gas +... +push used a maximum of 40839 gas +``` + +اس کی وجہ یہ ہے کہ لاگت `addrs` کے سائز پر منحصر ہے اور بے ترتیب کالز صف کو تقریباً خالی چھوڑ دیتی ہیں۔ +`pop` اور `clear` کو بلیک لسٹ کرنے سے، تاہم، ہمیں بہت بہتر نتائج ملتے ہیں: + +```yaml +filterBlacklist: true +filterFunctions: ["pop", "clear"] +``` + +``` +echidna-test pushpop.sol --config config.yaml +... +push used a maximum of 40839 gas +... +check used a maximum of 1484472 gas +``` + +### خلاصہ: زیادہ گیس کی کھپت والے لین دین کی تلاش {#summary-finding-transactions-with-high-gas-consumption} + +Echidna `estimateGas` کنفیگریشن آپشن کا استعمال کرکے زیادہ گیس کی کھپت والے لین دین تلاش کر سکتا ہے: + +```yaml +estimateGas: true +``` + +```bash +echidna-test contract.sol --config config.yaml +... +``` + +Echidna ہر فنکشن کے لیے زیادہ سے زیادہ گیس کی کھپت کے ساتھ ایک ترتیب کی اطلاع دے گا، جب فزنگ مہم ختم ہو جائے گی۔ diff --git a/public/content/translations/ur/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/ur/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md new file mode 100644 index 00000000000..47c472e1fa1 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md @@ -0,0 +1,526 @@ +--- +title: "اسمارٹ کنٹریکٹس میں بگز تلاش کرنے کے لیے Manticore کا استعمال کیسے کریں" +description: "اسمارٹ کنٹریکٹس میں خود بخود بگز تلاش کرنے کے لیے Manticore کا استعمال کیسے کریں" +author: Trailofbits +lang: ur-in +tags: + [ + "solidity", + "اسمارٹ معاہدات", + "سیکورٹی", + "testing", + "رسمی تصدیق" + ] +skill: advanced +published: 2020-01-13 +source: Building secure contracts +sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore +--- + +اس ٹیوٹوریل کا مقصد یہ دکھانا ہے کہ اسمارٹ کنٹریکٹس میں خود بخود بگز تلاش کرنے کے لیے Manticore کا استعمال کیسے کیا جائے۔ + +## انسٹالیشن {#installation} + +Manticore کے لیے >= python 3.6 درکار ہے۔ اسے pip کے ذریعے یا docker کا استعمال کرکے انسٹال کیا جاسکتا ہے۔ + +### docker کے ذریعے Manticore {#manticore-through-docker} + +```bash +docker pull trailofbits/eth-security-toolbox +docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox +``` + +_آخری کمانڈ eth-security-toolbox کو ایک docker میں چلاتا ہے جس کی آپ کی موجودہ ڈائریکٹری تک رسائی ہے۔ آپ اپنے ہوسٹ سے فائلیں تبدیل کر سکتے ہیں، اور docker سے فائلوں پر ٹولز چلا سکتے ہیں_ + +docker کے اندر، چلائیں: + +```bash +solc-select 0.5.11 +cd /home/trufflecon/ +``` + +### pip کے ذریعے Manticore {#manticore-through-pip} + +```bash +pip3 install --user manticore +``` + +solc 0.5.11 تجویز کیا جاتا ہے۔ + +### ایک اسکرپٹ چلانا {#running-a-script} + +python 3 کے ساتھ ایک python اسکرپٹ چلانے کے لیے: + +```bash +python3 script.py +``` + +## ڈائنامک سمبولک ایگزیکیوشن کا تعارف {#introduction-to-dynamic-symbolic-execution} + +### مختصر طور پر ڈائنامک سمبولک ایگزیکیوشن {#dynamic-symbolic-execution-in-a-nutshell} + +ڈائنامک سمبولک ایگزیکیوشن (DSE) پروگرام کے تجزیے کی ایک تکنیک ہے جو اعلیٰ درجے کی سیمانٹک بیداری کے ساتھ اسٹیٹ اسپیس کو تلاش کرتی ہے۔ یہ تکنیک "پروگرام پاتھس" کی دریافت پر مبنی ہے، جسے `path predicates` کہلانے والے ریاضیاتی فارمولوں کے طور پر پیش کیا جاتا ہے۔ تصوراتی طور پر، یہ تکنیک دو مراحل میں پاتھ پریڈیکیٹس پر کام کرتی ہے: + +1. یہ پروگرام کے ان پٹ پر پابندیوں کا استعمال کرتے ہوئے تعمیر کیے جاتے ہیں۔ +2. یہ ایسے پروگرام ان پٹس پیدا کرنے کے لیے استعمال ہوتے ہیں جو متعلقہ پاتھس کو ایگزیکیوٹ کرنے کا سبب بنیں گے۔ + +یہ نقطہ نظر اس لحاظ سے کوئی غلط مثبت پیدا نہیں کرتا ہے کہ تمام شناخت شدہ پروگرام اسٹیٹس کو ٹھوس ایگزیکیوشن کے دوران ٹرگر کیا جا سکتا ہے۔ مثال کے طور پر، اگر تجزیہ میں کوئی انٹیجر اوور فلو ملتا ہے، تو اس کے دوبارہ پیدا کیے جانے کی ضمانت ہے۔ + +### پاتھ پریڈیکیٹ کی مثال {#path-predicate-example} + +DSE کیسے کام کرتا ہے اس کی بصیرت حاصل کرنے کے لیے، درج ذیل مثال پر غور کریں: + +```solidity +function f(uint a){ + + if (a == 65) { + // ایک بگ موجود ہے + } + +} +``` + +چونکہ `f()` میں دو پاتھس ہیں، اس لیے ایک DSE دو مختلف پاتھ پریڈیکیٹس بنائے گا: + +- پاتھ 1: `a == 65` +- پاتھ 2: `Not (a == 65)` + +ہر پاتھ پریڈیکیٹ ایک ریاضیاتی فارمولا ہے جسے [SMT solver](https://wikipedia.org/wiki/Satisfiability_modulo_theories) نامی ایک نام نہاد کو دیا جا سکتا ہے، جو مساوات کو حل کرنے کی کوشش کرے گا۔ `پاتھ 1` کے لیے، سولور کہے گا کہ پاتھ کو `a = 65` کے ساتھ تلاش کیا جا سکتا ہے۔ `پاتھ 2` کے لیے، سولور `a` کو 65 کے علاوہ کوئی بھی قدر دے سکتا ہے، مثال کے طور پر `a = 0`۔ + +### خصوصیات کی تصدیق کرنا {#verifying-properties} + +Manticore ہر پاتھ کے تمام ایگزیکیوشن پر مکمل کنٹرول کی اجازت دیتا ہے۔ نتیجے کے طور پر، یہ آپ کو تقریباً کسی بھی چیز پر من مانی پابندیاں شامل کرنے کی اجازت دیتا ہے۔ یہ کنٹرول کنٹریکٹ پر خصوصیات بنانے کی اجازت دیتا ہے۔ + +درج ذیل مثال پر غور کریں: + +```solidity +function unsafe_add(uint a, uint b) returns(uint c){ + c = a + b; // کوئی اوور فلو تحفظ نہیں + return c; +} +``` + +یہاں فنکشن میں تلاش کرنے کے لیے صرف ایک پاتھ ہے: + +- پاتھ 1: `c = a + b` + +Manticore کا استعمال کرتے ہوئے، آپ اوور فلو کی جانچ کر سکتے ہیں، اور پاتھ پریڈیکیٹ میں پابندیاں شامل کر سکتے ہیں: + +- `c = a + b AND (c < a OR c < b)` + +اگر `a` اور `b` کی ایسی ویلیویشن تلاش کرنا ممکن ہے جس کے لیے مذکورہ بالا پاتھ پریڈیکیٹ قابل عمل ہے، تو اس کا مطلب ہے کہ آپ کو ایک اوور فلو مل گیا ہے۔ مثال کے طور پر سولور ان پٹ `a = 10 , b = MAXUINT256` پیدا کر سکتا ہے۔ + +اگر آپ ایک فکسڈ ورژن پر غور کریں: + +```solidity +function safe_add(uint a, uint b) returns(uint c){ + c = a + b; + require(c>=a); + require(c>=b); + return c; +} +``` + +اوور فلو چیک کے ساتھ متعلقہ فارمولا ہوگا: + +- `c = a + b AND (c >= a) AND (c=>b) AND (c < a OR c < b)` + +اس فارمولے کو حل نہیں کیا جا سکتا؛ دوسرے لفظوں میں یہ ایک **ثبوت** ہے کہ `safe_add` میں، `c` ہمیشہ بڑھے گا۔ + +DSE اس طرح ایک طاقتور ٹول ہے، جو آپ کے کوڈ پر من مانی پابندیوں کی تصدیق کر سکتا ہے۔ + +## Manticore کے تحت چلانا {#running-under-manticore} + +ہم دیکھیں گے کہ Manticore API کے ساتھ ایک اسمارٹ کنٹریکٹ کو کیسے تلاش کیا جائے۔ ہدف درج ذیل اسمارٹ کنٹریکٹ [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol) ہے: + +```solidity +pragma solidity >=0.4.24 <0.6.0; + +contract Simple { + function f(uint a) payable public{ + if (a == 65) { + revert(); + } + } +} +``` + +### ایک اسٹینڈ الون ایکسپلوریشن چلائیں {#run-a-standalone-exploration} + +آپ درج ذیل کمانڈ کے ذریعے Manticore کو براہ راست اسمارٹ کنٹریکٹ پر چلا سکتے ہیں (`پروجیکٹ` ایک Solidity فائل، یا ایک پروجیکٹ ڈائریکٹری ہو سکتا ہے): + +```bash +$ manticore project +``` + +آپ کو اس طرح کے ٹیسٹ کیسز کا آؤٹ پٹ ملے گا (ترتیب بدل سکتی ہے): + +``` +... +... m.c.manticore:INFO: Generated testcase No. 0 - STOP +... m.c.manticore:INFO: Generated testcase No. 1 - REVERT +... m.c.manticore:INFO: Generated testcase No. 2 - RETURN +... m.c.manticore:INFO: Generated testcase No. 3 - REVERT +... m.c.manticore:INFO: Generated testcase No. 4 - STOP +... m.c.manticore:INFO: Generated testcase No. 5 - REVERT +... m.c.manticore:INFO: Generated testcase No. 6 - REVERT +... m.c.manticore:INFO: Results in /home/ethsec/workshops/Automated Smart Contracts Audit - TruffleCon 2018/manticore/examples/mcore_t6vi6ij3 +... +``` + +اضافی معلومات کے بغیر، Manticore نئے سمبولک +ٹرانزیکشنز کے ساتھ کنٹریکٹ کو اس وقت تک تلاش کرے گا جب تک کہ وہ کنٹریکٹ پر نئے پاتھس کو تلاش نہ کر لے۔ Manticore ایک ناکام ٹرانزیکشن کے بعد (مثال کے طور پر: ایک revert کے بعد) نئے ٹرانزیکشنز نہیں چلاتا ہے۔ + +Manticore معلومات کو ایک `mcore_*` ڈائریکٹری میں آؤٹ پٹ کرے گا۔ دیگر چیزوں کے علاوہ، آپ کو اس ڈائریکٹری میں ملے گا: + +- `global.summary`: کوریج اور کمپائلر وارننگز +- `test_XXXXX.summary`: کوریج، آخری ہدایت، فی ٹیسٹ کیس اکاؤنٹ بیلنس +- `test_XXXXX.tx`: فی ٹیسٹ کیس ٹرانزیکشنز کی تفصیلی فہرست + +یہاں Manticore کو 7 ٹیسٹ کیسز ملے ہیں، جو اس کے مطابق ہیں (فائل نام کی ترتیب بدل سکتی ہے): + +| | ٹرانزیکشن 0 | ٹرانزیکشن 1 | ٹرانزیکشن 2 | نتیجہ | +| :-------------------------------------------------------: | :--------------: | :------------------------: | -------------------------- | :----: | +| **test_00000000.tx** | کنٹریکٹ کی تخلیق | f(!=65) | f(!=65) | STOP | +| **test_00000001.tx** | کنٹریکٹ کی تخلیق | فال بیک فنکشن | | REVERT | +| **test_00000002.tx** | کنٹریکٹ کی تخلیق | | | RETURN | +| **test_00000003.tx** | کنٹریکٹ کی تخلیق | f(65) | | REVERT | +| **test_00000004.tx** | کنٹریکٹ کی تخلیق | f(!=65) | | STOP | +| **test_00000005.tx** | کنٹریکٹ کی تخلیق | f(!=65) | f(65) | REVERT | +| **test_00000006.tx** | کنٹریکٹ کی تخلیق | f(!=65) | فال بیک فنکشن | REVERT | + +_ایکسپلوریشن کا خلاصہ f(!=65) ظاہر کرتا ہے کہ f کو 65 سے مختلف کسی بھی قدر کے ساتھ کال کیا گیا ہے۔_ + +جیسا کہ آپ دیکھ سکتے ہیں، Manticore ہر کامیاب یا واپس کیے گئے ٹرانزیکشن کے لیے ایک منفرد ٹیسٹ کیس تیار کرتا ہے۔ + +اگر آپ تیز کوڈ ایکسپلوریشن چاہتے ہیں تو `--quick-mode` فلیگ کا استعمال کریں (یہ بگ ڈیٹیکٹرز، گیس کمپیوٹیشن، ... کو غیر فعال کر دیتا ہے) + +### API کے ذریعے ایک اسمارٹ کنٹریکٹ میں ہیرا پھیری کرنا {#manipulate-a-smart-contract-through-the-api} + +یہ سیکشن Manticore Python API کے ذریعے ایک اسمارٹ کنٹریکٹ میں ہیرا پھیری کرنے کے طریقے کی تفصیلات بیان کرتا ہے۔ آپ python ایکسٹینشن `*.py` کے ساتھ نئی فائل بنا سکتے ہیں اور اس فائل میں API کمانڈز (جن کی بنیادی باتیں ذیل میں بیان کی جائیں گی) کو شامل کرکے ضروری کوڈ لکھ سکتے ہیں اور پھر اسے `$ python3 *.py` کمانڈ کے ساتھ چلا سکتے ہیں۔ آپ ذیل میں دی گئی کمانڈز کو براہ راست python کنسول میں بھی ایگزیکیوٹ کر سکتے ہیں، کنسول چلانے کے لیے `$ python3` کمانڈ کا استعمال کریں۔ + +### اکاؤنٹس بنانا {#creating-accounts} + +سب سے پہلے آپ کو درج ذیل کمانڈز کے ساتھ ایک نئی بلاک چین شروع کرنی چاہیے: + +```python +from manticore.ethereum import ManticoreEVM + +m = ManticoreEVM() +``` + +ایک غیر کنٹریکٹ اکاؤنٹ [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) کا استعمال کرتے ہوئے بنایا جاتا ہے: + +```python +user_account = m.create_account(balance=1000) +``` + +ایک Solidity کنٹریکٹ [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract) کا استعمال کرتے ہوئے تعینات کیا جا سکتا ہے: + +```solidity +source_code = ''' +pragma solidity >=0.4.24 <0.6.0; +contract Simple { + function f(uint a) payable public{ + if (a == 65) { + revert(); + } + } +} +''' +# کنٹریکٹ شروع کریں +contract_account = m.solidity_create_contract(source_code, owner=user_account) +``` + +#### خلاصہ {#summary} + +- آپ [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) اور [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract) کے ساتھ صارف اور کنٹریکٹ اکاؤنٹس بنا سکتے ہیں۔ + +### ٹرانزیکشنز کو ایگزیکیوٹ کرنا {#executing-transactions} + +Manticore دو قسم کے ٹرانزیکشن کو سپورٹ کرتا ہے: + +- را ٹرانزیکشن: تمام فنکشنز کو تلاش کیا جاتا ہے +- نامزد ٹرانزیکشن: صرف ایک فنکشن کو تلاش کیا جاتا ہے + +#### را ٹرانزیکشن {#raw-transaction} + +ایک را ٹرانزیکشن [m.transaction](https://manticore.readthedocs.io/en/latest/evm.html?highlight=transaction#manticore.ethereum.ManticoreEVM.transaction) کا استعمال کرتے ہوئے ایگزیکیوٹ کیا جاتا ہے: + +```python +m.transaction(caller=user_account, + address=contract_account, + data=data, + value=value) +``` + +ٹرانزیکشن کا کالر، ایڈریس، ڈیٹا، یا ویلیو یا تو ٹھوس یا سمبولک ہو سکتا ہے: + +- [m.make_symbolic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_value#manticore.ethereum.ManticoreEVM.make_symbolic_value) ایک سمبولک ویلیو بناتا ہے۔ +- [m.make_symbolic_buffer(size)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_buffer#manticore.ethereum.ManticoreEVM.make_symbolic_buffer) ایک سمبولک بائٹ ایرے بناتا ہے۔ + +مثال کے طور پر: + +```python +symbolic_value = m.make_symbolic_value() +symbolic_data = m.make_symbolic_buffer(320) +m.transaction(caller=user_account, + address=contract_address, + data=symbolic_data, + value=symbolic_value) +``` + +اگر ڈیٹا سمبولک ہے، تو Manticore ٹرانزیکشن ایگزیکیوشن کے دوران کنٹریکٹ کے تمام فنکشنز کو تلاش کرے گا۔ فنکشن کا انتخاب کیسے کام کرتا ہے، یہ سمجھنے کے لیے [Hands on the Ethernaut CTF](https://blog.trailofbits.com/2017/11/06/hands-on-the-ethernaut-ctf/) مضمون میں فال بیک فنکشن کی وضاحت دیکھنا مددگار ہوگا۔ + +#### نامزد ٹرانزیکشن {#named-transaction} + +فنکشنز کو ان کے نام کے ذریعے ایگزیکیوٹ کیا جا سکتا ہے۔ +`f(uint var)` کو ایک سمبولک ویلیو کے ساتھ، user_account سے، اور 0 ایتھر کے ساتھ ایگزیکیوٹ کرنے کے لیے، استعمال کریں: + +```python +symbolic_var = m.make_symbolic_value() +contract_account.f(symbolic_var, caller=user_account, value=0) +``` + +اگر ٹرانزیکشن کی `value` کی وضاحت نہیں کی گئی ہے، تو یہ بطور ڈیفالٹ 0 ہے۔ + +#### خلاصہ {#summary-1} + +- ایک ٹرانزیکشن کے آرگومنٹس ٹھوس یا سمبولک ہو سکتے ہیں +- ایک را ٹرانزیکشن تمام فنکشنز کو تلاش کرے گا +- فنکشن کو ان کے نام سے کال کیا جا سکتا ہے + +### ورک اسپیس {#workspace} + +`m.workspace` وہ ڈائریکٹری ہے جو تمام تیار کردہ فائلوں کے لیے آؤٹ پٹ ڈائریکٹری کے طور پر استعمال ہوتی ہے: + +```python +print("نتائج {} میں ہیں".format(m.workspace)) +``` + +### ایکسپلوریشن کو ختم کریں {#terminate-the-exploration} + +ایکسپلوریشن کو روکنے کے لیے [m.finalize()](https://manticore.readthedocs.io/en/latest/evm.html?highlight=finalize#manticore.ethereum.ManticoreEVM.finalize) کا استعمال کریں۔ ایک بار یہ طریقہ کال ہو جانے کے بعد مزید کوئی ٹرانزیکشن نہیں بھیجا جانا چاہیے اور Manticore ہر تلاش کیے گئے پاتھ کے لیے ٹیسٹ کیسز تیار کرتا ہے۔ + +### خلاصہ: Manticore کے تحت چلانا {#summary-running-under-manticore} + +پچھلے تمام مراحل کو ایک ساتھ رکھنے پر، ہم حاصل کرتے ہیں: + +```python +from manticore.ethereum import ManticoreEVM + +m = ManticoreEVM() + +with open('example.sol') as f: + source_code = f.read() + +user_account = m.create_account(balance=1000) +contract_account = m.solidity_create_contract(source_code, owner=user_account) + +symbolic_var = m.make_symbolic_value() +contract_account.f(symbolic_var) + +print("نتائج {} میں ہیں".format(m.workspace)) +m.finalize() # ایکسپلوریشن کو روکیں +``` + +اوپر دیا گیا تمام کوڈ آپ [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) میں تلاش کر سکتے ہیں + +## تھروئنگ پاتھس حاصل کرنا {#getting-throwing-paths} + +اب ہم `f()` میں استثناء پیدا کرنے والے پاتھس کے لیے مخصوص ان پٹس تیار کریں گے۔ ہدف اب بھی درج ذیل اسمارٹ کنٹریکٹ [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol) ہے: + +```solidity +pragma solidity >=0.4.24 <0.6.0; +contract Simple { + function f(uint a) payable public{ + if (a == 65) { + revert(); + } + } +} +``` + +### اسٹیٹ کی معلومات کا استعمال {#using-state-information} + +ہر ایگزیکیوٹ ہونے والے پاتھ کی بلاک چین کی اپنی اسٹیٹ ہوتی ہے۔ ایک اسٹیٹ یا تو تیار ہوتی ہے یا اسے ختم کر دیا جاتا ہے، جس کا مطلب ہے کہ یہ ایک THROW یا REVERT ہدایت تک پہنچ جاتی ہے: + +- [m.ready_states](https://manticore.readthedocs.io/en/latest/states.html#accessing): تیار اسٹیٹس کی فہرست (انہوں نے REVERT/INVALID ایگزیکیوٹ نہیں کیا) +- [m.killed_states](https://manticore.readthedocs.io/en/latest/states.html#accessings): ختم شدہ اسٹیٹس کی فہرست +- [m.all_states](https://manticore.readthedocs.io/en/latest/states.html#accessings): تمام اسٹیٹس + +```python +for state in m.all_states: + # اسٹیٹ کے ساتھ کچھ کریں +``` + +آپ اسٹیٹ کی معلومات تک رسائی حاصل کر سکتے ہیں۔ مثال کے طور پر: + +- `state.platform.get_balance(account.address)`: اکاؤنٹ کا بیلنس +- `state.platform.transactions`: ٹرانزیکشنز کی فہرست +- `state.platform.transactions[-1].return_data`: آخری ٹرانزیکشن کے ذریعے واپس کیا گیا ڈیٹا + +آخری ٹرانزیکشن کے ذریعے واپس کیا گیا ڈیٹا ایک ایرے ہے، جسے ABI.deserialize کے ساتھ ایک ویلیو میں تبدیل کیا جا سکتا ہے، مثال کے طور پر: + +```python +data = state.platform.transactions[0].return_data +data = ABI.deserialize("uint", data) +``` + +### ٹیسٹ کیس کیسے تیار کریں {#how-to-generate-testcase} + +ٹیسٹ کیس تیار کرنے کے لیے [m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=generate_testcase#manticore.ethereum.ManticoreEVM.generate_testcase) کا استعمال کریں: + +```python +m.generate_testcase(state, 'BugFound') +``` + +### خلاصہ {#summary-2} + +- آپ m.all_states کے ساتھ اسٹیٹ پر اعادہ کر سکتے ہیں +- `state.platform.get_balance(account.address)` اکاؤنٹ کا بیلنس واپس کرتا ہے +- `state.platform.transactions` ٹرانزیکشنز کی فہرست واپس کرتا ہے +- `transaction.return_data` واپس کیا گیا ڈیٹا ہے +- `m.generate_testcase(state, name)` اسٹیٹ کے لیے ان پٹس تیار کرتا ہے + +### خلاصہ: تھروئنگ پاتھ حاصل کرنا {#summary-getting-throwing-path} + +```python +from manticore.ethereum import ManticoreEVM + +m = ManticoreEVM() + +with open('example.sol') as f: + source_code = f.read() + +user_account = m.create_account(balance=1000) +contract_account = m.solidity_create_contract(source_code, owner=user_account) + +symbolic_var = m.make_symbolic_value() +contract_account.f(symbolic_var) + +## چیک کریں کہ کیا کوئی ایگزیکیوشن REVERT یا INVALID کے ساتھ ختم ہوتا ہے + +for state in m.terminated_states: + last_tx = state.platform.transactions[-1] + if last_tx.result in ['REVERT', 'INVALID']: + print('تھرو ملا {}'.format(m.workspace)) + m.generate_testcase(state, 'ThrowFound') +``` + +اوپر دیا گیا تمام کوڈ آپ [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) میں تلاش کر سکتے ہیں + +_نوٹ کریں کہ ہم ایک بہت آسان اسکرپٹ تیار کر سکتے تھے، کیونکہ terminated_state کے ذریعے واپس کی گئی تمام اسٹیٹس کے نتیجے میں REVERT یا INVALID ہوتا ہے: اس مثال کا مقصد صرف یہ دکھانا تھا کہ API میں ہیرا پھیری کیسے کی جائے۔_ + +## پابندیاں شامل کرنا {#adding-constraints} + +ہم دیکھیں گے کہ ایکسپلوریشن کو کیسے محدود کیا جائے۔ ہم یہ فرض کریں گے کہ `f()` کی +دستاویزات میں کہا گیا ہے کہ فنکشن کو کبھی بھی `a == 65` کے ساتھ کال نہیں کیا جاتا، لہذا `a == 65` والا کوئی بھی بگ حقیقی بگ نہیں ہے۔ ہدف اب بھی درج ذیل اسمارٹ کنٹریکٹ [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol) ہے: + +```solidity +pragma solidity >=0.4.24 <0.6.0; +contract Simple { + function f(uint a) payable public{ + if (a == 65) { + revert(); + } + } +} +``` + +### آپریٹرز {#operators} + +[Operators](https://github.com/trailofbits/manticore/blob/master/manticore/core/smtlib/operators.py) ماڈیول پابندیوں کی ہیرا پھیری میں سہولت فراہم کرتا ہے، دیگر چیزوں کے علاوہ یہ فراہم کرتا ہے: + +- Operators.AND, +- Operators.OR, +- Operators.UGT (غیر دستخط شدہ سے بڑا), +- Operators.UGE (غیر دستخط شدہ سے بڑا یا برابر)، +- Operators.ULT (غیر دستخط شدہ سے کم)، +- Operators.ULE (غیر دستخط شدہ سے کم یا برابر)۔ + +ماڈیول کو امپورٹ کرنے کے لیے درج ذیل کا استعمال کریں: + +```python +from manticore.core.smtlib import Operators +``` + +`Operators.CONCAT` ایک ایرے کو ایک ویلیو سے جوڑنے کے لیے استعمال کیا جاتا ہے۔ مثال کے طور پر، ایک ٹرانزیکشن کے return_data کو ایک ویلیو میں تبدیل کرنے کی ضرورت ہے تاکہ اسے دوسری ویلیو کے خلاف چیک کیا جا سکے: + +```python +last_return = Operators.CONCAT(256, *last_return) +``` + +### پابندیاں {#state-constraint} + +آپ پابندیوں کا استعمال عالمی سطح پر یا کسی مخصوص اسٹیٹ کے لیے کر سکتے ہیں۔ + +#### عالمی پابندی {#state-constraint} + +عالمی پابندی شامل کرنے کے لیے `m.constrain(constraint)` کا استعمال کریں۔ +مثال کے طور پر، آپ ایک سمبولک ایڈریس سے ایک کنٹریکٹ کو کال کر سکتے ہیں، اور اس ایڈریس کو مخصوص ویلیوز تک محدود کر سکتے ہیں: + +```python +symbolic_address = m.make_symbolic_value() +m.constraint(Operators.OR(symbolic == 0x41, symbolic_address == 0x42)) +m.transaction(caller=user_account, + address=contract_account, + data=m.make_symbolic_buffer(320), + value=0) +``` + +#### اسٹیٹ کی پابندی {#state-constraint} + +کسی مخصوص اسٹیٹ میں پابندی شامل کرنے کے لیے [state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/states.html?highlight=StateBase#manticore.core.state.StateBase.constrain) کا استعمال کریں۔ +اس کا استعمال اسٹیٹ کو اس کی ایکسپلوریشن کے بعد محدود کرنے کے لیے کیا جا سکتا ہے تاکہ اس پر کچھ خصوصیت کی جانچ کی جا سکے۔ + +### پابندی کی جانچ کرنا {#checking-constraint} + +یہ جاننے کے لیے کہ کیا کوئی پابندی اب بھی قابل عمل ہے، `solver.check(state.constraints)` کا استعمال کریں۔ +مثال کے طور پر، درج ذیل `symbolic_value` کو 65 سے مختلف ہونے پر مجبور کرے گا اور یہ جانچے گا کہ کیا اسٹیٹ اب بھی قابل عمل ہے: + +```python +state.constrain(symbolic_var != 65) +if solver.check(state.constraints): + # اسٹیٹ قابل عمل ہے +``` + +### خلاصہ: پابندیاں شامل کرنا {#summary-adding-constraints} + +پچھلے کوڈ میں پابندی شامل کرنے پر، ہم حاصل کرتے ہیں: + +```python +from manticore.ethereum import ManticoreEVM +from manticore.core.smtlib.solver import Z3Solver + +solver = Z3Solver.instance() + +m = ManticoreEVM() + +with open("example.sol") as f: + source_code = f.read() + +user_account = m.create_account(balance=1000) +contract_account = m.solidity_create_contract(source_code, owner=user_account) + +symbolic_var = m.make_symbolic_value() +contract_account.f(symbolic_var) + +no_bug_found = True + +## چیک کریں کہ کیا کوئی ایگزیکیوشن REVERT یا INVALID کے ساتھ ختم ہوتا ہے + +for state in m.terminated_states: + last_tx = state.platform.transactions[-1] + if last_tx.result in ['REVERT', 'INVALID']: + # ہم اس پاتھ پر غور نہیں کرتے جہاں a == 65 ہے + condition = symbolic_var != 65 + if m.generate_testcase(state, name="BugFound", only_if=condition): + print(f'بگ ملا، نتائج {m.workspace} میں ہیں') + no_bug_found = False + +if no_bug_found: + print(f'کوئی بگ نہیں ملا') +``` + +اوپر دیا گیا تمام کوڈ آپ [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) میں تلاش کر سکتے ہیں diff --git a/public/content/translations/ur/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/ur/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md new file mode 100644 index 00000000000..f898caf8f19 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md @@ -0,0 +1,233 @@ +--- +title: "اسمارٹ کنٹریکٹ بگز کو تلاش کرنے کے لیے Slither کا استعمال کیسے کریں" +description: "اسمارٹ کنٹریکٹس میں بگز کو خود بخود تلاش کرنے کے لیے Slither کا استعمال کیسے کریں" +author: Trailofbits +lang: ur-in +tags: [ "solidity", "اسمارٹ معاہدات", "سیکورٹی", "testing" ] +skill: advanced +published: 2020-06-09 +source: Building secure contracts +sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither +--- + +## Slither کا استعمال کیسے کریں {#how-to-use-slither} + +اس ٹیوٹوریل کا مقصد یہ دکھانا ہے کہ اسمارٹ کنٹریکٹس میں بگز کو خود بخود تلاش کرنے کے لیے Slither کا استعمال کیسے کیا جائے۔ + +- [انسٹالیشن](#installation) +- [کمانڈ لائن کا استعمال](#command-line) +- [اسٹیٹک تجزیہ کا تعارف](#static-analysis): اسٹیٹک تجزیہ کا مختصر تعارف +- [API](#api-basics): پائتھن API کی تفصیل + +## انسٹالیشن {#installation} + +Slither کے لیے Python >= 3.6 درکار ہے۔ اسے pip کے ذریعے یا docker کا استعمال کرکے انسٹال کیا جاسکتا ہے۔ + +pip کے ذریعے Slither: + +```bash +pip3 install --user slither-analyzer +``` + +docker کے ذریعے Slither: + +```bash +docker pull trailofbits/eth-security-toolbox +docker run -it -v "$PWD":/home/trufflecon trailofbits/eth-security-toolbox +``` + +_آخری کمانڈ eth-security-toolbox کو ایک docker میں چلاتا ہے جس کی آپ کی موجودہ ڈائریکٹری تک رسائی ہے۔ آپ اپنے ہوسٹ سے فائلیں تبدیل کر سکتے ہیں، اور docker سے فائلوں پر ٹولز چلا سکتے ہیں_ + +docker کے اندر، چلائیں: + +```bash +solc-select 0.5.11 +cd /home/trufflecon/ +``` + +### ایک اسکرپٹ چلانا {#running-a-script} + +python 3 کے ساتھ ایک python اسکرپٹ چلانے کے لیے: + +```bash +python3 script.py +``` + +### کمانڈ لائن {#command-line} + +**کمانڈ لائن بمقابلہ صارف کے ذریعے متعین کردہ اسکرپٹس۔** Slither پہلے سے متعین ڈیٹیکٹرز کے ایک سیٹ کے ساتھ آتا ہے جو بہت سے عام بگز کو تلاش کرتے ہیں۔ کمانڈ لائن سے Slither کو کال کرنے پر تمام ڈیٹیکٹرز چل جائیں گے، اسٹیٹک تجزیہ کے تفصیلی علم کی ضرورت نہیں: + +```bash +slither project_paths +``` + +ڈیٹیکٹرز کے علاوہ، Slither میں اس کے [پرنٹرز](https://github.com/crytic/slither#printers) اور [ٹولز](https://github.com/crytic/slither#tools) کے ذریعے کوڈ ریویو کی صلاحیتیں ہیں۔ + +پرائیویٹ ڈیٹیکٹرز اور GitHub انٹیگریشن تک رسائی حاصل کرنے کے لیے [crytic.io](https://github.com/crytic) کا استعمال کریں۔ + +## اسٹیٹک تجزیہ {#static-analysis} + +Slither اسٹیٹک تجزیہ فریم ورک کی صلاحیتوں اور ڈیزائن کو بلاگ پوسٹس ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/), [2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) اور ایک [تعلیمی مقالے](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf) میں بیان کیا گیا ہے۔ + +اسٹیٹک تجزیہ مختلف اقسام میں موجود ہے۔ آپ کو شاید اس بات کا احساس ہوگا کہ [clang](https://clang-analyzer.llvm.org/) اور [gcc](https://lwn.net/Articles/806099/) جیسے کمپائلرز ان تحقیقی تکنیکوں پر انحصار کرتے ہیں، لیکن یہ ([Infer](https://fbinfer.com/), [CodeClimate](https://codeclimate.com/), [FindBugs](http://findbugs.sourceforge.net/) اور [Frama-C](https://frama-c.com/) اور [Polyspace](https://www.mathworks.com/products/polyspace.html) جیسے رسمی طریقوں پر مبنی ٹولز) کی بھی بنیاد ہے۔ + +ہم یہاں اسٹیٹک تجزیہ کی تکنیکوں اور محققین کا جامع طور پر جائزہ نہیں لیں گے۔ اس کے بجائے، ہم اس بات پر توجہ مرکوز کریں گے کہ Slither کے کام کرنے کے طریقے کو سمجھنے کے لیے کیا ضروری ہے تاکہ آپ بگز کو تلاش کرنے اور کوڈ کو سمجھنے کے لیے اس کا زیادہ مؤثر طریقے سے استعمال کر سکیں۔ + +- [کوڈ کی نمائندگی](#code-representation) +- [کوڈ کا تجزیہ](#analysis) +- [درمیانی نمائندگی](#intermediate-representation) + +### کوڈ کی نمائندگی {#code-representation} + +ڈائنامک تجزیہ کے برعکس، جو ایک ہی ایگزیکیوشن پاتھ کے بارے میں استدلال کرتا ہے، اسٹیٹک تجزیہ ایک ہی وقت میں تمام پاتھس کے بارے میں استدلال کرتا ہے۔ ایسا کرنے کے لیے، یہ ایک مختلف کوڈ کی نمائندگی پر انحصار کرتا ہے۔ دو سب سے عام ہیں ایبسٹریکٹ سنٹیکس ٹری (AST) اور کنٹرول فلو گراف (CFG)۔ + +### ایبسٹریکٹ سنٹیکس ٹریز (AST) {#abstract-syntax-trees-ast} + +AST کا استعمال ہر بار کیا جاتا ہے جب کمپائلر کوڈ کو پارس کرتا ہے۔ یہ شاید سب سے بنیادی ڈھانچہ ہے جس پر اسٹیٹک تجزیہ کیا جا سکتا ہے۔ + +مختصراً، ایک AST ایک سٹرکچرڈ ٹری ہے جہاں، عام طور پر، ہر لیف میں ایک ویری ایبل یا ایک کانسٹنٹ ہوتا ہے اور انٹرنل نوڈز آپرینڈز یا کنٹرول فلو آپریشنز ہوتے ہیں۔ درج ذیل کوڈ پر غور کریں: + +```solidity +function safeAdd(uint a, uint b) pure internal returns(uint){ + if(a + b <= a){ + revert(); + } + return a + b; +} +``` + +متعلقہ AST کو اس میں دکھایا گیا ہے: + +![AST](./ast.png) + +Slither, solc کے ذریعے ایکسپورٹ کردہ AST کا استعمال کرتا ہے۔ + +بنانے میں آسان ہونے کے باوجود، AST ایک نیسٹڈ سٹرکچر ہے۔ بعض اوقات، اس کا تجزیہ کرنا سب سے سیدھا نہیں ہوتا ہے۔ مثال کے طور پر، ایکسپریشن `a + b <= a` کے ذریعے استعمال ہونے والے آپریشنز کی شناخت کے لیے، آپ کو پہلے `<=` اور پھر `+` کا تجزیہ کرنا ہوگا۔ ایک عام طریقہ نام نہاد وزیٹر پیٹرن کا استعمال کرنا ہے، جو ٹری کے ذریعے ریکرسیولی نیویگیٹ کرتا ہے۔ Slither میں [`ExpressionVisitor`](https://github.com/crytic/slither/blob/master/slither/visitors/expression/expression.py) میں ایک عام وزیٹر موجود ہے۔ + +درج ذیل کوڈ `ExpressionVisitor` کا استعمال کرتا ہے یہ پتہ لگانے کے لیے کہ آیا ایکسپریشن میں کوئی ایڈیشن ہے: + +```python +from slither.visitors.expression.expression import ExpressionVisitor +from slither.core.expressions.binary_operation import BinaryOperationType + +class HasAddition(ExpressionVisitor): + + def result(self): + return self._result + + def _post_binary_operation(self, expression): + if expression.type == BinaryOperationType.ADDITION: + self._result = True + +visitor = HasAddition(expression) # ایکسپریشن وہ ایکسپریشن ہے جس کی جانچ کی جانی ہے +print(f'The expression {expression} has a addition: {visitor.result()}') +``` + +### کنٹرول فلو گراف (CFG) {#control-flow-graph-cfg} + +دوسری سب سے عام کوڈ کی نمائندگی کنٹرول فلو گراف (CFG) ہے۔ جیسا کہ اس کے نام سے ظاہر ہے، یہ ایک گراف پر مبنی نمائندگی ہے جو تمام ایگزیکیوشن پاتھس کو ظاہر کرتی ہے۔ ہر نوڈ میں ایک یا ایک سے زیادہ ہدایات ہوتی ہیں۔ گراف میں ایجز کنٹرول فلو آپریشنز (if/then/else, loop, وغیرہ) کی نمائندگی کرتے ہیں۔ ہماری پچھلی مثال کا CFG یہ ہے: + +![CFG](./cfg.png) + +CFG وہ نمائندگی ہے جس کے اوپر زیادہ تر تجزیے بنائے جاتے ہیں۔ + +بہت سی دوسری کوڈ کی نمائندگیاں موجود ہیں۔ ہر نمائندگی کے اپنے فائدے اور نقصانات ہیں اس تجزیہ کے مطابق جو آپ کرنا چاہتے ہیں۔ + +### تجزیہ {#analysis} + +سب سے آسان قسم کے تجزیے جو آپ Slither کے ساتھ کر سکتے ہیں وہ سنٹیکٹک تجزیے ہیں۔ + +### سنٹیکس کا تجزیہ {#syntax-analysis} + +Slither پیٹرن میچنگ جیسے طریقے کا استعمال کرتے ہوئے تضادات اور خامیوں کو تلاش کرنے کے لیے کوڈ کے مختلف اجزاء اور ان کی نمائندگی کے ذریعے نیویگیٹ کر سکتا ہے۔ + +مثال کے طور پر درج ذیل ڈیٹیکٹرز سنٹیکس سے متعلقہ مسائل کو تلاش کرتے ہیں: + +- [اسٹیٹ ویری ایبل شیڈونگ](https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing): تمام اسٹیٹ ویری ایبلز پر ایٹریٹ کرتا ہے اور چیک کرتا ہے کہ آیا کوئی موروثی کنٹریکٹ سے کسی ویری ایبل کو شیڈو کرتا ہے ([state.py#L51-L62](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/shadowing/state.py#L51-L62)) + +- [غلط ERC20 انٹرفیس](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-erc20-interface): غلط ERC20 فنکشن سگنیچرز کو تلاش کرتا ہے ([incorrect_erc20_interface.py#L34-L55](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/erc/incorrect_erc20_interface.py#L34-L55)) + +### سیمنٹک تجزیہ {#semantic-analysis} + +سنٹیکس تجزیہ کے برعکس، ایک سیمنٹک تجزیہ زیادہ گہرائی میں جائے گا اور کوڈ کے "معنی" کا تجزیہ کرے گا۔ اس فیملی میں کچھ وسیع اقسام کے تجزیے شامل ہیں۔ یہ زیادہ طاقتور اور مفید نتائج کی طرف لے جاتے ہیں، لیکن لکھنے میں بھی زیادہ پیچیدہ ہیں۔ + +سیمنٹک تجزیے سب سے جدید کمزوریوں کا پتہ لگانے کے لیے استعمال کیے جاتے ہیں۔ + +#### ڈیٹا کا انحصاری تجزیہ {#fixed-point-computation} + +ایک ویری ایبل `variable_a` کو `variable_b` پر ڈیٹا-ڈیپینڈینٹ کہا جاتا ہے اگر کوئی ایسا پاتھ ہے جس کے لیے `variable_a` کی قدر `variable_b` سے متاثر ہوتی ہے۔ + +درج ذیل کوڈ میں، `variable_a`، `variable_b` پر منحصر ہے: + +```solidity +// ... +variable_a = variable_b + 1; +``` + +Slither بلٹ ان [ڈیٹا ڈیپینڈینسی](https://github.com/crytic/slither/wiki/data-dependency) کی صلاحیتوں کے ساتھ آتا ہے، اس کی درمیانی نمائندگی کی بدولت (جس پر بعد کے سیکشن میں بحث کی گئی ہے)۔ + +ڈیٹا ڈیپینڈینسی کے استعمال کی ایک مثال [خطرناک سخت مساوات ڈیٹیکٹر](https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities) میں مل سکتی ہے۔ یہاں Slither ایک خطرناک قدر کے ساتھ سخت مساوات کے موازنہ کو تلاش کرے گا ([incorrect_strict_equality.py#L86-L87](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L86-L87))، اور صارف کو مطلع کرے گا کہ اسے کسی حملہ آور کو کنٹریکٹ میں پھنسانے سے روکنے کے لیے `==` کے بجائے `>=` یا `<=` کا استعمال کرنا چاہیے۔ دیگر چیزوں کے علاوہ، ڈیٹیکٹر `balanceOf(address)` ([incorrect_strict_equality.py#L63-L64](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L63-L64)) پر کال کی واپسی کی قدر کو خطرناک سمجھے گا، اور اس کے استعمال کو ٹریک کرنے کے لیے ڈیٹا ڈیپینڈینسی انجن کا استعمال کرے گا۔ + +#### فکسڈ پوائنٹ کمپیوٹیشن {#fixed-point-computation} + +اگر آپ کا تجزیہ CFG کے ذریعے نیویگیٹ کرتا ہے اور ایجز کی پیروی کرتا ہے، تو آپ کو پہلے سے دیکھے گئے نوڈس نظر آنے کا امکان ہے۔ مثال کے طور پر، اگر ایک لوپ کو نیچے دکھایا گیا ہے: + +```solidity +for(uint i; i < range; ++){ + variable_a += 1 +} +``` + +آپ کے تجزیہ کو یہ جاننے کی ضرورت ہوگی کہ کب رکنا ہے۔ یہاں دو اہم حکمت عملیاں ہیں: (1) ہر نوڈ پر ایک محدود تعداد میں ایٹریٹ کریں، (2) ایک نام نہاد _فکس پوائنٹ_ کا حساب لگائیں۔ ایک فکس پوائنٹ کا بنیادی طور پر مطلب ہے کہ اس نوڈ کا تجزیہ کوئی بامعنی معلومات فراہم نہیں کرتا ہے۔ + +فکس پوائنٹ کے استعمال کی ایک مثال ری اینٹرینسی ڈیٹیکٹرز میں مل سکتی ہے: Slither نوڈس کو ایکسپلور کرتا ہے، اور ایکسٹرنل کالز، اسٹوریج میں لکھنے اور پڑھنے کی تلاش کرتا ہے۔ ایک بار جب یہ فکس پوائنٹ ([reentrancy.py#L125-L131](https://github.com/crytic/slither/blob/master/slither/detectors/reentrancy/reentrancy.py#L125-L131)) تک پہنچ جاتا ہے، تو یہ ایکسپلوریشن کو روک دیتا ہے، اور نتائج کا تجزیہ کرتا ہے یہ دیکھنے کے لیے کہ آیا ری اینٹرینسی موجود ہے، مختلف ری اینٹرینسی پیٹرنز ([reentrancy_benign.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_benign.py), [reentrancy_read_before_write.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_read_before_write.py), [reentrancy_eth.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_eth.py)) کے ذریعے۔ + +موثر فکسڈ پوائنٹ کمپیوٹیشن کا استعمال کرتے ہوئے تجزیے لکھنے کے لیے اس بات کی اچھی سمجھ کی ضرورت ہوتی ہے کہ تجزیہ اپنی معلومات کو کیسے پھیلاتا ہے۔ + +### درمیانی نمائندگی {#intermediate-representation} + +ایک درمیانی نمائندگی (IR) ایک ایسی زبان ہے جو اصل زبان کے مقابلے میں اسٹیٹک تجزیہ کے لیے زیادہ موزوں ہو۔ Slither, Solidity کو اپنے IR: [SlithIR](https://github.com/crytic/slither/wiki/SlithIR) میں ترجمہ کرتا ہے۔ + +اگر آپ صرف بنیادی چیکس لکھنا چاہتے ہیں تو SlithIR کو سمجھنا ضروری نہیں ہے۔ تاہم، اگر آپ جدید سیمنٹک تجزیے لکھنے کا ارادہ رکھتے ہیں تو یہ کام آئے گا۔ [SlithIR](https://github.com/crytic/slither/wiki/Printer-documentation#slithir) اور [SSA](https://github.com/crytic/slither/wiki/Printer-documentation#slithir-ssa) پرنٹرز آپ کو یہ سمجھنے میں مدد کریں گے کہ کوڈ کا ترجمہ کیسے ہوتا ہے۔ + +## API کی بنیادی باتیں {#api-basics} + +Slither میں ایک API ہے جو آپ کو کنٹریکٹ اور اس کے فنکشنز کی بنیادی خصوصیات کو ایکسپلور کرنے دیتا ہے۔ + +کوڈبیس کو لوڈ کرنے کے لیے: + +```python +from slither import Slither +slither = Slither('/path/to/project') + +``` + +### کنٹریکٹس اور فنکشنز کو ایکسپلور کرنا {#exploring-contracts-and-functions} + +ایک `Slither` آبجیکٹ میں ہوتا ہے: + +- `contracts (list(Contract)`: کنٹریکٹس کی فہرست +- `contracts_derived (list(Contract)`: ان کنٹریکٹس کی فہرست جو کسی دوسرے کنٹریکٹ سے موروثی نہیں ہیں (کنٹریکٹس کا سب سیٹ) +- `get_contract_from_name (str)`: اس کے نام سے ایک کنٹریکٹ واپس کریں + +ایک `Contract` آبجیکٹ میں ہوتا ہے: + +- `name (str)`: کنٹریکٹ کا نام +- `functions (list(Function))`: فنکشنز کی فہرست +- `modifiers (list(Modifier))`: فنکشنز کی فہرست +- `all_functions_called (list(Function/Modifier))`: کنٹریکٹ کے ذریعے پہنچنے کے قابل تمام اندرونی فنکشنز کی فہرست +- `inheritance (list(Contract))`: موروثی کنٹریکٹس کی فہرست +- `get_function_from_signature (str)`: اس کے سگنیچر سے ایک فنکشن واپس کریں +- `get_modifier_from_signature (str)`: اس کے سگنیچر سے ایک موڈیفائر واپس کریں +- `get_state_variable_from_name (str)`: اس کے نام سے ایک اسٹیٹ ویری ایبل واپس کریں + +ایک `Function` یا `Modifier` آبجیکٹ میں ہوتا ہے: + +- `name (str)`: فنکشن کا نام +- `contract (contract)`: وہ کنٹریکٹ جہاں فنکشن کا اعلان کیا گیا ہے +- `nodes (list(Node))`: فنکشن/موڈیفائر کے CFG کو بنانے والے نوڈس کی فہرست +- `entry_point (Node)`: CFG کا انٹری پوائنٹ +- `variables_read (list(Variable))`: پڑھے گئے ویری ایبلز کی فہرست +- `variables_written (list(Variable))`: لکھے گئے ویری ایبلز کی فہرست +- `state_variables_read (list(StateVariable))`: پڑھے گئے اسٹیٹ ویری ایبلز کی فہرست (ویری ایبلز`ریڈ کا سب سیٹ) +- `state_variables_written (list(StateVariable))`: لکھے گئے اسٹیٹ ویری ایبلز کی فہرست (ویری ایبلز`رٹن کا سب سیٹ) diff --git a/public/content/translations/ur/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/ur/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md new file mode 100644 index 00000000000..b74d5fc2bbe --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -0,0 +1,81 @@ +--- +title: "Tellor کو اپنے اوریکل کے طور پر کیسے سیٹ اپ کریں" +description: "Tellor اوریکل کو اپنے پروٹوکول میں ضم کرنے کے ساتھ شروع کرنے کے لئے ایک گائیڈ" +author: "Tellor" +lang: ur-in +tags: [ "solidity", "اسمارٹ معاہدات", "اوریکلز" ] +skill: beginner +published: 2021-06-29 +source: Tellor Docs +sourceUrl: https://docs.tellor.io/tellor/ +--- + +پاپ کوئز: آپ کا پروٹوکول تقریباً ختم ہو چکا ہے، لیکن اسے آف چین ڈیٹا تک رسائی حاصل کرنے کے لیے ایک اوریکل کی ضرورت ہے... آپ کیا کرتے ہیں؟ + +## (نرم) شرائط {#soft-prerequisites} + +اس پوسٹ کا مقصد اوریکل فیڈ تک رسائی کو ہر ممکن حد تک آسان اور سیدھا بنانا ہے۔ یہ کہنے کے بعد، ہم اوریکل پہلو پر توجہ مرکوز کرنے کے لئے آپ کی کوڈنگ کی مہارت کی سطح کے بارے میں مندرجہ ذیل فرض کر رہے ہیں۔ + +مفروضے: + +- آپ ٹرمینل نیویگیٹ کر سکتے ہیں +- آپ نے npm انسٹال کیا ہے +- آپ جانتے ہیں کہ انحصار کو منظم کرنے کے لئے npm کا استعمال کیسے کریں + +Tellor ایک لائیو اور اوپن سورس اوریکل ہے جو نفاذ کے لیے تیار ہے۔ یہ ابتدائی رہنما یہاں اس آسانی کو ظاہر کرنے کے لیے ہے جس کے ساتھ کوئی بھی Tellor کے ساتھ شروع کر سکتا ہے، جو آپ کے پروجیکٹ کو مکمل طور پر غیر مرکزی اور سنسر شپ سے مزاحم اوریکل فراہم کرتا ہے۔ + +## جائزہ {#overview} + +Tellor ایک اوریکل سسٹم ہے جہاں پارٹیاں آف چین ڈیٹا پوائنٹ (مثال کے طور پر، BTC/USD) کی قیمت کی درخواست کر سکتی ہیں اور رپورٹرز اس قیمت کو آن چین ڈیٹا بینک میں شامل کرنے کے لیے مقابلہ کرتے ہیں، جو تمام Ethereum اسمارٹ کنٹریکٹس کے ذریعے قابل رسائی ہے۔ اس ڈیٹا بینک کے ان پٹس کو اسٹیک شدہ رپورٹرز کے نیٹ ورک کے ذریعے محفوظ کیا جاتا ہے۔ Tellor کرپٹو-اقتصادی ترغیبی میکانزم کا استعمال کرتا ہے، رپورٹرز کے ذریعے ایماندارانہ ڈیٹا جمع کرانے پر انعام دیتا ہے اور Tellor کے ٹوکن، Tributes (TRB) کے اجراء اور ایک تنازعہ کے میکانزم کے ذریعے برے اداکاروں کو سزا دیتا ہے۔ + +اس ٹیوٹوریل میں ہم اس پر بات کریں گے: + +- ابتدائی ٹول کٹ ترتیب دینا جس کی آپ کو شروع کرنے اور چلانے کی ضرورت ہوگی۔ +- ایک سادہ مثال کے ذریعے چلیں۔ +- ان نیٹ ورکس کے ٹیسٹ نیٹ پتے درج کریں جن پر آپ فی الحال Tellor کی جانچ کر سکتے ہیں۔ + +## UsingTellor کا استعمال {#usingtellor} + +سب سے پہلی چیز جو آپ کرنا چاہیں گے وہ ہے Tellor کو اپنے اوریکل کے طور پر استعمال کرنے کے لیے ضروری بنیادی ٹولز کو انسٹال کرنا۔ Tellor یوزر کنٹریکٹس کو انسٹال کرنے کے لیے [اس پیکیج](https://github.com/tellor-io/usingtellor) کا استعمال کریں: + +`npm install usingtellor` + +ایک بار انسٹال ہونے کے بعد یہ آپ کے کنٹریکٹس کو 'UsingTellor' کنٹریکٹ سے فنکشنز وراثت میں حاصل کرنے کی اجازت دے گا۔ + +بہت خوب! اب جب کہ آپ کے پاس ٹولز تیار ہیں، آئیے ایک سادہ سی مشق سے گزرتے ہیں جہاں ہم بٹ کوائن کی قیمت حاصل کرتے ہیں: + +### BTC/USD مثال {#btcusd-example} + +UsingTellor کنٹریکٹ کو وراثت میں حاصل کریں، Tellor ایڈریس کو کنسٹرکٹر آرگیومنٹ کے طور پر پاس کرتے ہوئے: + +یہاں ایک مثال ہے: + +```solidity +import "usingtellor/contracts/UsingTellor.sol"; + +contract PriceContract is UsingTellor { + uint256 public btcPrice; + + //اس کنٹریکٹ کو اب UsingTellor کے تمام فنکشنز تک رسائی حاصل ہے + +constructor(address payable _tellorAddress) UsingTellor(_tellorAddress) public {} + +function setBtcPrice() public { + bytes memory _b = abi.encode("SpotPrice",abi.encode("btc","usd")); + bytes32 _queryId = keccak256(_b); + + uint256 _timestamp; + bytes _value; + + (_value, _timestamp) = getDataBefore(_queryId, block.timestamp - 15 minutes); + + btcPrice = abi.decode(_value,(uint256)); + } +} +``` + +کنٹریکٹ ایڈریسز کی مکمل فہرست کے لیے [یہاں](https://docs.tellor.io/tellor/the-basics/contracts-reference) رجوع کریں۔ + +استعمال میں آسانی کے لیے، UsingTellor ریپو آسان انضمام کے لیے [Tellor Playground](https://github.com/tellor-io/TellorPlayground) کنٹریکٹ کے ایک ورژن کے ساتھ آتا ہے۔ مددگار فنکشنز کی فہرست کے لیے [یہاں](https://github.com/tellor-io/sampleUsingTellor#tellor-playground) دیکھیں۔ + +Tellor اوریکل کے زیادہ مضبوط نفاذ کے لیے، دستیاب فنکشنز کی مکمل فہرست [یہاں](https://github.com/tellor-io/usingtellor/blob/master/README.md) دیکھیں۔ diff --git a/public/content/translations/ur/developers/tutorials/how-to-view-nft-in-metamask/index.md b/public/content/translations/ur/developers/tutorials/how-to-view-nft-in-metamask/index.md new file mode 100644 index 00000000000..09f8c7fe1d4 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-view-nft-in-metamask/index.md @@ -0,0 +1,33 @@ +--- +title: "اپنے والٹ میں اپنا NFT کیسے دیکھیں (NFT ٹیوٹوریل سیریز کا حصہ 3/3)" +description: "یہ ٹیوٹوریل بیان کرتا ہے کہ MetaMask پر موجودہ NFT کو کیسے دیکھیں!" +author: "Sumi Mudgil" +tags: [ "ERC-721", "Alchemy", "Solidity" ] +skill: beginner +lang: ur-in +published: 2021-04-22 +--- + +یہ ٹیوٹوریل NFT ٹیوٹوریل سیریز کا حصہ 3/3 ہے، جہاں ہم اپنا نیا منٹ کیا ہوا NFT دیکھتے ہیں۔ تاہم، آپ MetaMask کا استعمال کرتے ہوئے کسی بھی ERC-721 ٹوکن کے لیے عمومی ٹیوٹوریل استعمال کر سکتے ہیں، بشمول Mainnet یا کسی بھی testnet پر۔ اگر آپ Ethereum پر اپنا NFT منٹ کرنے کا طریقہ سیکھنا چاہتے ہیں، تو آپ کو [حصہ 1 NFT اسمارٹ کنٹریکٹ کو کیسے لکھیں اور ڈیپلوئے کریں](/developers/tutorials/how-to-write-and-deploy-an-nft) دیکھنا چاہئے! + +مبارک ہو! آپ ہماری NFT ٹیوٹوریل سیریز کے سب سے مختصر اور آسان ترین حصے تک پہنچ گئے ہیں — اپنے نئے منٹ کیے گئے NFT کو ورچوئل والٹ پر کیسے دیکھیں۔ ہم اس مثال کے لیے MetaMask کا استعمال کریں گے کیونکہ ہم نے پچھلے دو حصوں میں اسی کا استعمال کیا تھا۔ + +ایک شرط کے طور پر، آپ کے موبائل پر MetaMask پہلے سے انسٹال ہونا چاہیے، اور اس میں وہ اکاؤنٹ شامل ہونا چاہیے جس میں آپ نے اپنا NFT منٹ کیا ہے — آپ ایپ کو [iOS](https://apps.apple.com/us/app/metamask-blockchain-wallet/id1438144202) یا [Android](https://play.google.com/store/apps/details?id=io.metamask&hl=en_US&gl=US) پر مفت حاصل کر سکتے ہیں۔ + +## مرحلہ 1: اپنا نیٹ ورک Sepolia پر سیٹ کریں {#set-network-to-sepolia} + +ایپ کے اوپری حصے میں، "والٹ" بٹن دبائیں، جس کے بعد آپ کو ایک نیٹ ورک منتخب کرنے کے لیے کہا جائے گا۔ چونکہ ہمارا NFT Sepolia نیٹ ورک پر منٹ کیا گیا تھا، آپ اپنے نیٹ ورک کے طور پر Sepolia کو منتخب کرنا چاہیں گے۔ + +![MetaMask موبائل پر Sepolia کو اپنے نیٹ ورک کے طور پر کیسے سیٹ کریں](./goerliMetamask.gif) + +## مرحلہ 2: MetaMask میں اپنی جمع کرنے والی چیز شامل کریں {#add-nft-to-metamask} + +ایک بار جب آپ Sepolia نیٹ ورک پر ہوں، تو دائیں جانب "Collectibles" ٹیب کو منتخب کریں اور NFT اسمارٹ کنٹریکٹ کا ایڈریس اور اپنے NFT کا ERC-721 ٹوکن ID شامل کریں — جسے آپ ہمارے ٹیوٹوریل کے حصہ II میں ڈیپلوئے کیے گئے اپنے NFT کے ٹرانزیکشن ہیش کی بنیاد پر Etherscan پر تلاش کر سکتے ہیں۔ + +![اپنا ٹرانزیکشن ہیش اور ERC-721 ٹوکن ID کیسے تلاش کریں](./findNFTEtherscan.png) + +اپنا NFT دیکھنے کے لیے آپ کو چند بار ریفریش کرنے کی ضرورت پڑ سکتی ہے — لیکن یہ وہاں موجود ہوگا ! + +![اپنا NFT MetaMask پر کیسے اپ لوڈ کریں](./findNFTMetamask.gif) + +مبارک ہو! آپ نے کامیابی سے ایک NFT منٹ کر لیا ہے، اور اب آپ اسے دیکھ سکتے ہیں! ہم یہ دیکھنے کا انتظار نہیں کر سکتے کہ آپ NFT کی دنیا میں کیسے دھوم مچاتے ہیں! diff --git a/public/content/translations/ur/developers/tutorials/how-to-write-and-deploy-an-nft/index.md b/public/content/translations/ur/developers/tutorials/how-to-write-and-deploy-an-nft/index.md new file mode 100644 index 00000000000..cf2a844b3ce --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/how-to-write-and-deploy-an-nft/index.md @@ -0,0 +1,380 @@ +--- +title: "NFT کیسے لکھیں اور ڈیپلوئے کریں (NFT ٹیوٹوریل سیریز کا حصہ 1/3)" +description: "یہ ٹیوٹوریل NFTs پر ایک سیریز کا حصہ 1 ہے جو آپ کو مرحلہ وار بتائے گا کہ Ethereum اور انٹر پلینٹری فائل سسٹم (IPFS) کا استعمال کرتے ہوئے ایک نان-فنجیبل ٹوکن (ERC-721 ٹوکن) اسمارٹ کنٹریکٹ کیسے لکھیں اور ڈیپلوئے کریں۔" +author: "Sumi Mudgil" +tags: [ "ERC-721", "Alchemy", "Solidity", "اسمارٹ معاہدات" ] +skill: beginner +lang: ur-in +published: 2021-04-22 +--- + +NFTs کے بلاک چین کو عوام کی نظروں میں لانے کے ساتھ، اب آپ کے لیے Ethereum بلاک چین پر اپنا خود کا NFT کنٹریکٹ (ERC-721 ٹوکن) شائع کرکے اس ہائپ کو خود سمجھنے کا ایک بہترین موقع ہے! + +Alchemy کو NFT اسپیس کے سب سے بڑے ناموں کو طاقت فراہم کرنے پر بے حد فخر ہے، جس میں Makersplace (جس نے حال ہی میں کرسٹی'ز میں 69 ملین ڈالر میں ایک ریکارڈ ڈیجیٹل آرٹ ورک فروخت کیا)، Dapper Labs (NBA Top Shot اور Crypto Kitties کے تخلیق کار)، OpenSea (دنیا کا سب سے بڑا NFT مارکیٹ پلیس)، Zora، Super Rare، NFTfi، Foundation، Enjin، Origin Protocol، Immutable، اور مزید شامل ہیں۔ + +اس ٹیوٹوریل میں، ہم [MetaMask](https://metamask.io/)، [Solidity](https://docs.soliditylang.org/en/v0.8.0/)، [Hardhat](https://hardhat.org/)، [Pinata](https://pinata.cloud/) اور [Alchemy](https://alchemy.com/signup/eth) کا استعمال کرتے ہوئے Sepolia ٹیسٹ نیٹ ورک پر ایک ERC-721 اسمارٹ کنٹریکٹ بنانے اور ڈیپلوئے کرنے کے بارے میں بتائیں گے (اگر آپ ابھی تک نہیں سمجھتے کہ ان میں سے کسی کا کیا مطلب ہے تو پریشان نہ ہوں — ہم اس کی وضاحت کریں گے!)۔ + +اس ٹیوٹوریل کے حصہ 2 میں ہم دیکھیں گے کہ ہم اپنے اسمارٹ کنٹریکٹ کا استعمال کرکے ایک NFT کیسے مِنٹ کر سکتے ہیں، اور حصہ 3 میں ہم وضاحت کریں گے کہ MetaMask پر اپنے NFT کو کیسے دیکھیں۔ + +اور ہاں، اگر آپ کے پاس کسی بھی وقت کوئی سوالات ہوں، تو [Alchemy Discord](https://discord.gg/gWuC7zB) میں رابطہ کرنے یا [Alchemy کی NFT API دستاویزات](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) پر جانے میں ہچکچاہٹ محسوس نہ کریں! + +## مرحلہ 1: Ethereum نیٹ ورک سے جڑیں {#connect-to-ethereum} + +Ethereum بلاک چین سے درخواستیں کرنے کے بہت سے طریقے ہیں، لیکن چیزوں کو آسان بنانے کے لیے، ہم [Alchemy](https://alchemy.com/signup/eth) پر ایک مفت اکاؤنٹ استعمال کریں گے، جو ایک بلاک چین ڈیولپر پلیٹ فارم اور API ہے جو ہمیں اپنے نوڈس چلائے بغیر Ethereum چین کے ساتھ بات چیت کرنے کی اجازت دیتا ہے۔ + +اس ٹیوٹوریل میں، ہم اپنے اسمارٹ کنٹریکٹ کی ڈیپلوئمنٹ کے دوران پس پردہ کیا ہو رہا ہے یہ سمجھنے کے لیے مانیٹرنگ اور تجزیات کے لیے Alchemy کے ڈیولپر ٹولز کا بھی فائدہ اٹھائیں گے۔ اگر آپ کے پاس پہلے سے Alchemy اکاؤنٹ نہیں ہے، تو آپ [یہاں](https://alchemy.com/signup/eth) مفت میں سائن اپ کر سکتے ہیں۔ + +## مرحلہ 2: اپنی ایپ (اور API کلید) بنائیں {#make-api-key} + +ایک بار جب آپ Alchemy اکاؤنٹ بنا لیں، تو آپ ایک ایپ بنا کر API کلید تیار کر سکتے ہیں۔ یہ ہمیں Sepolia ٹیسٹ نیٹ ورک سے درخواستیں کرنے کی اجازت دے گا۔ اگر آپ ٹیسٹ نیٹ ورکس کے بارے میں مزید جاننے کے لیے متجسس ہیں تو [اس گائیڈ](https://docs.alchemyapi.io/guides/choosing-a-network) کو دیکھیں۔ + +1. نیو بار میں "Apps" پر ہوور کرکے اور "Create App" پر کلک کرکے اپنے Alchemy ڈیش بورڈ میں "Create App" صفحہ پر جائیں۔ + +![اپنی ایپ بنائیں](./create-your-app.png) + +2. اپنی ایپ کو نام دیں (ہم نے “My First NFT!” منتخب کیا)، ایک مختصر تفصیل دیں، چین کے لیے “Ethereum” منتخب کریں، اور اپنے نیٹ ورک کے لیے “Sepolia” کا انتخاب کریں۔ مرج کے بعد سے دوسرے ٹیسٹ نیٹس کو فرسودہ کر دیا گیا ہے۔ + +![اپنی ایپ کو کنفیگر اور شائع کریں](./alchemy-explorer-sepolia.png) + +3. “Create app” پر کلک کریں اور بس! آپ کی ایپ نیچے دی گئی ٹیبل میں ظاہر ہونی چاہیے۔ + +## مرحلہ 3: ایک Ethereum اکاؤنٹ (ایڈریس) بنائیں {#create-eth-address} + +ٹرانزیکشنز بھیجنے اور وصول کرنے کے لیے ہمیں ایک Ethereum اکاؤنٹ کی ضرورت ہے۔ اس ٹیوٹوریل کے لیے، ہم MetaMask استعمال کریں گے، جو براؤزر میں ایک ورچوئل والیٹ ہے جو آپ کے Ethereum اکاؤنٹ ایڈریس کو منظم کرنے کے لیے استعمال ہوتا ہے۔ اگر آپ یہ سمجھنا چاہتے ہیں کہ Ethereum پر ٹرانزیکشنز کیسے کام کرتی ہیں، تو Ethereum فاؤنڈیشن کا [یہ صفحہ](/developers/docs/transactions/) دیکھیں۔ + +آپ [یہاں](https://metamask.io/download) مفت میں MetaMask اکاؤنٹ ڈاؤن لوڈ اور بنا سکتے ہیں۔ جب آپ اکاؤنٹ بنا رہے ہوں، یا اگر آپ کے پاس پہلے سے ہی اکاؤنٹ ہے، تو یقینی بنائیں کہ اوپری دائیں کونے میں "Sepolia Test Network" پر سوئچ کریں (تاکہ ہم اصلی پیسے کے ساتھ کام نہ کر رہے ہوں)۔ + +![Sepolia کو اپنے نیٹ ورک کے طور پر سیٹ کریں](./metamask-goerli.png) + +## مرحلہ 4: ایک فاسیٹ سے ایتھر شامل کریں {#step-4-add-ether-from-a-faucet} + +اپنے اسمارٹ کنٹریکٹ کو ٹیسٹ نیٹ ورک پر ڈیپلوئے کرنے کے لیے، ہمیں کچھ جعلی ETH کی ضرورت ہوگی۔ ETH حاصل کرنے کے لیے آپ Alchemy کے زیر اہتمام [Sepolia Faucet](https://sepoliafaucet.com/) پر جا سکتے ہیں، لاگ ان کریں اور اپنا اکاؤنٹ ایڈریس درج کریں، "Send Me ETH" پر کلک کریں۔ اس کے فوراً بعد آپ کو اپنے MetaMask اکاؤنٹ میں ETH نظر آنا چاہیے! + +## مرحلہ 5: اپنا بیلنس چیک کریں {#check-balance} + +ہمارا بیلنس موجود ہے یا نہیں اس کی دوبارہ جانچ کرنے کے لیے، آئیے [Alchemy کے کمپوزر ٹول](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) کا استعمال کرتے ہوئے ایک [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) درخواست کریں۔ یہ ہمارے والیٹ میں ETH کی رقم واپس کرے گا۔ اپنے MetaMask اکاؤنٹ کا ایڈریس درج کرنے اور "Send Request" پر کلک کرنے کے بعد، آپ کو اس طرح کا جواب نظر آنا چاہیے: + + ``` + `{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}` + ``` + +> **نوٹ** یہ نتیجہ wei میں ہے، ETH میں نہیں۔ Wei کو ایتھر کی سب سے چھوٹی اکائی کے طور پر استعمال کیا جاتا ہے۔ wei سے ETH میں تبدیلی 1 eth = 1018 wei ہے۔ لہذا اگر ہم 0xde0b6b3a7640000 کو ڈیسیمل میں تبدیل کرتے ہیں تو ہمیں 1\*1018 wei ملتا ہے، جو 1 ETH کے برابر ہے۔ + +اف! ہمارا جعلی پیسہ سب وہیں ہے۔ + +## مرحلہ 6: ہمارے پروجیکٹ کو شروع کریں {#initialize-project} + +سب سے پہلے، ہمیں اپنے پروجیکٹ کے لیے ایک فولڈر بنانا ہوگا۔ اپنی کمانڈ لائن پر جائیں اور ٹائپ کریں: + + ``` + mkdir my-nft + cd my-nft + ``` + +اب جب کہ ہم اپنے پروجیکٹ فولڈر کے اندر ہیں، ہم پروجیکٹ کو شروع کرنے کے لیے npm init استعمال کریں گے۔ اگر آپ کے پاس پہلے سے npm انسٹال نہیں ہے، تو [ان ہدایات](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) پر عمل کریں (ہمیں [Node.js](https://nodejs.org/en/download/) کی بھی ضرورت ہوگی، لہذا اسے بھی ڈاؤن لوڈ کریں!)۔ + + ``` + npm init + ``` + +اس سے کوئی فرق نہیں پڑتا کہ آپ انسٹالیشن کے سوالات کا جواب کیسے دیتے ہیں؛ یہاں ہم نے اسے حوالہ کے لیے کیسے کیا ہے: + +```json + package name: (my-nft) + version: (1.0.0) + description: میرا پہلا NFT! + entry point: (index.js) + test command: + git repository: + keywords: + author: + license: (ISC) + About to write to /Users/thesuperb1/Desktop/my-nft/package.json: + + { + "name": "my-nft", + "version": "1.0.0", + "description": "میرا پہلا NFT!", + "main": "index.js", + "scripts": { + "test": "echo \"Error: no test specified\" && exit 1" + }, + "author": "", + "license": "ISC" + } +``` + +package.json کو منظور کریں، اور ہم تیار ہیں! + +## مرحلہ 7: [Hardhat](https://hardhat.org/getting-started/#overview) انسٹال کریں {#install-hardhat} + +Hardhat آپ کے Ethereum سافٹ ویئر کو کمپائل، ڈیپلوئے، ٹیسٹ اور ڈیبگ کرنے کے لیے ایک ڈیولپمنٹ ماحول ہے۔ یہ ڈیولپرز کو لائیو چین پر ڈیپلوئے کرنے سے پہلے مقامی طور پر اسمارٹ کنٹریکٹس اور dapps بنانے میں مدد کرتا ہے۔ + +ہمارے my-nft پروجیکٹ کے اندر چلائیں: + + ``` + npm install --save-dev hardhat + ``` + +[انسٹالیشن کی ہدایات](https://hardhat.org/getting-started/#overview) پر مزید تفصیلات کے لیے یہ صفحہ دیکھیں۔ + +## مرحلہ 8: Hardhat پروجیکٹ بنائیں {#create-hardhat-project} + +ہمارے پروجیکٹ فولڈر کے اندر چلائیں: + + ``` + npx hardhat + ``` + +پھر آپ کو ایک خوش آمدیدی پیغام اور یہ منتخب کرنے کا آپشن نظر آئے گا کہ آپ کیا کرنا چاہتے ہیں۔ “create an empty hardhat.config.js” منتخب کریں: + + ``` + 888 888 888 888 888 + 888 888 888 888 888 + 888 888 888 888 888 + 8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 + 888 888 "88b 888P" d88" 888 888 "88b "88b 888 + 888 888 .d888888 888 888 888 888 888 .d888888 888 + 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. + 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 + 👷 Hardhat v2.0.11 میں خوش آمدید 👷‍ + ? آپ کیا کرنا چاہتے ہیں؟ … + ایک نمونہ پروجیکٹ بنائیں + ❯ ایک خالی hardhat.config.js بنائیں + چھوڑ دیں + ``` + +یہ ہمارے لیے ایک hardhat.config.js فائل تیار کرے گا جہاں ہم اپنے پروجیکٹ کے لیے تمام سیٹ اپ کی وضاحت کریں گے (مرحلہ 13 پر)۔ + +## مرحلہ 9: پروجیکٹ فولڈرز شامل کریں {#add-project-folders} + +اپنے پروجیکٹ کو منظم رکھنے کے لیے، ہم دو نئے فولڈر بنائیں گے۔ اپنی کمانڈ لائن میں اپنے پروجیکٹ کی روٹ ڈائرکٹری پر جائیں اور ٹائپ کریں: + + ``` + mkdir contracts + mkdir scripts + ``` + +- `contracts/` وہ جگہ ہے جہاں ہم اپنا NFT اسمارٹ کنٹریکٹ کوڈ رکھیں گے۔ + +- `scripts/` وہ جگہ ہے جہاں ہم اپنے اسمارٹ کنٹریکٹ کو ڈیپلوئے کرنے اور اس کے ساتھ تعامل کرنے کے لیے اسکرپٹس رکھیں گے۔ + +## مرحلہ 10: ہمارا کنٹریکٹ لکھیں {#write-contract} + +اب جب کہ ہمارا ماحول سیٹ ہو گیا ہے، تو مزید دلچسپ چیزوں کی طرف بڑھتے ہیں: _ہمارا اسمارٹ کنٹریکٹ کوڈ لکھنا!_ + +اپنے پسندیدہ ایڈیٹر میں my-nft پروجیکٹ کھولیں (ہمیں [VSCode](https://code.visualstudio.com/) پسند ہے)۔ اسمارٹ کنٹریکٹس Solidity نامی زبان میں لکھے جاتے ہیں جسے ہم اپنا MyNFT.sol اسمارٹ کنٹریکٹ لکھنے کے لیے استعمال کریں گے۔ + +1. `contracts` فولڈر پر جائیں اور MyNFT.sol نامی ایک نئی فائل بنائیں۔ + +2. ذیل میں ہمارا NFT اسمارٹ کنٹریکٹ کوڈ ہے، جسے ہم نے [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc721) لائبریری کے ERC-721 نفاذ پر مبنی کیا ہے۔ نیچے دیئے گئے مواد کو اپنی MyNFT.sol فائل میں کاپی اور پیسٹ کریں۔ + + ```solidity + //کنٹریکٹ [https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721) پر مبنی ہے + // SPDX-License-Identifier: MIT + pragma solidity ^0.8.0; + + import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; + import "@openzeppelin/contracts/utils/Counters.sol"; + import "@openzeppelin/contracts/access/Ownable.sol"; + import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; + + contract MyNFT is ERC721URIStorage, Ownable { + using Counters for Counters.Counter; + Counters.Counter private _tokenIds; + + constructor() ERC721("MyNFT", "NFT") {} + + function mintNFT(address recipient, string memory tokenURI) + public onlyOwner + returns (uint256) + { + _tokenIds.increment(); + + uint256 newItemId = _tokenIds.current(); + _mint(recipient, newItemId); + _setTokenURI(newItemId, tokenURI); + + return newItemId; + } + } + ``` + +3. چونکہ ہم OpenZeppelin کنٹریکٹ لائبریری سے کلاسز وراثت میں لے رہے ہیں، اپنی کمانڈ لائن میں `npm install @openzeppelin/contracts^4.0.0` چلا کر لائبریری کو اپنے فولڈر میں انسٹال کریں۔ + +تو، یہ کوڈ اصل میں _کرتا_ کیا ہے؟ آئیے اسے لائن بہ لائن توڑتے ہیں۔ + +ہمارے اسمارٹ کنٹریکٹ کے اوپری حصے میں، ہم تین [OpenZeppelin](https://openzeppelin.com/) اسمارٹ کنٹریکٹ کلاسز درآمد کرتے ہیں: + +- @openzeppelin/contracts/token/ERC721/ERC721.sol میں ERC-721 معیار کا نفاذ شامل ہے، جسے ہمارا NFT اسمارٹ کنٹریکٹ وراثت میں لے گا۔ (ایک درست NFT ہونے کے لیے، آپ کے اسمارٹ کنٹریکٹ کو ERC-721 معیار کے تمام طریقوں کو نافذ کرنا ہوگا)۔ وراثت میں ملے ERC-721 فنکشنز کے بارے میں مزید جاننے کے لیے، انٹرفیس کی تعریف [یہاں](https://eips.ethereum.org/EIPS/eip-721) دیکھیں۔ + +- @openzeppelin/contracts/utils/Counters.sol کاؤنٹرز فراہم کرتا ہے جنہیں صرف ایک سے بڑھایا یا گھٹایا جا سکتا ہے۔ ہمارا اسمارٹ کنٹریکٹ مِنٹ کیے گئے NFTs کی کل تعداد پر نظر رکھنے اور ہمارے نئے NFT پر منفرد ID سیٹ کرنے کے لیے ایک کاؤنٹر استعمال کرتا ہے۔ (ایک اسمارٹ کنٹریکٹ کا استعمال کرتے ہوئے مِنٹ کیے گئے ہر NFT کو ایک منفرد ID تفویض کی جانی چاہیے—یہاں ہماری منفرد ID صرف موجودہ NFTs کی کل تعداد سے طے ہوتی ہے۔ مثال کے طور پر، پہلا NFT جسے ہم اپنے اسمارٹ کنٹریکٹ سے مِنٹ کرتے ہیں اس کی ID "1" ہے، ہمارے دوسرے NFT کی ID "2" ہے، وغیرہ)۔ + +- @openzeppelin/contracts/access/Ownable.sol ہمارے اسمارٹ کنٹریکٹ پر [رسائی کنٹرول](https://docs.openzeppelin.com/contracts/3.x/access-control) سیٹ کرتا ہے، تاکہ صرف اسمارٹ کنٹریکٹ کا مالک (آپ) ہی NFTs مِنٹ کر سکے۔ (نوٹ کریں، رسائی کنٹرول کو شامل کرنا مکمل طور پر ایک ترجیح ہے۔ اگر آپ چاہتے ہیں کہ کوئی بھی آپ کے اسمارٹ کنٹریکٹ کا استعمال کرتے ہوئے NFT مِنٹ کر سکے، تو لائن 10 پر Ownable لفظ اور لائن 17 پر onlyOwner کو ہٹا دیں)۔ + +ہمارے امپورٹ اسٹیٹمنٹس کے بعد، ہمارے پاس ہمارا کسٹم NFT اسمارٹ کنٹریکٹ ہے، جو حیرت انگیز طور پر مختصر ہے — اس میں صرف ایک کاؤنٹر، ایک کنسٹرکٹر، اور ایک ہی فنکشن ہے! یہ ہمارے وراثت میں ملے OpenZeppelin کنٹریکٹس کی بدولت ہے، جو ایک NFT بنانے کے لیے درکار زیادہ تر طریقوں کو نافذ کرتے ہیں، جیسے `ownerOf` جو NFT کے مالک کو واپس کرتا ہے، اور `transferFrom`، جو NFT کی ملکیت کو ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں منتقل کرتا ہے۔ + +ہمارے ERC-721 کنسٹرکٹر میں، آپ دیکھیں گے کہ ہم 2 اسٹرنگز، “MyNFT” اور “NFT” پاس کرتے ہیں۔ پہلا متغیر اسمارٹ کنٹریکٹ کا نام ہے، اور دوسرا اس کی علامت ہے۔ آپ ان میں سے ہر ایک متغیر کو جو چاہیں نام دے سکتے ہیں! + +آخر میں، ہمارے پاس ہمارا فنکشن `mintNFT(address recipient, string memory tokenURI)` ہے جو ہمیں ایک NFT مِنٹ کرنے کی اجازت دیتا ہے! آپ دیکھیں گے کہ یہ فنکشن دو متغیرات لیتا ہے: + +- `address recipient` اس ایڈریس کی وضاحت کرتا ہے جو آپ کا تازہ مِنٹ کیا ہوا NFT وصول کرے گا + +- `string memory tokenURI` ایک اسٹرنگ ہے جسے ایک JSON دستاویز میں حل ہونا چاہئے جو NFT کے میٹا ڈیٹا کو بیان کرتا ہے۔ ایک NFT کا میٹا ڈیٹا ہی دراصل اسے زندگی بخشتا ہے، جس سے اس میں قابل ترتیب خصوصیات ہوتی ہیں، جیسے نام، تفصیل، تصویر، اور دیگر خصوصیات۔ اس ٹیوٹوریل کے حصہ 2 میں، ہم اس میٹا ڈیٹا کو کنفیگر کرنے کا طریقہ بیان کریں گے۔ + +`mintNFT` وراثت میں ملی ERC-721 لائبریری سے کچھ طریقے کال کرتا ہے، اور آخر میں ایک نمبر واپس کرتا ہے جو تازہ مِنٹ کیے گئے NFT کی ID کی نمائندگی کرتا ہے۔ + +## مرحلہ 11: MetaMask اور Alchemy کو اپنے پروجیکٹ سے جوڑیں {#connect-metamask-and-alchemy} + +اب جب کہ ہم نے ایک MetaMask والیٹ، Alchemy اکاؤنٹ بنا لیا ہے، اور اپنا اسمارٹ کنٹریکٹ لکھ لیا ہے، اب وقت آگیا ہے کہ تینوں کو جوڑا جائے۔ + +آپ کے ورچوئل والیٹ سے بھیجی گئی ہر ٹرانزیکشن کے لیے آپ کی منفرد پرائیویٹ کلید کا استعمال کرتے ہوئے ایک دستخط کی ضرورت ہوتی ہے۔ ہمارے پروگرام کو یہ اجازت فراہم کرنے کے لیے، ہم اپنی پرائیویٹ کلید (اور Alchemy API کلید) کو ایک ماحولیاتی فائل میں محفوظ طریقے سے اسٹور کر سکتے ہیں۔ + +ٹرانزیکشنز بھیجنے کے بارے میں مزید جاننے کے لیے، web3 کا استعمال کرتے ہوئے ٹرانزیکشنز بھیجنے پر [یہ ٹیوٹوریل](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) دیکھیں۔ + +سب سے پہلے، اپنی پروجیکٹ ڈائرکٹری میں dotenv پیکیج انسٹال کریں: + + ``` + npm install dotenv --save + ``` + +پھر، ہمارے پروجیکٹ کی روٹ ڈائرکٹری میں ایک `.env` فائل بنائیں، اور اس میں اپنی MetaMask پرائیویٹ کلید اور HTTP Alchemy API URL شامل کریں۔ + +- اپنی پرائیویٹ کلید کو MetaMask سے ایکسپورٹ کرنے کے لیے [ان ہدایات](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) پر عمل کریں۔ + +- HTTP Alchemy API URL حاصل کرنے کے لیے نیچے دیکھیں اور اسے اپنے کلپ بورڈ پر کاپی کریں۔ + +![اپنا Alchemy API URL کاپی کریں](./copy-alchemy-api-url.gif) + +اب آپ کی `.env` فائل اس طرح نظر آنی چاہیے: + + ``` + API_URL="https://eth-sepolia.g.alchemy.com/v2/your-api-key" + PRIVATE_KEY="your-metamask-private-key" + ``` + +ان کو حقیقت میں ہمارے کوڈ سے جوڑنے کے لیے، ہم مرحلہ 13 میں اپنی hardhat.config.js فائل میں ان متغیرات کا حوالہ دیں گے۔ + + + +## مرحلہ 12: Ethers.js انسٹال کریں {#install-ethers} + +Ethers.js ایک لائبریری ہے جو [معیاری JSON-RPC طریقوں](/developers/docs/apis/json-rpc/) کو زیادہ صارف دوست طریقوں کے ساتھ لپیٹ کر Ethereum کے ساتھ تعامل اور درخواستیں کرنا آسان بناتی ہے۔ + +Hardhat اضافی ٹولنگ اور توسیع شدہ فعالیت کے لیے [پلگ انز](https://hardhat.org/plugins/) کو ضم کرنا انتہائی آسان بناتا ہے۔ ہم کنٹریکٹ ڈیپلائمنٹ کے لیے [Ethers پلگ ان](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) سے فائدہ اٹھائیں گے ([Ethers.js](https://github.com/ethers-io/ethers.js/) میں کچھ انتہائی صاف کنٹریکٹ ڈیپلائمنٹ کے طریقے ہیں)۔ + +اپنی پروجیکٹ ڈائرکٹری میں ٹائپ کریں: + + ``` + npm install --save-dev @nomiclabs/hardhat-ethers ethers@^5.0.0 + ``` + +ہم اگلے مرحلے میں اپنی hardhat.config.js میں بھی ethers کی ضرورت محسوس کریں گے۔ + +## مرحلہ 13: hardhat.config.js کو اپ ڈیٹ کریں {#update-hardhat-config} + +ہم نے اب تک کئی انحصار اور پلگ ان شامل کیے ہیں، اب ہمیں hardhat.config.js کو اپ ڈیٹ کرنے کی ضرورت ہے تاکہ ہمارے پروجیکٹ کو ان سب کے بارے میں معلوم ہو۔ + +اپنی hardhat.config.js کو اس طرح دکھنے کے لیے اپ ڈیٹ کریں: + +```js + /** + * @type import('hardhat/config').HardhatUserConfig + */ + require('dotenv').config(); + require("@nomiclabs/hardhat-ethers"); + const { API_URL, PRIVATE_KEY } = process.env; + module.exports = { + solidity: "0.8.1", + defaultNetwork: "sepolia", + networks: { + hardhat: {}, + sepolia: { + url: API_URL, + accounts: [`0x${PRIVATE_KEY}`] + } + }, + } +``` + +## مرحلہ 14: ہمارا کنٹریکٹ کمپائل کریں {#compile-contract} + +یہ یقینی بنانے کے لیے کہ اب تک سب کچھ کام کر رہا ہے، آئیے اپنے کنٹریکٹ کو کمپائل کریں۔ کمپائل ٹاسک بلٹ ان ہارڈ ہیٹ ٹاسک میں سے ایک ہے۔ + +کمانڈ لائن سے چلائیں: + + ``` + npx hardhat compile + ``` + +آپ کو سورس فائل میں SPDX لائسنس شناخت کنندہ فراہم نہ کیے جانے کے بارے میں ایک انتباہ مل سکتا ہے، لیکن اس کے بارے میں فکر کرنے کی ضرورت نہیں ہے — امید ہے کہ باقی سب کچھ ٹھیک نظر آئے گا! اگر نہیں، تو آپ ہمیشہ [Alchemy discord](https://discord.gg/u72VCg3) میں پیغام بھیج سکتے ہیں۔ + +## مرحلہ 15: ہماری ڈیپلوئے اسکرپٹ لکھیں {#write-deploy} + +اب جب کہ ہمارا کنٹریکٹ لکھا جا چکا ہے اور ہماری کنفیگریشن فائل تیار ہے، اب وقت آگیا ہے کہ ہم اپنی کنٹریکٹ ڈیپلوئے اسکرپٹ لکھیں۔ + +`scripts/` فولڈر پر جائیں اور `deploy.js` نامی ایک نئی فائل بنائیں، اس میں درج ذیل مواد شامل کریں: + +```js +async function main() { + const MyNFT = await ethers.getContractFactory("MyNFT") + + // ڈیپلوئمنٹ شروع کریں، ایک وعدہ واپس کریں جو ایک کنٹریکٹ آبجیکٹ میں حل ہو + const myNFT = await MyNFT.deploy() + await myNFT.deployed() + console.log("کنٹریکٹ اس ایڈریس پر ڈیپلوئے کیا گیا:", myNFT.address) +} + +main() + .then(() => process.exit(0)) + .catch((error) => { + console.error(error) + process.exit(1) + }) +``` + +Hardhat اپنے [کنٹریکٹس ٹیوٹوریل](https://hardhat.org/tutorial/testing-contracts.html#writing-tests) میں بہت اچھی طرح سے وضاحت کرتا ہے کہ کوڈ کی یہ ہر لائن کیا کرتی ہے، ہم نے یہاں ان کی وضاحتیں اپنائی ہیں۔ + + ``` + const MyNFT = await ethers.getContractFactory("MyNFT"); + ``` + +ethers.js میں ایک ContractFactory نئے اسمارٹ کنٹریکٹس کو ڈیپلوئے کرنے کے لیے استعمال ہونے والا ایک خلاصہ ہے، لہذا MyNFT یہاں ہمارے NFT کنٹریکٹ کی مثالوں کے لیے ایک فیکٹری ہے۔ hardhat-ethers پلگ ان کا استعمال کرتے وقت ContractFactory اور Contract مثالیں پہلے دستخط کنندہ سے بطور ڈیفالٹ منسلک ہوتی ہیں۔ + + ``` + const myNFT = await MyNFT.deploy(); + ``` + +ContractFactory پر deploy() کو کال کرنے سے ڈیپلوئمنٹ شروع ہو جائے گی، اور ایک Promise واپس آئے گا جو ایک Contract میں حل ہو جائے گا۔ یہ وہ آبجیکٹ ہے جس میں ہمارے ہر اسمارٹ کنٹریکٹ فنکشن کے لیے ایک طریقہ ہے۔ + +## مرحلہ 16: ہمارا کنٹریکٹ ڈیپلوئے کریں {#deploy-contract} + +ہم آخر کار اپنے اسمارٹ کنٹریکٹ کو ڈیپلوئے کرنے کے لیے تیار ہیں! اپنی پروجیکٹ ڈائرکٹری کی جڑ پر واپس جائیں، اور کمانڈ لائن میں چلائیں: + + ``` + npx hardhat --network sepolia run scripts/deploy.js + ``` + +پھر آپ کو کچھ اس طرح نظر آنا چاہیے: + + ``` + کنٹریکٹ اس ایڈریس پر ڈیپلوئے کیا گیا: 0x4C5266cCc4b3F426965d2f51b6D910325a0E7650 + ``` + +اگر ہم [Sepolia etherscan](https://sepolia.etherscan.io/) پر جائیں اور اپنے کنٹریکٹ ایڈریس کو تلاش کریں تو ہمیں یہ دیکھنے کے قابل ہونا چاہئے کہ یہ کامیابی سے ڈیپلوئے ہو گیا ہے۔ اگر آپ اسے فوراً نہیں دیکھ سکتے ہیں، تو براہ کرم تھوڑی دیر انتظار کریں کیونکہ اس میں کچھ وقت لگ سکتا ہے۔ ٹرانزیکشن کچھ اس طرح نظر آئے گی: + +![Etherscan پر اپنے ٹرانزیکشن کا ایڈریس دیکھیں](./etherscan-sepoila-contract-creation.png) + +From ایڈریس آپ کے MetaMask اکاؤنٹ کے ایڈریس سے ملنا چاہیے اور To ایڈریس پر “Contract Creation” لکھا ہوگا۔ اگر ہم ٹرانزیکشن میں کلک کرتے ہیں، تو ہمیں To فیلڈ میں اپنا کنٹریکٹ ایڈریس نظر آئے گا: + +![Etherscan پر اپنے کنٹریکٹ کا ایڈریس دیکھیں](./etherscan-sepolia-tx-details.png) + +یاہ! آپ نے ابھی اپنا NFT اسمارٹ کنٹریکٹ Ethereum (ٹیسٹ نیٹ) چین پر ڈیپلوئے کیا ہے! + +یہ سمجھنے کے لیے کہ پس پردہ کیا ہو رہا ہے، آئیے اپنے [Alchemy ڈیش بورڈ](https://dashboard.alchemyapi.io/explorer) میں ایکسپلورر ٹیب پر جائیں۔ اگر آپ کے پاس ایک سے زیادہ Alchemy ایپس ہیں تو ایپ کے ذریعے فلٹر کرنا اور “MyNFT” منتخب کرنا یقینی بنائیں۔ + +![Alchemy کے ایکسپلورر ڈیش بورڈ کے ساتھ “پس پردہ” کی گئی کالز دیکھیں](./alchemy-explorer-goerli.png) + +یہاں آپ کو مٹھی بھر JSON-RPC کالز نظر آئیں گی جو Hardhat/Ethers نے ہمارے لیے پس پردہ کی تھیں جب ہم نے .deploy() فنکشن کو کال کیا تھا۔ یہاں دو اہم کالز [eth_sendRawTransaction](/developers/docs/apis/json-rpc/#eth_sendrawtransaction) ہیں، جو دراصل ہمارے اسمارٹ کنٹریکٹ کو Sepolia چین پر لکھنے کی درخواست ہے، اور [eth_getTransactionByHash](/developers/docs/apis/json-rpc/#eth_gettransactionbyhash) جو ہیش کی بنیاد پر ہماری ٹرانزیکشن کے بارے میں معلومات پڑھنے کی درخواست ہے (ٹرانزیکشنز بھیجتے وقت ایک عام نمونہ)۔ ٹرانزیکشنز بھیجنے کے بارے میں مزید جاننے کے لیے، [Web3 کا استعمال کرتے ہوئے ٹرانزیکشنز بھیجنے](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) پر یہ ٹیوٹوریل دیکھیں۔ + +اس ٹیوٹوریل کے حصہ 1 کے لیے بس اتنا ہی۔ [حصہ 2 میں، ہم اصل میں ایک NFT مِنٹ کرکے اپنے اسمارٹ کنٹریکٹ کے ساتھ تعامل کریں گے](/developers/tutorials/how-to-mint-an-nft/)، اور [حصہ 3 میں ہم آپ کو دکھائیں گے کہ اپنے Ethereum والیٹ میں اپنے NFT کو کیسے دیکھیں](/developers/tutorials/how-to-view-nft-in-metamask/)! diff --git a/public/content/translations/ur/developers/tutorials/interact-with-other-contracts-from-solidity/index.md b/public/content/translations/ur/developers/tutorials/interact-with-other-contracts-from-solidity/index.md new file mode 100644 index 00000000000..434ff69e3d0 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/interact-with-other-contracts-from-solidity/index.md @@ -0,0 +1,179 @@ +--- +title: "Solidity سے دوسرے معاہدوں کے ساتھ تعامل کریں" +description: "ایک موجودہ معاہدے سے ایک اسمارٹ معاہدہ کیسے تعینات کریں اور اس کے ساتھ تعامل کریں" +author: "jdourlens" +tags: + [ + "اسمارٹ معاہدات", + "solidity", + "remix", + "تعینات کرنا", + "مرکبیت" + ] +skill: advanced +lang: ur-in +published: 2020-04-05 +source: EthereumDev +sourceUrl: https://ethereumdev.io/interact-with-other-contracts-from-solidity/ +address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" +--- + +پچھلے ٹیوٹوریلز میں ہم نے بہت کچھ سیکھا [اپنا پہلا اسمارٹ معاہدہ کیسے تعینات کریں](/developers/tutorials/deploying-your-first-smart-contract/) اور اس میں کچھ خصوصیات شامل کرنا جیسے [موڈیفائرز کے ساتھ رسائی کو کنٹرول کرنا](https://ethereumdev.io/organize-your-code-and-control-access-to-your-smart-contract-with-modifiers/) یا [Solidity میں غلطی سے نمٹنا](https://ethereumdev.io/handle-errors-in-solidity-with-require-and-revert/)۔ اس ٹیوٹوریل میں ہم سیکھیں گے کہ ایک موجودہ معاہدے سے ایک اسمارٹ معاہدہ کیسے تعینات کیا جائے اور اس کے ساتھ تعامل کیا جائے۔ + +ہم ایک ایسا معاہدہ بنائیں گے جو کسی کو بھی اپنا `Counter` اسمارٹ معاہدہ رکھنے کے قابل بنائے گا اس کے لیے ایک فیکٹری بنا کر، اس کا نام `CounterFactory` ہوگا۔ سب سے پہلے یہاں ہمارے ابتدائی `Counter` اسمارٹ معاہدے کا کوڈ ہے: + +```solidity +pragma solidity 0.5.17; + +contract Counter { + + uint256 private _count; + address private _owner; + address private _factory; + + + modifier onlyOwner(address caller) { + require(caller == _owner, "آپ معاہدے کے مالک نہیں ہیں"); + _; + } + + modifier onlyFactory() { + require(msg.sender == _factory, "آپ کو فیکٹری استعمال کرنے کی ضرورت ہے"); + _; + } + + constructor(address owner) public { + _owner = owner; + _factory = msg.sender; + } + + function getCount() public view returns (uint256) { + return _count; + } + + function increment(address caller) public onlyFactory onlyOwner(caller) { + _count++; + } + +} +``` + +نوٹ کریں کہ ہم نے فیکٹری کے ایڈریس اور معاہدے کے مالک کے ایڈریس کا ٹریک رکھنے کے لیے معاہدے کے کوڈ میں تھوڑی ترمیم کی ہے۔ جب آپ کسی دوسرے معاہدے سے کسی معاہدے کا کوڈ کال کرتے ہیں، تو msg.sender ہمارے معاہدے کی فیکٹری کے ایڈریس کا حوالہ دے گا۔ یہ سمجھنے کے لیے **ایک بہت اہم نکتہ ہے** کیونکہ دوسرے معاہدوں کے ساتھ تعامل کرنے کے لیے ایک معاہدے کا استعمال ایک عام رواج ہے۔ اس لیے آپ کو پیچیدہ معاملات میں اس بات کا خیال رکھنا چاہیے کہ بھیجنے والا کون ہے۔ + +اس کے لیے ہم نے ایک `onlyFactory` موڈیفائر بھی شامل کیا ہے جو اس بات کو یقینی بناتا ہے کہ اسٹیٹ کو تبدیل کرنے والے فنکشن کو صرف فیکٹری کے ذریعے ہی کال کیا جا سکتا ہے جو اصل کالر کو ایک پیرامیٹر کے طور پر پاس کرے گا۔ + +ہمارے نئے `CounterFactory` کے اندر جو دیگر تمام کاؤنٹروں کا نظم کرے گا، ہم ایک میپنگ شامل کریں گے جو ایک مالک کو اس کے کاؤنٹر معاہدے کے ایڈریس کے ساتھ منسلک کرے گا: + +```solidity +mapping(address => Counter) _counters; +``` + +Ethereum میں، میپنگ جاوا اسکرپٹ میں آبجیکٹس کے مساوی ہیں، وہ قسم A کی کلید کو قسم B کی قدر سے میپ کرنے کے قابل بناتے ہیں۔ اس صورت میں ہم ایک مالک کے ایڈریس کو اس کے کاؤنٹر کے انسٹنس کے ساتھ میپ کرتے ہیں۔ + +کسی کے لیے ایک نیا کاؤنٹر شروع کرنا اس طرح نظر آئے گا: + +```solidity + function createCounter() public { + require (_counters[msg.sender] == Counter(0)); + _counters[msg.sender] = new Counter(msg.sender); + } +``` + +ہم پہلے چیک کرتے ہیں کہ آیا وہ شخص پہلے سے ہی ایک کاؤنٹر کا مالک ہے۔ اگر وہ کاؤنٹر کا مالک نہیں ہے تو ہم اس کا ایڈریس `Counter` کنسٹرکٹر کو پاس کر کے ایک نیا کاؤنٹر شروع کرتے ہیں اور نئے بنائے گئے انسٹنس کو میپنگ کو تفویض کرتے ہیں۔ + +ایک مخصوص کاؤنٹر کی گنتی حاصل کرنے کے لیے یہ اس طرح نظر آئے گا: + +```solidity +function getCount(address account) public view returns (uint256) { + require (_counters[account] != Counter(0)); + return (_counters[account].getCount()); +} + +function getMyCount() public view returns (uint256) { + return (getCount(msg.sender)); +} +``` + +پہلا فنکشن یہ چیک کرتا ہے کہ آیا دیے گئے ایڈریس کے لیے کاؤنٹر معاہدہ موجود ہے اور پھر انسٹنس سے `getCount` میتھڈ کو کال کرتا ہے۔ دوسرا فنکشن: `getMyCount` صرف msg.sender کو براہ راست `getCount` فنکشن میں پاس کرنے کا ایک مختصر طریقہ ہے۔ + +`increment` فنکشن کافی ملتا جلتا ہے لیکن اصل ٹرانزیکشن بھیجنے والے کو `Counter` معاہدے میں پاس کرتا ہے: + +```solidity +function increment() public { + require (_counters[msg.sender] != Counter(0)); + Counter(_counters[msg.sender]).increment(msg.sender); + } +``` + +نوٹ کریں کہ اگر بہت زیادہ بار کال کیا گیا، تو ہمارا کاؤنٹر ممکنہ طور پر اوور فلو کا شکار ہو سکتا ہے۔ اس ممکنہ صورتحال سے بچانے کے لیے آپ کو جتنا ممکن ہو [SafeMath لائبریری](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/) کا استعمال کرنا چاہیے۔ + +ہمارے معاہدے کو تعینات کرنے کے لیے، آپ کو `CounterFactory` اور `Counter` دونوں کا کوڈ فراہم کرنا ہوگا۔ مثال کے طور پر Remix میں تعینات کرتے وقت آپ کو CounterFactory کو منتخب کرنے کی ضرورت ہوگی۔ + +مکمل کوڈ یہاں ہے: + +```solidity +pragma solidity 0.5.17; + +contract Counter { + + uint256 private _count; + address private _owner; + address private _factory; + + + modifier onlyOwner(address caller) { + require(caller == _owner, "آپ معاہدے کے مالک نہیں ہیں"); + _; + } + + modifier onlyFactory() { + require(msg.sender == _factory, "آپ کو فیکٹری استعمال کرنے کی ضرورت ہے"); + _; + } + + constructor(address owner) public { + _owner = owner; + _factory = msg.sender; + } + + function getCount() public view returns (uint256) { + return _count; + } + + function increment(address caller) public onlyFactory onlyOwner(caller) { + _count++; + } + +} + +contract CounterFactory { + + mapping(address => Counter) _counters; + + function createCounter() public { + require (_counters[msg.sender] == Counter(0)); + _counters[msg.sender] = new Counter(msg.sender); + } + + function increment() public { + require (_counters[msg.sender] != Counter(0)); + Counter(_counters[msg.sender]).increment(msg.sender); + } + + function getCount(address account) public view returns (uint256) { + require (_counters[account] != Counter(0)); + return (_counters[account].getCount()); + } + + function getMyCount() public view returns (uint256) { + return (getCount(msg.sender)); + } + +} +``` + +کمپائل کرنے کے بعد، Remix ڈیپلائے سیکشن میں آپ تعینات کی جانے والی فیکٹری کو منتخب کریں گے: + +![Remix میں تعینات کی جانے والی فیکٹری کا انتخاب](./counterfactory-deploy.png) + +پھر آپ اپنی معاہدہ فیکٹری کے ساتھ کھیل سکتے ہیں اور بدلتی ہوئی قدر کو چیک کر سکتے ہیں۔ اگر آپ اسمارٹ معاہدے کو کسی مختلف ایڈریس سے کال کرنا چاہتے ہیں تو آپ کو Remix کے اکاؤنٹ سلیکٹ میں ایڈریس تبدیل کرنے کی ضرورت ہوگی۔ diff --git a/public/content/translations/ur/developers/tutorials/ipfs-decentralized-ui/index.md b/public/content/translations/ur/developers/tutorials/ipfs-decentralized-ui/index.md new file mode 100644 index 00000000000..1806e4ed156 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/ipfs-decentralized-ui/index.md @@ -0,0 +1,73 @@ +--- +title: "غیر مرکزی یوزر انٹرفیس کے لیے IPFS" +description: "یہ ٹیوٹوریل پڑھنے والے کو سکھاتا ہے کہ ایک ڈیپ (dapp) کے لیے یوزر انٹرفیس کو اسٹور کرنے کے لیے IPFS کا استعمال کیسے کریں۔ اگرچہ ایپلیکیشن کا ڈیٹا اور کاروباری منطق غیر مرکزی ہے، لیکن سنسر شپ سے مزاحم یوزر انٹرفیس کے بغیر، یوزر کسی بھی طرح اس تک رسائی کھو سکتے ہیں۔" +author: Ori Pomerantz +tags: [ "ipfs" ] +skill: beginner +lang: ur-in +published: 2024-06-29 +--- + +آپ نے ایک ناقابل یقین نیا ڈیپ (dapp) لکھا ہے۔ آپ نے اس کے لیے ایک [یوزر انٹرفیس](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) بھی لکھا ہے۔ لیکن اب آپ کو ڈر ہے کہ کوئی آپ کے یوزر انٹرفیس کو بند کرکے اسے سنسر کرنے کی کوشش کرے گا، جو کلاؤڈ میں صرف ایک سرور ہے۔ اس ٹیوٹوریل میں آپ سیکھتے ہیں کہ اپنے یوزر انٹرفیس کو **[انٹرپلینیٹری فائل سسٹم (IPFS)](https://ipfs.tech/developers/)** پر ڈال کر سنسر شپ سے کیسے بچا جائے تاکہ کوئی بھی دلچسپی رکھنے والا اسے مستقبل کی رسائی کے لیے سرور پر پن کر سکے۔ + +آپ تمام کام کرنے کے لیے [Fleek](https://resources.fleek.xyz/docs/) جیسی تھرڈ پارٹی سروس کا استعمال کر سکتے ہیں۔ یہ ٹیوٹوریل ان لوگوں کے لیے ہے جو یہ سمجھنے کے لیے کافی کچھ کرنا چاہتے ہیں کہ وہ کیا کر رہے ہیں، چاہے اس میں زیادہ کام ہی کیوں نہ ہو۔ + +## مقامی طور پر شروع کرنا {#getting-started-locally} + +متعدد [تھرڈ-پارٹی IPFS فراہم کنندگان](https://docs.ipfs.tech/how-to/work-with-pinning-services/#use-a-third-party-pinning-service) ہیں، لیکن جانچ کے لیے مقامی طور پر IPFS چلا کر شروع کرنا بہتر ہے۔ + +1. [IPFS یوزر انٹرفیس](https://docs.ipfs.tech/install/ipfs-desktop/#install-instructions) انسٹال کریں۔ + +2. اپنی ویب سائٹ کے ساتھ ایک ڈائرکٹری بنائیں۔ اگر آپ [Vite](https://vite.dev/) استعمال کر رہے ہیں، تو یہ کمانڈ استعمال کریں: + + ```sh + pnpm vite build + ``` + +3. IPFS ڈیسک ٹاپ میں، **Import > Folder** پر کلک کریں اور پچھلے مرحلے میں بنائی گئی ڈائرکٹری کو منتخب کریں۔ + +4. جس فولڈر کو آپ نے ابھی اپ لوڈ کیا ہے اسے منتخب کریں اور **Rename** پر کلک کریں۔ اسے ایک زیادہ بامعنی نام دیں۔ + +5. اسے دوبارہ منتخب کریں اور **Share link** پر کلک کریں۔ URL کو کلپ بورڈ پر کاپی کریں۔ لنک `https://ipfs.io/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ` جیسا ہوگا۔ + +6. **Status** پر کلک کریں۔ گیٹ وے ایڈریس دیکھنے کے لیے **Advanced** ٹیب کو پھیلائیں۔ مثال کے طور پر، میرے سسٹم پر ایڈریس `http://127.0.0.1:8080` ہے۔ + +7. اپنا ایڈریس تلاش کرنے کے لیے لنک مرحلے سے پاتھ کو گیٹ وے ایڈریس کے ساتھ جوڑیں۔ مثال کے طور پر، اوپر دی گئی مثال کے لیے، URL ہے `http://127.0.0.1:8080/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`۔ اپنی سائٹ دیکھنے کے لیے اس URL کو براؤزر میں کھولیں۔ + +## اپ لوڈ کرنا {#uploading} + +تو اب آپ مقامی طور پر فائلوں کو پیش کرنے کے لیے IPFS کا استعمال کر سکتے ہیں، جو بہت دلچسپ نہیں ہے۔ اگلا مرحلہ یہ ہے کہ جب آپ آف لائن ہوں تو انہیں دنیا کے لیے دستیاب کرائیں۔ + +کئی مشہور [پننگ سروسز](https://docs.ipfs.tech/concepts/persistence/#pinning-services) ہیں۔ ان میں سے کسی ایک کا انتخاب کریں۔ آپ جو بھی سروس استعمال کرتے ہیں، آپ کو ایک اکاؤنٹ بنانے اور اسے اپنے IPFS ڈیسک ٹاپ میں **مواد شناخت کنندہ (CID)** فراہم کرنے کی ضرورت ہے۔ + +ذاتی طور پر، مجھے استعمال کرنے کے لیے [4EVERLAND](https://docs.4everland.org/storage/4ever-pin/guides) سب سے آسان لگا۔ اس کے لیے ہدایات یہ ہیں: + +1. [ڈیش بورڈ](https://dashboard.4everland.org/overview) پر براؤز کریں اور اپنے والیٹ سے لاگ ان کریں۔ + +2. بائیں سائڈبار میں **Storage > 4EVER Pin** پر کلک کریں۔ + +3. **Upload > Selected CID** پر کلک کریں۔ اپنے مواد کو ایک نام دیں اور IPFS ڈیسک ٹاپ سے CID فراہم کریں۔ فی الحال ایک CID ایک اسٹرنگ ہے جو `Qm` سے شروع ہوتی ہے جس کے بعد 44 حروف اور ہندسے ہوتے ہیں جو ایک [بیس-58 انکوڈڈ](https://medium.com/bootdotdev/base64-vs-base58-encoding-c25553ff4524) ہیش کی نمائندگی کرتے ہیں، جیسے `QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`، لیکن [اس کے تبدیل ہونے کا امکان ہے](https://docs.ipfs.tech/concepts/content-addressing/#version-1-v1)۔ + +4. ابتدائی اسٹیٹس **Queued** ہے۔ دوبارہ لوڈ کریں جب تک کہ یہ **Pinned** میں تبدیل نہ ہو جائے۔ + +5. لنک حاصل کرنے کے لیے اپنے CID پر کلک کریں۔ آپ میری ایپلیکیشن [یہاں](https://bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im/) دیکھ سکتے ہیں۔ + +6. آپ کو اپنے اکاؤنٹ کو ایک مہینے سے زیادہ کے لیے پن کرنے کے لیے اسے فعال کرنے کی ضرورت پڑسکتی ہے۔ اکاؤنٹ ایکٹیویشن کی لاگت تقریباً 1$ ہے۔ اگر آپ نے اسے بند کر دیا ہے، تو لاگ آؤٹ کریں اور دوبارہ فعال کرنے کے لیے پوچھے جانے کے لیے واپس لاگ ان کریں۔ + +## IPFS سے استعمال کرنا {#using-from-ipfs} + +اس وقت آپ کے پاس ایک مرکزی گیٹ وے کا لنک ہے جو آپ کے IPFS مواد کو پیش کرتا ہے۔ مختصر یہ کہ، آپ کا یوزر انٹرفیس تھوڑا محفوظ ہو سکتا ہے لیکن یہ اب بھی سنسر شپ سے مزاحم نہیں ہے۔ حقیقی سنسرشپ مزاحمت کے لیے، یوزرس کو IPFS کو [براہ راست براؤزر سے](https://docs.ipfs.tech/install/ipfs-companion/#prerequisites) استعمال کرنے کی ضرورت ہے۔ + +ایک بار جب آپ اسے انسٹال کر لیتے ہیں (اور ڈیسک ٹاپ IPFS کام کر رہا ہوتا ہے)، تو آپ کسی بھی سائٹ پر [/ipfs/``](https://any.site/ipfs/bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im) پر جا سکتے ہیں اور آپ کو وہ مواد، ایک غیر مرکزی طریقے سے پیش کیا ہوا، مل جائے گا۔ + +## نقصانات {#drawbacks} + +آپ IPFS فائلوں کو قابل اعتماد طریقے سے حذف نہیں کر سکتے، لہذا جب تک آپ اپنے یوزر انٹرفیس میں ترمیم کر رہے ہیں، شاید بہتر ہے کہ اسے یا تو مرکزی چھوڑ دیں، یا [انٹرپلینیٹری نیم سسٹم (IPNS)](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs) کا استعمال کریں، ایک ایسا نظام جو IPFS کے اوپر تغیر پذیری فراہم کرتا ہے۔ یقیناً، کوئی بھی چیز جو قابل تغیر ہے اسے سنسر کیا جا سکتا ہے، IPNS کے معاملے میں اس شخص پر دباؤ ڈال کر جس کے پاس پرائیویٹ کی ہے جس سے یہ مطابقت رکھتا ہے۔ + +مزید برآں، کچھ پیکیجز کو IPFS کے ساتھ مسئلہ ہے، لہذا اگر آپ کی ویب سائٹ بہت پیچیدہ ہے تو یہ ایک اچھا حل نہیں ہو سکتا ہے۔ اور یقیناً، کوئی بھی چیز جو سرور انضمام پر انحصار کرتی ہے اسے صرف IPFS پر کلائنٹ سائیڈ رکھ کر غیر مرکزی نہیں بنایا جا سکتا ہے۔ + +## نتیجہ {#conclusion} + +جس طرح Ethereum آپ کو اپنے ڈیپ (dapp) کے ڈیٹا بیس اور کاروباری منطق کے پہلوؤں کو غیر مرکزی بنانے دیتا ہے، اسی طرح IPFS آپ کو یوزر انٹرفیس کو غیر مرکزی بنانے دیتا ہے۔ یہ آپ کو اپنے ڈیپ (dapp) کے خلاف ایک اور حملے کے ویکٹر کو بند کرنے دیتا ہے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/ur/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md new file mode 100644 index 00000000000..3ede6b5e5f8 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md @@ -0,0 +1,111 @@ +--- +title: "create-eth-app کے ساتھ اپنے ڈیپ فرنٹ اینڈ ڈیولپمنٹ کو کک اسٹارٹ کریں" +description: "create-eth-app کا استعمال کیسے کریں اور اس کی خصوصیات کا ایک جائزہ" +author: "Markus Waas" +tags: + [ + "فرنٹ اینڈ", + "javascript", + "ethers.js", + "دی گراف", + "defi" + ] +skill: beginner +lang: ur-in +published: 2020-04-27 +source: soliditydeveloper.com +sourceUrl: https://soliditydeveloper.com/create-eth-app +--- + +پچھلی بار ہم نے [Solidity کی بڑی تصویر](https://soliditydeveloper.com/solidity-overview-2020) پر نظر ڈالی تھی اور [create-eth-app](https://github.com/PaulRBerg/create-eth-app) کا ذکر بھی کیا تھا۔ اب آپ جانیں گے کہ اسے کیسے استعمال کیا جائے، کون سی خصوصیات اس میں ضم ہیں اور اس کو مزید وسیع کرنے کے اضافی آئیڈیاز کیا ہیں۔ [Sablier](http://sablier.com/) کے بانی، Paul Razvan Berg کے ذریعہ شروع کی گئی، یہ ایپ آپ کے فرنٹ اینڈ ڈیولپمنٹ کو کِک اسٹارٹ کرے گی اور منتخب کرنے کے لیے کئی اختیاری انضمام کے ساتھ آتی ہے۔ + +## انسٹالیشن {#installation} + +انسٹالیشن کے لیے Yarn 0.25 یا اس سے اعلیٰ ورژن کی ضرورت ہے (`npm install yarn --global`)۔ یہ چلانے جتنا ہی آسان ہے: + +```bash +yarn create eth-app my-eth-app +cd my-eth-app +yarn react-app:start +``` + +یہ اندرونی طور پر [create-react-app](https://github.com/facebook/create-react-app) کا استعمال کر رہا ہے۔ اپنی ایپ دیکھنے کے لیے، `http://localhost:3000/` کھولیں۔ جب آپ پروڈکشن میں ڈیپلائے کرنے کے لیے تیار ہوں، تو yarn build کے ساتھ ایک مِنیفائیڈ بنڈل بنائیں۔ اسے ہوسٹ کرنے کا ایک آسان طریقہ [Netlify](https://www.netlify.com/) ہوگا۔ آپ ایک GitHub ریپو بنا سکتے ہیں، اسے Netlify میں شامل کر سکتے ہیں، بلڈ کمانڈ سیٹ اپ کر سکتے ہیں اور بس ہو گیا! آپ کی ایپ ہوسٹ ہو جائے گی اور ہر کسی کے لیے قابل استعمال ہوگی۔ اور یہ سب کچھ مفت ہے۔ + +## خصوصیات {#features} + +### React اور create-react-app {#react--create-react-app} + +سب سے پہلے ایپ کا دل: React اور _create-react-app_ کے ساتھ آنے والی تمام اضافی خصوصیات۔ اگر آپ Ethereum کو انٹیگریٹ نہیں کرنا چاہتے ہیں تو صرف اس کا استعمال کرنا ایک بہترین آپشن ہے۔ [React](https://react.dev/) خود انٹرایکٹو UI بنانا بہت آسان بنا دیتا ہے۔ ہو سکتا ہے یہ [Vue](https://vuejs.org/) کی طرح مبتدیوں کے لیے آسان نہ ہو، لیکن یہ اب بھی زیادہ تر استعمال ہوتا ہے، اس میں زیادہ خصوصیات ہیں اور سب سے اہم بات یہ ہے کہ منتخب کرنے کے لیے ہزاروں اضافی لائبریریاں موجود ہیں۔ _create-react-app_ اس کے ساتھ شروعات کرنا بھی بہت آسان بنا دیتا ہے اور اس میں شامل ہیں: + +- React, JSX, ES6, TypeScript, فلو سنٹیکس سپورٹ۔ +- ES6 سے آگے زبان کی اضافی چیزیں جیسے آبجیکٹ اسپریڈ آپریٹر۔ +- آٹوپریفکسڈ CSS، لہذا آپ کو -webkit- یا دیگر پریفکس کی ضرورت نہیں ہے۔ +- کوریج رپورٹنگ کے لیے بلٹ ان سپورٹ کے ساتھ ایک تیز انٹرایکٹو یونٹ ٹیسٹ رنر۔ +- ایک لائیو ڈیولپمنٹ سرور جو عام غلطیوں کے بارے میں خبردار کرتا ہے۔ +- ہیشز اور سورس میپس کے ساتھ، پروڈکشن کے لیے JS، CSS، اور تصاویر کو بنڈل کرنے کے لیے ایک بلڈ اسکرپٹ۔ + +خاص طور پر _create-eth-app_ نئے [hooks effects](https://legacy.reactjs.org/docs/hooks-effect.html) کا استعمال کر رہا ہے۔ طاقتور، پھر بھی بہت چھوٹے نام نہاد فنکشنل کمپونینٹس لکھنے کا ایک طریقہ۔ _create-eth-app_ میں ان کا استعمال کیسے ہوتا ہے اس کے لیے Apollo کے بارے میں نیچے والا سیکشن دیکھیں۔ + +### Yarn Workspaces {#yarn-workspaces} + +[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) آپ کو ایک سے زیادہ پیکیجز رکھنے کی اجازت دیتے ہیں، لیکن ان سب کو روٹ فولڈر سے منظم کرنے اور `yarn install` کا استعمال کرتے ہوئے سب کے لیے ایک ساتھ ڈیپینڈینسیز انسٹال کرنے کے قابل بناتے ہیں۔ یہ خاص طور پر چھوٹے اضافی پیکیجز کے لیے معنی خیز ہے جیسے کہ اسمارٹ کنٹریکٹس ایڈریس/ABI مینجمنٹ (یہ معلومات کہ آپ نے کون سے اسمارٹ کنٹریکٹس کہاں ڈیپلائے کیے ہیں اور ان کے ساتھ کیسے کمیونیکیٹ کرنا ہے) یا گراف انٹیگریشن، دونوں `create-eth-app` کا حصہ ہیں۔ + +### ethers.js {#ethersjs} + +جبکہ [Web3](https://docs.web3js.org/) اب بھی زیادہ تر استعمال ہوتا ہے، [ethers.js](https://docs.ethers.io/) نے پچھلے سال ایک متبادل کے طور پر بہت زیادہ مقبولیت حاصل کی ہے اور یہی وہ ہے جسے _create-eth-app_ میں انٹیگریٹ کیا گیا ہے۔ آپ اس کے ساتھ کام کر سکتے ہیں، اسے Web3 میں تبدیل کر سکتے ہیں یا [ethers.js v5](https://docs.ethers.org/v5/) میں اپ گریڈ کرنے پر غور کر سکتے ہیں جو تقریباً بیٹا سے باہر ہے۔ + +### دی گراف {#the-graph} + +[GraphQL](https://graphql.org/) ایک [Restful API](https://restfulapi.net/) کے مقابلے میں ڈیٹا کو ہینڈل کرنے کا ایک متبادل طریقہ ہے۔ ان کے Restful Apis پر کئی فوائد ہیں، خاص طور پر وکندریقرت بلاک چین ڈیٹا کے لیے۔ اگر آپ اس کے پیچھے کی وجہ جاننے میں دلچسپی رکھتے ہیں، تو [GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a) پر ایک نظر ڈالیں۔ + +عام طور پر آپ براہ راست اپنے اسمارٹ کنٹریکٹ سے ڈیٹا حاصل کرتے ہیں۔ تازہ ترین ٹریڈ کا وقت پڑھنا چاہتے ہیں؟ بس `MyContract.methods.latestTradeTime().call()` کو کال کریں جو Ethereum نوڈ سے آپ کے ڈی ایپ میں ڈیٹا حاصل کرتا ہے۔ لیکن کیا ہوگا اگر آپ کو سینکڑوں مختلف ڈیٹا پوائنٹس کی ضرورت ہو؟ اس کے نتیجے میں نوڈ پر سینکڑوں ڈیٹا فیچ ہوں گے، جس میں ہر بار [RTT](https://wikipedia.org/wiki/Round-trip_delay_time) کی ضرورت ہوگی، جو آپ کے ڈی ایپ کو سست اور ناکارہ بنا دے گا۔ ایک حل آپ کے کنٹریکٹ کے اندر ایک فیچر کال فنکشن ہو سکتا ہے جو ایک ساتھ ایک سے زیادہ ڈیٹا واپس کرتا ہے۔ اگرچہ یہ ہمیشہ مثالی نہیں ہے۔ + +اور پھر آپ کو تاریخی ڈیٹا میں بھی دلچسپی ہو سکتی ہے۔ آپ نہ صرف آخری ٹریڈ کا وقت جاننا چاہتے ہیں، بلکہ ان تمام ٹریڈز کے اوقات بھی جاننا چاہتے ہیں جو آپ نے خود کیے ہیں۔ _create-eth-app_ سب گراف پیکیج کا استعمال کریں، [ڈاکومنٹیشن](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph) پڑھیں اور اسے اپنے کنٹریکٹس کے مطابق ڈھالیں۔ اگر آپ مقبول اسمارٹ کنٹریکٹس کی تلاش میں ہیں، تو ہو سکتا ہے کہ پہلے سے ہی ایک سب گراف موجود ہو۔ [سب گراف ایکسپلورر](https://thegraph.com/explorer/) دیکھیں۔ + +ایک بار جب آپ کے پاس سب گراف ہو جاتا ہے، تو یہ آپ کو اپنے ڈی ایپ میں ایک سادہ کوئری لکھنے کی اجازت دیتا ہے جو آپ کے لیے درکار تمام اہم بلاک چین ڈیٹا کو بازیافت کرتا ہے، بشمول تاریخی ڈیٹا، اور اس کے لیے صرف ایک فیچ کی ضرورت ہوتی ہے۔ + +### Apollo {#apollo} + +[Apollo Boost](https://www.apollographql.com/docs/react/get-started/) انٹیگریشن کی بدولت آپ آسانی سے اپنے React ڈی ایپ میں گراف کو انٹیگریٹ کر سکتے ہیں۔ خاص طور پر [React hooks and Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks) کا استعمال کرتے وقت، ڈیٹا حاصل کرنا اتنا ہی آسان ہے جتنا کہ اپنے کمپونینٹ میں ایک ہی GraphQl کوئری لکھنا: + +```js +const { loading, error, data } = useQuery(myGraphQlQuery) + +React.useEffect(() => { + if (!loading && !error && data) { + console.log({ data }) + } +}, [loading, error, data]) +``` + +## ٹیمپلیٹس {#templates} + +اس کے علاوہ آپ کئی مختلف ٹیمپلیٹس میں سے انتخاب کر سکتے ہیں۔ اب تک آپ Aave، Compound، UniSwap یا sablier انٹیگریشن استعمال کر سکتے ہیں۔ وہ سبھی پہلے سے بنے سب گراف انٹیگریشنز کے ساتھ اہم سروس اسمارٹ کنٹریکٹ ایڈریسز شامل کرتے ہیں۔ بس ٹیمپلیٹ کو کریشن کمانڈ میں شامل کریں جیسے `yarn create eth-app my-eth-app --with-template aave`۔ + +### Aave {#aave} + +[Aave](https://aave.com/) ایک وکندریقرت رقم قرض دینے والی مارکیٹ ہے۔ ڈیپازیٹرز غیر فعال آمدنی حاصل کرنے کے لیے مارکیٹ کو لیکویڈیٹی فراہم کرتے ہیں، جبکہ قرض لینے والے کولیٹرلز کا استعمال کرکے قرض لے سکتے ہیں۔ Aave کی ایک منفرد خصوصیت [فلیش لونز](https://aave.com/docs/developers/flash-loans) ہیں جو آپ کو بغیر کسی کولیٹرل کے رقم ادھار لینے کی اجازت دیتے ہیں، جب تک کہ آپ ایک ٹرانزیکشن کے اندر قرض واپس کر دیں۔ یہ مفید ہو سکتا ہے، مثال کے طور پر، آربٹریج ٹریڈنگ پر آپ کو اضافی نقد رقم دینے کے لیے۔ + +ٹریڈ کیے گئے ٹوکنز جو آپ کو سود کماتے ہیں انہیں _aTokens_ کہا جاتا ہے۔ + +جب آپ _create-eth-app_ کے ساتھ Aave کو انٹیگریٹ کرنے کا انتخاب کرتے ہیں، تو آپ کو ایک [سب گراف انٹیگریشن](https://docs.aave.com/developers/getting-started/using-graphql) ملے گا۔ Aave، The Graph کا استعمال کرتا ہے اور آپ کو پہلے ہی [Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten) اور [Mainnet](https://thegraph.com/explorer/subgraph/aave/protocol) پر [خام](https://thegraph.com/explorer/subgraph/aave/protocol-raw) یا [فارمیٹ شدہ](https://thegraph.com/explorer/subgraph/aave/protocol) شکل میں کئی استعمال کے لیے تیار سب گراف فراہم کرتا ہے۔ + +![Aave فلیش لون میم – "ہاں، اگر میں اپنا فلیش لون 1 ٹرانزیکشن سے زیادہ وقت تک رکھ سکتا، تو یہ بہت اچھا ہوتا"](./flashloan-meme.png) + +### Compound {#compound} + +[Compound](https://compound.finance/)، Aave کی طرح ہے۔ انٹیگریشن میں نیا [Compound v2 Subgraph](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195) پہلے سے ہی شامل ہے۔ یہاں سود کمانے والے ٹوکنز کو حیرت انگیز طور پر _cTokens_ کہا جاتا ہے۔ + +### Uniswap {#uniswap} + +[Uniswap](https://uniswap.exchange/) ایک وکندریقرت ایکسچینج (DEX) ہے۔ لیکویڈیٹی فراہم کرنے والے ٹریڈ کے دونوں اطراف کے لیے مطلوبہ ٹوکنز یا ایتھر فراہم کرکے فیس کما سکتے ہیں۔ یہ بڑے پیمانے پر استعمال ہوتا ہے اور اس لیے ٹوکنز کی ایک بہت وسیع رینج کے لیے اس کی لیکویڈیٹی سب سے زیادہ ہے۔ آپ اسے آسانی سے اپنے ڈی ایپ میں انٹیگریٹ کر سکتے ہیں، مثال کے طور پر، صارفین کو اپنے ETH کو DAI سے تبدیل کرنے کی اجازت دینے کے لیے۔ + +بدقسمتی سے، اس تحریر کے وقت انٹیگریشن صرف Uniswap v1 کے لیے ہے نہ کہ [ابھی جاری کردہ v2](https://uniswap.org/blog/uniswap-v2/) کے لیے۔ + +### Sablier {#sablier} + +[Sablier](https://sablier.com/) صارفین کو رقم کی ادائیگیوں کو اسٹریم کرنے کی اجازت دیتا ہے۔ ایک ہی تنخواہ کے دن کے بجائے، آپ کو ابتدائی سیٹ اپ کے بعد مزید کسی انتظامی کارروائی کے بغیر مسلسل اپنی رقم ملتی ہے۔ انٹیگریشن میں اس کا [اپنا سب گراف](https://thegraph.com/explorer/subgraph/sablierhq/sablier) شامل ہے۔ + +## آگے کیا ہے؟ {#whats-next} + +اگر آپ کے پاس _create-eth-app_ کے بارے میں سوالات ہیں، تو [Sablier کمیونٹی سرور](https://discord.gg/bsS8T47) پر جائیں، جہاں آپ _create-eth-app_ کے مصنفین سے رابطہ کر سکتے ہیں۔ کچھ پہلے اگلے اقدامات کے طور پر آپ [Material UI](https://mui.com/material-ui/) جیسے UI فریم ورک کو انٹیگریٹ کرنا چاہ سکتے ہیں، اس ڈیٹا کے لیے GraphQL کوئریز لکھیں جس کی آپ کو واقعی ضرورت ہے اور ڈیپلائمنٹ سیٹ اپ کریں۔ diff --git a/public/content/translations/ur/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md b/public/content/translations/ur/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md new file mode 100644 index 00000000000..81ee317b711 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md @@ -0,0 +1,269 @@ +--- +title: "SQL کے ساتھ Ethereum کے بنیادی موضوعات سیکھیں" +description: "یہ ٹیوٹوریل قارئین کو اسٹرکچرڈ کوئری لینگویج (SQL) کے ساتھ آن چین ڈیٹا کو کوئری کر کے ٹرانزیکشن، بلاکس اور گیس سمیت Ethereum کے بنیادی تصورات کو سمجھنے میں مدد کرتا ہے۔" +author: "Paul Apivat" +tags: [ "SQL", "کوئری کرنا", "ٹرانزیکشنز" ] +skill: beginner +lang: ur-in +published: 2021-05-11 +source: paulapivat.com +sourceUrl: https://paulapivat.com/post/query_ethereum/ +--- + +بہت سے Ethereum ٹیوٹوریل ڈیولپرز کو ہدف بناتے ہیں، لیکن ڈیٹا تجزیہ کاروں یا ان لوگوں کے لیے تعلیمی وسائل کی کمی ہے جو کلائنٹ یا نوڈ چلائے بغیر آن چین ڈیٹا دیکھنا چاہتے ہیں۔ + +یہ ٹیوٹوریل قارئین کو [Dune Analytics](https://dune.com/) کے فراہم کردہ انٹرفیس کے ذریعے اسٹرکچرڈ کوئری لینگویج (SQL) کے ساتھ آن چین ڈیٹا کو کوئری کرکے ٹرانزیکشن، بلاکس اور گیس سمیت Ethereum کے بنیادی تصورات کو سمجھنے میں مدد کرتا ہے۔ + +آن چین ڈیٹا ہمیں Ethereum، نیٹ ورک، اور کمپیوٹنگ پاور کے لیے ایک معیشت کو سمجھنے میں مدد کر سکتا ہے اور اسے آج Ethereum کو درپیش چیلنجوں (یعنی گیس کی بڑھتی ہوئی قیمتوں) اور اس سے بھی اہم بات یہ ہے کہ اسکیلنگ کے حل کے بارے میں بات چیت کو سمجھنے کی بنیاد کے طور پر کام کرنا چاہیے۔ + +### ٹرانزیکشنز {#transactions} + +Ethereum پر صارف کا سفر صارف کے زیر کنٹرول اکاؤنٹ یا ETH بیلنس والی کسی ہستی کو شروع کرنے سے شروع ہوتا ہے۔ اکاؤنٹ کی دو قسمیں ہیں - صارف کے زیر کنٹرول یا ایک اسمارٹ کنٹریکٹ (دیکھیں [ethereum.org](/developers/docs/accounts/))۔ + +کسی بھی اکاؤنٹ کو [Etherscan](https://etherscan.io/) یا [Blockscout](https://eth.blockscout.com/) جیسے بلاک ایکسپلورر پر دیکھا جا سکتا ہے۔ بلاک ایکسپلورر Ethereum کے ڈیٹا کا ایک پورٹل ہیں۔ وہ حقیقی وقت میں، بلاکس، ٹرانزیکشنز، مائنرز، اکاؤنٹس اور دیگر آن چین سرگرمیوں پر ڈیٹا دکھاتے ہیں (یہاں دیکھیں [here](/developers/docs/data-and-analytics/block-explorers/))۔ + +تاہم، ایک صارف بیرونی بلاک ایکسپلوررز کے ذریعہ فراہم کردہ معلومات کو ہم آہنگ کرنے کے لیے براہ راست ڈیٹا کو کوئری کرنا چاہے گا۔ [Dune Analytics](https://dune.com/) SQL کے کچھ علم رکھنے والے کسی بھی شخص کو یہ صلاحیت فراہم کرتا ہے۔ + +حوالہ کے لیے، Ethereum فاؤنڈیشن (EF) کے لیے اسمارٹ کنٹریکٹ اکاؤنٹ کو [Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) پر دیکھا جا سکتا ہے۔ + +ایک بات قابل غور ہے کہ تمام اکاؤنٹس، بشمول EF کے، کا ایک عوامی پتہ ہوتا ہے جسے ٹرانزیکشن بھیجنے اور وصول کرنے کے لیے استعمال کیا جا سکتا ہے۔ + +Etherscan پر اکاؤنٹ کا بیلنس باقاعدہ ٹرانزیکشنز اور اندرونی ٹرانزیکشنز پر مشتمل ہوتا ہے۔ اندرونی ٹرانزیکشنز، نام کے باوجود، _اصل_ ٹرانزیکشنز نہیں ہیں جو چین کی حالت کو بدلتی ہیں۔ وہ ایک معاہدے کو انجام دینے کے ذریعے شروع کی گئی قدر کی منتقلی ہیں ([source](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions))۔ چونکہ اندرونی ٹرانزیکشنز پر کوئی دستخط نہیں ہوتے ہیں، اس لیے وہ بلاک چین میں شامل **نہیں** ہوتے ہیں اور انہیں Dune Analytics سے کوئری نہیں کیا جا سکتا۔ + +لہذا، یہ ٹیوٹوریل باقاعدہ ٹرانزیکشنز پر توجہ مرکوز کرے گا۔ اسے اس طرح کوئری کیا جا سکتا ہے: + +```sql +WITH temp_table AS ( +SELECT + hash, + block_number, + block_time, + "from", + "to", + value / 1e18 AS ether, + gas_used, + gas_price / 1e9 AS gas_price_gwei +FROM ethereum."transactions" +WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe' +ORDER BY block_time DESC +) +SELECT + hash, + block_number, + block_time, + "from", + "to", + ether, + (gas_used * gas_price_gwei) / 1e9 AS txn_fee +FROM temp_table +``` + +اس سے وہی معلومات حاصل ہوں گی جو Etherscan کے ٹرانزیکشن پیج پر فراہم کی گئی ہیں۔ موازنہ کے لیے، یہاں دو ذرائع ہیں: + +#### Etherscan {#etherscan} + +![](./etherscan_view.png) + +[Blockscout پر EF کا کنٹریکٹ پیج۔](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) + +#### ڈیون اینالیٹکس {#dune-analytics} + +![](./dune_view.png) + +آپ ڈیش بورڈ [یہاں](https://dune.com/paulapivat/Learn-Ethereum) تلاش کر سکتے ہیں۔ کوئری دیکھنے کے لیے ٹیبل پر کلک کریں (اوپر بھی دیکھیں)۔ + +### ٹرانزیکشنز کو توڑنا {#breaking_down_transactions} + +جمع کرائی گئی ٹرانزیکشن میں کئی معلومات شامل ہوتی ہیں ([source](/developers/docs/transactions/)): + +- **وصول کنندہ**: وصول کرنے والا پتہ ("to" کے طور پر کوئری کیا گیا) +- **دستخط**: جبکہ بھیجنے والے کی نجی کلیدیں کسی ٹرانزیکشن پر دستخط کرتی ہیں، جو ہم SQL کے ساتھ کوئری کر سکتے ہیں وہ بھیجنے والے کا عوامی پتہ ہے ("from")۔ +- **قدر**: یہ منتقل شدہ ETH کی رقم ہے (`ether` کالم دیکھیں)۔ +- **ڈیٹا**: یہ صوابدیدی ڈیٹا ہے جسے ہیش کیا گیا ہے (`data` کالم دیکھیں) +- **gasLimit** – گیس یونٹس کی زیادہ سے زیادہ مقدار جو ٹرانزیکشن کے ذریعے استعمال کی جا سکتی ہے۔ گیس کی اکائیاں کمپیوٹیشنل مراحل کی نمائندگی کرتی ہیں +- **maxPriorityFeePerGas** - گیس کی زیادہ سے زیادہ مقدار جو مائنر کو ٹپ کے طور پر شامل کی جائے گی +- **maxFeePerGas** - ٹرانزیکشن کے لیے ادا کی جانے والی گیس کی زیادہ سے زیادہ مقدار (بشمول baseFeePerGas اور maxPriorityFeePerGas) + +ہم Ethereum فاؤنڈیشن کے عوامی پتے پر ٹرانزیکشنز کے لیے معلومات کے ان مخصوص ٹکڑوں کو کوئری کر سکتے ہیں: + +```sql +SELECT + "to", + "from", + value / 1e18 AS ether, + data, + gas_limit, + gas_price / 1e9 AS gas_price_gwei, + gas_used, + ROUND(((gas_used / gas_limit) * 100),2) AS gas_used_pct +FROM ethereum."transactions" +WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe' +ORDER BY block_time DESC +``` + +### بلاکس {#blocks} + +ہر ٹرانزیکشن Ethereum ورچوئل مشین ([EVM](/developers/docs/evm/)) کی حالت کو بدل دے گی ([source](/developers/docs/transactions/))۔ ٹرانزیکشنز کو تصدیق اور بلاک میں شامل کرنے کے لیے نیٹ ورک پر نشر کیا جاتا ہے۔ ہر ٹرانزیکشن ایک بلاک نمبر سے منسلک ہے۔ ڈیٹا دیکھنے کے لیے، ہم ایک مخصوص بلاک نمبر کو کوئری کر سکتے ہیں: 12396854 (اس تحریر کے مطابق Ethereum فاؤنڈیشن ٹرانزیکشنز میں سب سے حالیہ بلاک، 11/5/21)۔ + +مزید برآں، جب ہم اگلے دو بلاکس کو کوئری کرتے ہیں، تو ہم دیکھ سکتے ہیں کہ ہر بلاک میں پچھلے بلاک کا ہیش (یعنی پیرنٹ ہیش) ہوتا ہے، جو یہ ظاہر کرتا ہے کہ بلاک چین کیسے بنتا ہے۔ + +ہر بلاک میں اس کے پیرنٹ بلاک کا حوالہ ہوتا ہے۔ یہ نیچے `hash` اور `parent_hash` کالموں کے درمیان دکھایا گیا ہے ([source](/developers/docs/blocks/)): + +![parent_hash](./parent_hash.png) + +Dune Analytics پر [query](https://dune.com/queries/44856/88292) یہ ہے: + +```sql +SELECT + time, + number, + hash, + parent_hash, + nonce +FROM ethereum."blocks" +WHERE "number" = 12396854 OR "number" = 12396855 OR "number" = 12396856 +LIMIT 10 +``` + +ہم وقت، بلاک نمبر، مشکل، ہیش، پیرنٹ ہیش، اور نونس کو کوئری کرکے ایک بلاک کا جائزہ لے سکتے ہیں۔ + +صرف ایک چیز جس کا یہ کوئری احاطہ نہیں کرتی ہے وہ ہے _ٹرانزیکشن کی فہرست_ جس کے لیے نیچے ایک الگ کوئری اور _اسٹیٹ روٹ_ درکار ہے۔ ایک مکمل یا آرکائیول نوڈ تمام ٹرانزیکشنز اور اسٹیٹ ٹرانزیشن کو اسٹور کرے گا، جس سے کلائنٹس کو کسی بھی وقت چین کی حالت کو کوئری کرنے کی اجازت ملے گی۔ چونکہ اس کے لیے بڑی اسٹوریج کی جگہ درکار ہے، ہم چین ڈیٹا کو اسٹیٹ ڈیٹا سے الگ کر سکتے ہیں: + +- چین ڈیٹا (بلاکس، ٹرانزیکشنز کی فہرست) +- اسٹیٹ ڈیٹا (ہر ٹرانزیکشن کے اسٹیٹ ٹرانزیشن کا نتیجہ) + +اسٹیٹ روٹ بعد میں آتا ہے اور یہ _مضمر_ ڈیٹا ہے (آن چین ذخیرہ نہیں کیا گیا)، جبکہ چین ڈیٹا واضح ہے اور خود چین پر ذخیرہ کیا گیا ہے ([source](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored))۔ + +اس ٹیوٹوریل کے لیے، ہم آن چین ڈیٹا پر توجہ مرکوز کریں گے جسے Dune Analytics کے ذریعے SQL کے ساتھ _کوئری_ کیا جا سکتا ہے۔ + +جیسا کہ اوپر بیان کیا گیا ہے، ہر بلاک میں ٹرانزیکشنز کی ایک فہرست ہوتی ہے، ہم اسے ایک مخصوص بلاک کے لیے فلٹر کرکے کوئری کر سکتے ہیں۔ ہم سب سے حالیہ بلاک، 12396854 کو آزمائیں گے: + +```sql +SELECT * FROM ethereum."transactions" +WHERE block_number = 12396854 +ORDER BY block_time DESC` +``` + +Dune پر SQL آؤٹ پٹ یہ ہے: + +![](./list_of_txn.png) + +چین میں شامل کیا جانے والا یہ واحد بلاک Ethereum ورچوئل مشین ([EVM](/developers/docs/evm/)) کی حالت کو بدل دیتا ہے۔ درجنوں، کبھی کبھی سینکڑوں ٹرانزیکشنز ایک ساتھ تصدیق کی جاتی ہیں۔ اس مخصوص معاملے میں، 222 ٹرانزیکشنز شامل تھیں۔ + +یہ دیکھنے کے لیے کہ کتنے واقعی کامیاب ہوئے، ہم کامیاب ٹرانزیکشنز کو گننے کے لیے ایک اور فلٹر شامل کریں گے: + +```sql +WITH temp_table AS ( + SELECT * FROM ethereum."transactions" + WHERE block_number = 12396854 AND success = true + ORDER BY block_time DESC +) +SELECT + COUNT(success) AS num_successful_txn +FROM temp_table +``` + +بلاک 12396854 کے لیے، کل 222 ٹرانزیکشنز میں سے، 204 کی کامیابی سے تصدیق کی گئی: + +![](./successful_txn.png) + +ٹرانزیکشن کی درخواستیں فی سیکنڈ درجنوں بار ہوتی ہیں، لیکن بلاکس تقریباً ہر 15 سیکنڈ میں ایک بار کمٹ کیے جاتے ہیں ([source](/developers/docs/blocks/))۔ + +یہ دیکھنے کے لیے کہ تقریباً ہر 15 سیکنڈ میں ایک بلاک تیار ہوتا ہے، ہم ایک دن میں سیکنڈز کی تعداد (86400) کو 15 سے تقسیم کر کے روزانہ بلاکس کی تخمینی اوسط تعداد (~ 5760) حاصل کر سکتے ہیں۔ + +روزانہ تیار ہونے والے Ethereum بلاکس (2016 - حال) کا چارٹ یہ ہے: + +![](./daily_blocks.png) + +اس مدت میں روزانہ تیار ہونے والے بلاکس کی اوسط تعداد ~5,874 ہے: + +![](./avg_daily_blocks.png) + +کوئریز یہ ہیں: + +```sql +# 2016 سے روزانہ تیار ہونے والے بلاکس کی تعداد کا تصور کرنے کے لیے کوئری + +SELECT + DATE_TRUNC('day', time) AS dt, + COUNT(*) AS block_count +FROM ethereum."blocks" +GROUP BY dt +OFFSET 1 + +# روزانہ تیار ہونے والے بلاکس کی اوسط تعداد + +WITH temp_table AS ( +SELECT + DATE_TRUNC('day', time) AS dt, + COUNT(*) AS block_count +FROM ethereum."blocks" +GROUP BY dt +OFFSET 1 +) +SELECT + AVG(block_count) AS avg_block_count +FROM temp_table +``` + +2016 سے روزانہ تیار ہونے والے بلاکس کی اوسط تعداد 5,874 پر اس تعداد سے قدرے زیادہ ہے۔ متبادل طور پر، 86400 سیکنڈ کو 5874 اوسط بلاکس سے تقسیم کرنے پر 14.7 سیکنڈ یا تقریباً ہر 15 سیکنڈ میں ایک بلاک آتا ہے۔ + +### گیس {#gas} + +بلاکس سائز میں محدود ہیں۔ زیادہ سے زیادہ بلاک کا سائز متحرک ہے اور نیٹ ورک کی طلب کے مطابق 12,500,000 اور 25,000,000 یونٹس کے درمیان مختلف ہوتا ہے۔ ڈسک کی جگہ اور رفتار کی ضروریات کے لحاظ سے مکمل نوڈس پر دباؤ ڈالنے والے من مانے بڑے بلاک سائز کو روکنے کے لیے حدود کی ضرورت ہوتی ہے ([source](/developers/docs/blocks/))۔ + +بلاک گیس کی حد کا تصور کرنے کا ایک طریقہ یہ ہے کہ اسے دستیاب بلاک کی جگہ کی **سپلائی** کے طور پر سوچا جائے جس میں ٹرانزیکشنز کو بیچ کیا جائے۔ بلاک گیس کی حد کو 2016 سے آج تک کوئری اور تصور کیا جا سکتا ہے: + +![](./avg_gas_limit.png) + +```sql +SELECT + DATE_TRUNC('day', time) AS dt, + AVG(gas_limit) AS avg_block_gas_limit +FROM ethereum."blocks" +GROUP BY dt +OFFSET 1 +``` + +پھر Ethereum چین پر کیے گئے کمپیوٹنگ کی ادائیگی کے لیے روزانہ استعمال ہونے والی اصل گیس ہے (یعنی ٹرانزیکشن بھیجنا، اسمارٹ کنٹریکٹ کو کال کرنا، NFT منٹ کرنا)۔ یہ دستیاب Ethereum بلاک کی جگہ کے لیے **ڈیمانڈ** ہے: + +![](./daily_gas_used.png) + +```sql +SELECT + DATE_TRUNC('day', time) AS dt, + AVG(gas_used) AS avg_block_gas_used +FROM ethereum."blocks" +GROUP BY dt +OFFSET 1 +``` + +ہم ان دونوں چارٹس کو ایک ساتھ جوڑ کر یہ بھی دیکھ سکتے ہیں کہ **ڈیمانڈ اور سپلائی** کس طرح صف بندی کرتے ہیں: + +![gas_demand_supply](./gas_demand_supply.png) + +لہذا ہم گیس کی قیمتوں کو Ethereum بلاک کی جگہ کی طلب کے ایک فنکشن کے طور پر سمجھ سکتے ہیں، دی گئی دستیاب سپلائی۔ + +آخر میں، ہم Ethereum چین کے لیے اوسط روزانہ گیس کی قیمتوں کو کوئری کرنا چاہیں گے، تاہم، ایسا کرنے سے خاص طور پر طویل کوئری وقت کا نتیجہ ہوگا، لہذا ہم اپنی کوئری کو Ethereum فاؤنڈیشن کی طرف سے فی ٹرانزیکشن ادا کی گئی گیس کی اوسط رقم تک فلٹر کریں گے۔ + +![](./ef_daily_gas.png) + +ہم سالوں کے دوران Ethereum فاؤنڈیشن کے پتے پر کی گئی تمام ٹرانزیکشنز کے لیے ادا کی گئی گیس کی قیمتیں دیکھ سکتے ہیں۔ کوئری یہ ہے: + +```sql +SELECT + block_time, + gas_price / 1e9 AS gas_price_gwei, + value / 1e18 AS eth_sent +FROM ethereum."transactions" +WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe' +ORDER BY block_time DESC +``` + +### خلاصہ {#summary} + +اس ٹیوٹوریل کے ساتھ، ہم آن چین ڈیٹا کو کوئری کرکے اور اس کا احساس حاصل کرکے Ethereum کے بنیادی تصورات اور Ethereum بلاک چین کے کام کرنے کے طریقے کو سمجھتے ہیں۔ + +اس ٹیوٹوریل میں استعمال ہونے والا تمام کوڈ رکھنے والا ڈیش بورڈ [یہاں](https://dune.com/paulapivat/Learn-Ethereum) پایا جا سکتا ہے۔ + +web3 کو دریافت کرنے کے لیے ڈیٹا کے مزید استعمال کے لیے [مجھے ٹویٹر پر تلاش کریں](https://twitter.com/paulapivat)۔ diff --git a/public/content/translations/ur/developers/tutorials/logging-events-smart-contracts/index.md b/public/content/translations/ur/developers/tutorials/logging-events-smart-contracts/index.md new file mode 100644 index 00000000000..48b65b59bfc --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/logging-events-smart-contracts/index.md @@ -0,0 +1,62 @@ +--- +title: "ایونٹس کے ساتھ سمارٹ معاہدوں سے ڈیٹا لاگ کرنا" +description: "اسمارٹ کنٹریکٹ ایونٹس کا تعارف اور آپ ڈیٹا لاگ کرنے کے لیے انہیں کیسے استعمال کر سکتے ہیں۔" +author: "jdourlens" +tags: [ "اسمارٹ معاہدات", "remix", "solidity", "ایونٹس" ] +skill: intermediate +lang: ur-in +published: 2020-04-03 +source: EthereumDev +sourceUrl: https://ethereumdev.io/logging-data-with-events/ +address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" +--- + +سولیڈٹی میں، [ایونٹس](/developers/docs/smart-contracts/anatomy/#events-and-logs) بھیجے گئے سگنل ہیں جنہیں سمارٹ معاہدے فائر کر سکتے ہیں۔ Dapps، یا ایتھیریم JSON-RPC API سے منسلک کوئی بھی چیز، ان ایونٹس کو سن سکتی ہے اور اسی کے مطابق کارروائی کر سکتی ہے۔ ایک ایونٹ کو انڈیکس بھی کیا جا سکتا ہے تاکہ بعد میں ایونٹ کی تاریخ کو تلاش کیا جا سکے۔ + +## ایونٹس {#events} + +اس مضمون کو لکھنے کے وقت ایتھیریم بلاک چین پر سب سے عام ایونٹ ٹرانسفر ایونٹ ہے جو ERC20 ٹوکنز کے ذریعے خارج ہوتا ہے جب کوئی ٹوکنز منتقل کرتا ہے۔ + +```solidity +event Transfer(address indexed from, address indexed to, uint256 value); +``` + +ایونٹ کے دستخط کا اعلان کنٹریکٹ کوڈ کے اندر کیا جاتا ہے اور اسے emit کلیدی لفظ کے ساتھ خارج کیا جا سکتا ہے۔ مثال کے طور پر، ٹرانسفر ایونٹ لاگ کرتا ہے کہ ٹرانسفر کس نے بھیجا (_from_)، کس کو بھیجا (_to_) اور کتنے ٹوکن منتقل کیے گئے (_value_)۔ + +اگر ہم اپنے کاؤنٹر سمارٹ معاہدے پر واپس جائیں اور ہر بار قدر میں تبدیلی کو لاگ کرنے کا فیصلہ کریں۔ چونکہ اس معاہدے کا مقصد تعینات کرنا نہیں ہے بلکہ اسے بڑھا کر ایک اور معاہدہ بنانے کی بنیاد کے طور پر کام کرنا ہے: اسے ایک تجریدی معاہدہ کہا جاتا ہے۔ ہماری کاؤنٹر مثال کے معاملے میں، یہ اس طرح نظر آئے گا: + +```solidity +pragma solidity 0.5.17; + +contract Counter { + + event ValueChanged(uint oldValue, uint256 newValue); + + // گنتی کی تعداد رکھنے کے لیے غیر دستخط شدہ int قسم کا نجی متغیر + uint256 private count = 0; + + // فنکشن جو ہمارے کاؤنٹر کو بڑھاتا ہے + function increment() public { + count += 1; + emit ValueChanged(count - 1, count); + } + + // گنتی کی قدر حاصل کرنے کے لیے گیٹر + function getCount() public view returns (uint256) { + return count; + } + +} +``` + +نوٹ کریں کہ: + +- **لائن 5** : ہم اپنے ایونٹ اور اس میں کیا شامل ہے، پرانی قدر اور نئی قدر کا اعلان کرتے ہیں۔ + +- **لائن 13** : جب ہم اپنے گنتی متغیر کو بڑھاتے ہیں، تو ہم ایونٹ خارج کرتے ہیں۔ + +اگر ہم اب معاہدہ تعینات کرتے ہیں اور انکریمنٹ فنکشن کو کال کرتے ہیں، تو ہم دیکھیں گے کہ اگر آپ لاگز نامی ایک صف کے اندر نئی ٹرانزیکشن پر کلک کرتے ہیں تو Remix اسے خود بخود ڈسپلے کر دے گا۔ + +![ری مکس اسکرین شاٹ](./remix-screenshot.png) + +لاگز آپ کے سمارٹ معاہدوں کو ڈی بگ کرنے کے لیے واقعی مفید ہیں لیکن اگر آپ مختلف لوگوں کے ذریعے استعمال کی جانے والی ایپلیکیشنز بناتے ہیں تو یہ بھی اہم ہیں اور آپ کے سمارٹ معاہدے کے استعمال کو ٹریک کرنے اور سمجھنے کے لیے تجزیات کرنا آسان بناتے ہیں۔ ٹرانزیکشنز کے ذریعے تیار کردہ لاگز مشہور بلاک ایکسپلوررز میں دکھائے جاتے ہیں اور آپ مثال کے طور پر مخصوص ایونٹس کو سننے اور ان کے ہونے پر کارروائی کرنے کے لیے آف چین اسکرپٹ بنانے کے لیے بھی ان کا استعمال کر سکتے ہیں۔ diff --git a/public/content/translations/ur/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/ur/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md new file mode 100644 index 00000000000..eafa36df48b --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md @@ -0,0 +1,247 @@ +--- +title: "آف لائن ڈیٹا کی سالمیت کے لیے مرکل پروفس" +description: "ایسے ڈیٹا کے لیے آن چین ڈیٹا کی سالمیت کو یقینی بنانا جو زیادہ تر آف چین اسٹور کیا جاتا ہے" +author: Ori Pomerantz +tags: [ "اسٹوریج" ] +skill: advanced +lang: ur-in +published: 2021-12-30 +--- + +## تعارف {#introduction} + +مثالی طور پر ہم ہر چیز کو Ethereum اسٹوریج میں اسٹور کرنا چاہیں گے، جو ہزاروں کمپیوٹرز میں اسٹور ہوتا ہے اور اس میں +انتہائی زیادہ دستیابی (ڈیٹا کو سنسر نہیں کیا جا سکتا) اور سالمیت (ڈیٹا کو غیر مجاز طریقے سے تبدیل نہیں کیا جا سکتا) ہوتی ہے، لیکن 32-بائٹ ورڈ کو اسٹور کرنے پر عام طور پر 20,000 گیس خرچ ہوتی ہے۔ جب میں یہ لکھ رہا ہوں، تو یہ لاگت $6.60 کے برابر ہے۔ 21 سینٹ فی بائٹ پر یہ بہت سے استعمالات کے لیے بہت مہنگا ہے۔ + +اس مسئلے کو حل کرنے کے لیے Ethereum ایکو سسٹم نے [ڈیٹا کو وکندریقرت طریقے سے اسٹور کرنے کے بہت سے متبادل طریقے](/developers/docs/storage/) تیار کیے ہیں۔ عام طور پر ان میں دستیابی اور قیمت کے درمیان ایک سمجھوتہ شامل ہوتا ہے۔ تاہم، سالمیت کو عام طور پر یقینی بنایا جاتا ہے۔ + +اس مضمون میں آپ سیکھیں گے کہ [مرکل پروفس](https://computersciencewiki.org/index.php/Merkle_proof) کا استعمال کرتے ہوئے، بلاک چین پر ڈیٹا اسٹور کیے بغیر ڈیٹا کی سالمیت کو **کیسے** یقینی بنایا جائے۔ + +## یہ کیسے کام کرتا ہے؟ {#how-does-it-work} + +نظریاتی طور پر ہم صرف ڈیٹا کا ہیش آن چین اسٹور کر سکتے ہیں، اور تمام ڈیٹا کو ان ٹرانزیکشنز میں بھیج سکتے ہیں جن میں اس کی ضرورت ہوتی ہے۔ تاہم، یہ اب بھی بہت مہنگا ہے۔ ایک ٹرانزیکشن میں ایک بائٹ ڈیٹا کی لاگت تقریباً 16 گیس ہوتی ہے، جو فی الحال تقریباً آدھا سینٹ، یا تقریباً 5 ڈالر فی کلو بائٹ ہے۔ 5000 ڈالر فی میگا بائٹ پر، یہ بہت سے استعمالات کے لیے اب بھی بہت مہنگا ہے، یہاں تک کہ ڈیٹا کو ہیش کرنے کی اضافی لاگت کے بغیر بھی۔ + +اس کا حل یہ ہے کہ ڈیٹا کے مختلف سب سیٹس کو بار بار ہیش کیا جائے، تاکہ جس ڈیٹا کو آپ کو بھیجنے کی ضرورت نہیں ہے اس کے لیے آپ صرف ایک ہیش بھیج سکیں۔ آپ یہ ایک مرکل ٹری کا استعمال کرتے ہوئے کرتے ہیں، جو ایک ٹری ڈیٹا اسٹرکچر ہے جہاں ہر نوڈ اس کے نیچے موجود نوڈس کا ہیش ہوتا ہے: + +![مرکل ٹری](tree.png) + +روٹ ہیش واحد حصہ ہے جسے آن چین اسٹور کرنے کی ضرورت ہے۔ ایک خاص قدر کو ثابت کرنے کے لیے، آپ وہ تمام ہیش فراہم کرتے ہیں جنہیں روٹ حاصل کرنے کے لیے اس کے ساتھ ملانے کی ضرورت ہوتی ہے۔ مثال کے طور پر، `C` کو ثابت کرنے کے لیے آپ `D`، `H(A-B)`، اور `H(E-H)` فراہم کرتے ہیں۔ + +![C کی قدر کا ثبوت](proof-c.png) + +## عمل درآمد {#implementation} + +[نمونہ کوڈ یہاں فراہم کیا گیا ہے](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity)۔ + +### آف چین کوڈ {#offchain-code} + +اس مضمون میں ہم آف چین حسابات کے لیے JavaScript کا استعمال کرتے ہیں۔ زیادہ تر وکندریقرت ایپلی کیشنز کا آف چین جزو JavaScript میں ہوتا ہے۔ + +#### مرکل روٹ بنانا {#creating-the-merkle-root} + +سب سے پہلے ہمیں چین کو مرکل روٹ فراہم کرنے کی ضرورت ہے۔ + +```javascript +const ethers = require("ethers") +``` + +[ہم ethers پیکیج سے ہیش فنکشن کا استعمال کرتے ہیں](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256)۔ + +```javascript +// وہ خام ڈیٹا جس کی سالمیت کی ہمیں تصدیق کرنی ہے۔ پہلے دو بائٹس +// ایک صارف کی شناخت ہیں، اور آخری دو بائٹس اس صارف کے پاس موجود ٹوکنز کی +// مقدار ہیں۔ +const dataArray = [ + 0x0bad0010, 0x60a70020, 0xbeef0030, 0xdead0040, 0xca110050, 0x0e660060, + 0xface0070, 0xbad00080, 0x060d0091, +] +``` + +ہر اندراج کو ایک 256-بٹ انٹیجر میں انکوڈ کرنے سے، مثال کے طور پر JSON استعمال کرنے کے مقابلے میں، کم پڑھنے کے قابل کوڈ بنتا ہے۔ تاہم، اس کا مطلب ہے کہ کنٹریکٹ میں ڈیٹا کو بازیافت کرنے کے لیے کافی کم پروسیسنگ کی ضرورت ہوتی ہے، اس لیے گیس کی لاگت بہت کم ہوتی ہے۔ [آپ آن چین پر JSON پڑھ سکتے ہیں](https://github.com/chrisdotn/jsmnSol)، لیکن اگر اس سے بچا جا سکے تو یہ ایک برا خیال ہے۔ + +```javascript +// ہیش ویلیوز کا ایرے، بطور BigInts +const hashArray = dataArray +``` + +اس معاملے میں ہمارا ڈیٹا شروع میں 256-بٹ ویلیوز ہے، اس لیے کسی پروسیسنگ کی ضرورت نہیں ہے۔ اگر ہم زیادہ پیچیدہ ڈیٹا اسٹرکچر، جیسے کہ اسٹرنگز، استعمال کرتے ہیں، تو ہمیں یہ یقینی بنانا ہوگا کہ ہم ہیشز کا ایک ایرے حاصل کرنے کے لیے پہلے ڈیٹا کو ہیش کریں۔ نوٹ کریں کہ یہ اس لیے بھی ہے کہ ہمیں اس بات کی پرواہ نہیں ہے کہ آیا صارفین دوسرے صارفین کی معلومات جانتے ہیں۔ بصورت دیگر ہمیں ہیش کرنا پڑتا تاکہ صارف 1 کو صارف 0 کی قدر معلوم نہ ہو، صارف 2 کو صارف 3 کی قدر معلوم نہ ہو، وغیرہ۔ + +```javascript +// ہیش فنکشن جس اسٹرنگ کی توقع کرتا ہے اور جو BigInt +// ہم ہر جگہ استعمال کرتے ہیں، ان کے درمیان تبدیل کریں۔ +const hash = (x) => + BigInt(ethers.utils.keccak256("0x" + x.toString(16).padStart(64, 0))) +``` + +ethers ہیش فنکشن ایک ہیکساڈیسیمل نمبر کے ساتھ ایک JavaScript اسٹرنگ حاصل کرنے کی توقع رکھتا ہے، جیسے `0x60A7`، اور اسی ساخت کے ساتھ ایک اور اسٹرنگ کے ساتھ جواب دیتا ہے۔ تاہم، باقی کوڈ کے لیے `BigInt` کا استعمال کرنا آسان ہے، اس لیے ہم ایک ہیکساڈیسیمل اسٹرنگ میں تبدیل کرتے ہیں اور پھر واپس۔ + +```javascript +// ایک جوڑے کا سیمیٹریکل ہیش تاکہ ہمیں پرواہ نہ ہو کہ ترتیب الٹ دی گئی ہے۔ +const pairHash = (a, b) => hash(hash(a) ^ hash(b)) +``` + +یہ فنکشن سیمیٹریکل ہے (a [xor](https://en.wikipedia.org/wiki/Exclusive_or) b کا ہیش)۔ اس کا مطلب ہے کہ جب ہم مرکل پروف کی جانچ کرتے ہیں تو ہمیں اس بارے میں فکر کرنے کی ضرورت نہیں ہے کہ پروف سے حاصل کردہ قدر کو حسابی قدر سے پہلے رکھنا ہے یا بعد میں۔ مرکل پروف کی جانچ آن چین کی جاتی ہے، لہذا ہمیں وہاں جتنا کم کام کرنے کی ضرورت ہوگی، اتنا ہی بہتر ہے۔ + +انتباہ: +کرپٹوگرافی جتنی نظر آتی ہے اس سے زیادہ مشکل ہے۔ +اس مضمون کے ابتدائی ورژن میں ہیش فنکشن `hash(a^b)` تھا۔ +یہ ایک **برا** خیال تھا کیونکہ اس کا مطلب یہ تھا کہ اگر آپ کو `a` اور `b` کی جائز قدریں معلوم ہوتیں تو آپ کسی بھی مطلوبہ `a'` قدر کو ثابت کرنے کے لیے `b' = a^b^a'` کا استعمال کر سکتے تھے۔ +اس فنکشن کے ساتھ آپ کو `b'` کا حساب لگانا ہوگا تاکہ `hash(a') ^ hash(b')` ایک معلوم قدر (روٹ کے راستے پر اگلی شاخ) کے برابر ہو، جو کہ بہت زیادہ مشکل ہے۔ + +```javascript +// یہ قدر یہ ظاہر کرنے کے لیے کہ ایک خاص شاخ خالی ہے، اس میں +// کوئی قدر نہیں ہے +const empty = 0n +``` + +جب قدروں کی تعداد دو کی انٹیجر پاور نہیں ہوتی ہے تو ہمیں خالی شاخوں کو ہینڈل کرنے کی ضرورت ہوتی ہے۔ یہ پروگرام جس طرح سے یہ کرتا ہے وہ یہ ہے کہ صفر کو ایک پلیس ہولڈر کے طور پر رکھتا ہے۔ + +![غائب شاخوں کے ساتھ مرکل ٹری](merkle-empty-hash.png) + +```javascript +// ایک ہیش ایرے کے ٹری میں ایک لیول اوپر کا حساب لگائیں، ہر جوڑے کا +// ترتیب سے ہیش لے کر +const oneLevelUp = (inputArray) => { + var result = [] + var inp = [...inputArray] // ان پٹ پر اوور رائٹنگ سے بچنے کے لیے // اگر ضروری ہو تو ایک خالی قدر شامل کریں (ہمیں تمام لیوز کو // جوڑا بنانے کی ضرورت ہے) + + if (inp.length % 2 === 1) inp.push(empty) + + for (var i = 0; i < inp.length; i += 2) + result.push(pairHash(inp[i], inp[i + 1])) + + return result +} // oneLevelUp +``` + +یہ فنکشن موجودہ لیئر پر قدروں کے جوڑوں کو ہیش کرکے مرکل ٹری میں ایک لیول "اوپر چڑھتا" ہے۔ نوٹ کریں کہ یہ سب سے موثر عمل درآمد نہیں ہے، ہم ان پٹ کو کاپی کرنے سے بچ سکتے تھے اور لوپ میں مناسب ہونے پر صرف `hashEmpty` شامل کر سکتے تھے، لیکن یہ کوڈ پڑھنے کی اہلیت کے لیے بہتر بنایا گیا ہے۔ + +```javascript +const getMerkleRoot = (inputArray) => { + var result + + result = [...inputArray] // ٹری پر اس وقت تک چڑھیں جب تک کہ صرف ایک قدر نہ رہ جائے، جو کہ // روٹ ہے۔ // // اگر کسی لیئر میں اندراجات کی تعداد طاق ہے تو // oneLevelUp میں موجود کوڈ ایک خالی قدر شامل کرتا ہے، لہذا اگر ہمارے پاس، مثال کے طور پر، // 10 لیوز ہیں تو ہمارے پاس دوسری لیئر میں 5 شاخیں، تیسری میں 3 // شاخیں، چوتھی میں 2 ہوں گی اور روٹ پانچواں ہے + + while (result.length > 1) result = oneLevelUp(result) + + return result[0] +} +``` + +روٹ حاصل کرنے کے لیے، اس وقت تک چڑھیں جب تک کہ صرف ایک قدر باقی نہ رہ جائے۔ + +#### مرکل پروف بنانا {#creating-a-merkle-proof} + +مرکل پروف وہ قدریں ہیں جنہیں ثابت کی جانے والی قدر کے ساتھ ہیش کرکے مرکل روٹ واپس حاصل کیا جاتا ہے۔ ثابت کرنے کی قدر اکثر دوسرے ڈیٹا سے دستیاب ہوتی ہے، اس لیے میں اسے کوڈ کے حصے کے طور پر فراہم کرنے کے بجائے الگ سے فراہم کرنا پسند کرتا ہوں۔ + +```javascript +// مرکل پروف ان اندراجات کی فہرست کی قدر پر مشتمل ہوتا ہے جن کے ساتھ +// ہیش کرنا ہے۔ چونکہ ہم ایک سیمیٹریکل ہیش فنکشن استعمال کرتے ہیں، ہمیں +// پروف کی تصدیق کے لیے آئٹم کے مقام کی ضرورت نہیں ہے، صرف اسے بنانے کے لیے +const getMerkleProof = (inputArray, n) => { +    var result = [], currentLayer = [...inputArray], currentN = n + +    // جب تک ہم سب سے اوپر نہ پہنچ جائیں +    while (currentLayer.length > 1) { +        // کوئی طاق لمبائی کی لیئرز نہیں +        if (currentLayer.length % 2) +            currentLayer.push(empty) + +        result.push(currentN % 2 +               // اگر currentN طاق ہے، تو اس سے پہلے کی قدر کے ساتھ پروف میں شامل کریں +            ? currentLayer[currentN-1] +               // اگر یہ جفت ہے، تو اس کے بعد کی قدر شامل کریں +            : currentLayer[currentN+1]) + +``` + +ہم `(v[0],v[1])`، `(v[2],v[3])`، وغیرہ کو ہیش کرتے ہیں۔ لہذا جفت قدروں کے لیے ہمیں اگلی قدر کی ضرورت ہے، اور طاق قدروں کے لیے پچھلی قدر کی۔ + +```javascript +        // اگلی لیئر پر جائیں +        currentN = Math.floor(currentN/2) +        currentLayer = oneLevelUp(currentLayer) +    }   // جبکہ currentLayer.length > 1 + +    return result +}   // getMerkleProof +``` + +### آن چین کوڈ {#onchain-code} + +آخر میں ہمارے پاس وہ کوڈ ہے جو پروف کی جانچ کرتا ہے۔ آن چین کوڈ [Solidity](https://docs.soliditylang.org/en/v0.8.11/) میں لکھا گیا ہے۔ یہاں آپٹیمائزیشن بہت زیادہ اہم ہے کیونکہ گیس نسبتاً مہنگی ہے۔ + +```solidity +//SPDX-License-Identifier: Public Domain +pragma solidity ^0.8.0; + +import "hardhat/console.sol"; +``` + +میں نے یہ [Hardhat ڈیولپمنٹ انوائرمنٹ](https://hardhat.org/) کا استعمال کرتے ہوئے لکھا ہے، جو ہمیں ڈیولپمنٹ کے دوران [Solidity سے کنسول آؤٹ پٹ](https://hardhat.org/docs/cookbook/debug-logs) حاصل کرنے کی اجازت دیتا ہے۔ + +```solidity + +contract MerkleProof { +    uint merkleRoot; + +    function getRoot() public view returns (uint) { +      return merkleRoot; +    } + +    // انتہائی غیر محفوظ، پروڈکشن کوڈ میں اس فنکشن +    // تک رسائی کو سختی سے محدود کیا جانا چاہیے، شاید کسی +    // مالک تک +    function setRoot(uint _merkleRoot) external { +      merkleRoot = _merkleRoot; +    }   // setRoot +``` + +مرکل روٹ کے لیے سیٹ اور گیٹ فنکشنز۔ پروڈکشن سسٹم میں ہر کسی کو مرکل روٹ کو اپ ڈیٹ کرنے کی اجازت دینا ایک _انتہائی برا خیال_ ہے۔ میں یہاں نمونہ کوڈ کی سادگی کی خاطر ایسا کرتا ہوں۔ **اسے ایسے سسٹم پر نہ کریں جہاں ڈیٹا کی سالمیت واقعی اہمیت رکھتی ہو**۔ + +```solidity +    function hash(uint _a) internal pure returns(uint) { +      return uint(keccak256(abi.encode(_a))); +    } + +    function pairHash(uint _a, uint _b) internal pure returns(uint) { +      return hash(hash(_a) ^ hash(_b)); +    } +``` + +یہ فنکشن ایک جوڑے کا ہیش بناتا ہے۔ یہ `hash` اور `pairHash` کے لیے JavaScript کوڈ کا صرف Solidity ترجمہ ہے۔ + +**نوٹ:** یہ پڑھنے کی اہلیت کے لیے آپٹیمائزیشن کا ایک اور معاملہ ہے۔ [فنکشن کی تعریف](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm) کی بنیاد پر، ڈیٹا کو [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) قدر کے طور پر اسٹور کرنا اور تبادلوں سے بچنا ممکن ہو سکتا ہے۔ + +```solidity +    // مرکل پروف کی تصدیق کریں +    function verifyProof(uint _value, uint[] calldata _proof) +        public view returns (bool) { +      uint temp = _value; +      uint i; + +      for(i=0; i<_proof.length; i++) { +        temp = pairHash(temp, _proof[i]); +      } + +      return temp == merkleRoot; +    } + +}  // MarkleProof +``` + +ریاضیاتی اشارے میں مرکل پروف کی تصدیق اس طرح نظر آتی ہے: `H(proof_n, H(proof_n-1, H(proof_n-2, ...` H(proof_1, H(proof_0, value))...)))`۔ یہ کوڈ اسے نافذ کرتا ہے۔ + +## مرکل پروفس اور رول اپس آپس میں نہیں ملتے {#merkle-proofs-and-rollups} + +مرکل پروفس [رول اپس](/developers/docs/scaling/#rollups) کے ساتھ اچھی طرح کام نہیں کرتے ہیں۔ اس کی وجہ یہ ہے کہ رول اپس تمام ٹرانزیکشن ڈیٹا L1 پر لکھتے ہیں، لیکن L2 پر پروسیس کرتے ہیں۔ ایک ٹرانزیکشن کے ساتھ مرکل پروف بھیجنے کی لاگت اوسطاً 638 گیس فی لیئر ہے (فی الحال کال ڈیٹا میں ایک بائٹ کی لاگت 16 گیس ہے اگر یہ صفر نہیں ہے، اور 4 ہے اگر یہ صفر ہے)۔ اگر ہمارے پاس 1024 الفاظ کا ڈیٹا ہے، تو مرکل پروف کے لیے دس لیئرز، یا کل 6380 گیس کی ضرورت ہوتی ہے۔ + +مثال کے طور پر [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m) کو دیکھیں، L1 گیس لکھنے پر تقریباً 100 gwei اور L2 گیس پر 0.001 gwei لاگت آتی ہے (یہ عام قیمت ہے، یہ بھیڑ کے ساتھ بڑھ سکتی ہے)۔ لہذا ایک L1 گیس کی لاگت پر ہم L2 پروسیسنگ پر ایک لاکھ گیس خرچ کر سکتے ہیں۔ یہ فرض کرتے ہوئے کہ ہم اسٹوریج کو اوور رائٹ نہیں کرتے ہیں، اس کا مطلب ہے کہ ہم ایک L1 گیس کی قیمت پر L2 پر اسٹوریج میں تقریباً پانچ الفاظ لکھ سکتے ہیں۔ ایک مرکل پروف کے لیے ہم پورے 1024 الفاظ اسٹوریج میں لکھ سکتے ہیں (یہ فرض کرتے ہوئے کہ انہیں شروع میں آن چین کیلکولیٹ کیا جا سکتا ہے، بجائے اس کے کہ ٹرانزیکشن میں فراہم کیا جائے) اور پھر بھی زیادہ تر گیس بچی رہے گی۔ + +## نتیجہ {#conclusion} + +حقیقی زندگی میں آپ شاید کبھی بھی خود سے مرکل ٹریز کو نافذ نہیں کریں گے۔ ایسی معروف اور آڈٹ شدہ لائبریریاں ہیں جنہیں آپ استعمال کر سکتے ہیں اور عام طور پر یہ بہتر ہے کہ آپ خود کرپٹوگرافک پرائمیٹیوز کو نافذ نہ کریں۔ لیکن مجھے امید ہے کہ اب آپ مرکل پروفس کو بہتر طور پر سمجھتے ہیں اور یہ فیصلہ کر سکتے ہیں کہ انہیں کب استعمال کرنا چاہیے۔ + +نوٹ کریں کہ جب مرکل پروفس _سالمیت_ کو محفوظ رکھتے ہیں، وہ _دستیابی_ کو محفوظ نہیں رکھتے ہیں۔ یہ جاننا کہ کوئی اور آپ کے اثاثے نہیں لے سکتا، یہ چھوٹی سی تسلی ہے اگر ڈیٹا اسٹوریج رسائی کو مسترد کرنے کا فیصلہ کرتا ہے اور آپ ان تک رسائی کے لیے مرکل ٹری بھی نہیں بنا سکتے ہیں۔ لہذا مرکل ٹریز کو کسی قسم کے وکندریقرت اسٹوریج، جیسے IPFS کے ساتھ بہترین طریقے سے استعمال کیا جاتا ہے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/ur/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md new file mode 100644 index 00000000000..6f615f5395e --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md @@ -0,0 +1,151 @@ +--- +title: "InfluxDB اور Grafana کے ساتھ Geth کی نگرانی" +description: "کارکردگی کو ٹریک کرنے اور مسائل کی شناخت کرنے کے لیے InfluxDB اور Grafana کا استعمال کرتے ہوئے اپنے Geth نوڈ کے لیے نگرانی سیٹ اپ کریں۔" +author: "Mario Havel" +tags: [ "کلائنٹس", "نوڈز" ] +skill: intermediate +lang: ur-in +published: 2021-01-13 +--- + +یہ ٹیوٹوریل آپ کو اپنے Geth نوڈ کے لیے نگرانی سیٹ اپ کرنے میں مدد کرے گا تاکہ آپ اس کی کارکردگی کو بہتر طور پر سمجھ سکیں اور ممکنہ مسائل کی شناخت کر سکیں۔ + +## شرائط {#prerequisites} + +- آپ کو پہلے سے ہی Geth کا ایک انسٹنس چلا رہے ہونا چاہئے۔ +- زیادہ تر اقدامات اور مثالیں linux ماحول کے لیے ہیں، بنیادی ٹرمینل کا علم مددگار ثابت ہوگا۔ +- Geth کے میٹرکس کے سوٹ کا یہ ویڈیو جائزہ دیکھیں: [Péter Szilágyi کے ذریعہ ایک Ethereum انفراسٹرکچر کی نگرانی](https://www.youtube.com/watch?v=cOBab8IJMYI)۔ + +## نگرانی کا اسٹیک {#monitoring-stack} + +ایک Ethereum کلائنٹ بہت سارا ڈیٹا اکٹھا کرتا ہے جسے ایک کرونولوجیکل ڈیٹا بیس کی شکل میں پڑھا جا سکتا ہے۔ نگرانی کو آسان بنانے کے لیے، آپ اسے ڈیٹا ویژولائزیشن سافٹ ویئر میں فیڈ کر سکتے ہیں۔ متعدد اختیارات دستیاب ہیں: + +- [Prometheus](https://prometheus.io/) (pull model) +- [InfluxDB](https://www.influxdata.com/get-influxdb/) (push model) +- [Telegraf](https://www.influxdata.com/get-influxdb/) +- [Grafana](https://www.grafana.com/) +- [Datadog](https://www.datadoghq.com/) +- [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/) + +[Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter) بھی ہے، جو InfluxDB اور Grafana کے ساتھ پہلے سے کنفیگر کیا گیا ایک آپشن ہے۔ + +اس ٹیوٹوریل میں، ہم آپ کے Geth کلائنٹ کو ایک ڈیٹا بیس بنانے کے لیے InfluxDB میں ڈیٹا پش کرنے کے لیے، اور ڈیٹا کا گراف ویژولائزیشن بنانے کے لیے Grafana کے لیے سیٹ اپ کریں گے۔ اسے دستی طور پر کرنے سے آپ کو اس عمل کو بہتر طور پر سمجھنے، اس میں تبدیلی کرنے، اور مختلف ماحول میں اسے ڈیپلائے کرنے میں مدد ملے گی۔ + +## InfluxDB سیٹ اپ کرنا {#setting-up-influxdb} + +سب سے پہلے، آئیے InfluxDB کو ڈاؤن لوڈ اور انسٹال کریں۔ ڈاؤن لوڈ کے مختلف اختیارات [Influxdata ریلیز پیج](https://portal.influxdata.com/downloads/) پر مل سکتے ہیں۔ اپنے ماحول کے مطابق ایک کا انتخاب کریں۔ +آپ اسے ایک [ریپوزٹری](https://repos.influxdata.com/) سے بھی انسٹال کر سکتے ہیں۔ مثال کے طور پر Debian پر مبنی ڈسٹری بیوشن میں: + +``` +curl -tlsv1.3 --proto =https -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add +source /etc/lsb-release +echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list +sudo apt update +sudo apt install influxdb -y +sudo systemctl enable influxdb +sudo systemctl start influxdb +sudo apt install influxdb-client +``` + +InfluxDB کو کامیابی سے انسٹال کرنے کے بعد، یقینی بنائیں کہ یہ بیک گراؤنڈ میں چل رہا ہے۔ ڈیفالٹ کے طور پر، یہ `localhost:8086` پر قابل رسائی ہے۔ +`influx` کلائنٹ استعمال کرنے سے پہلے، آپ کو ایڈمن مراعات کے ساتھ ایک نیا صارف بنانا ہوگا۔ یہ صارف اعلیٰ سطح کے انتظام، ڈیٹا بیس اور صارفین بنانے کے لیے کام کرے گا۔ + +``` +curl -XPOST "http://localhost:8086/query" --data-urlencode "q=CREATE USER username WITH PASSWORD 'password' WITH ALL PRIVILEGES" +``` + +اب آپ اس صارف کے ساتھ [InfluxDB شیل](https://docs.influxdata.com/influxdb/v1.8/tools/shell/) میں داخل ہونے کے لیے influx کلائنٹ کا استعمال کر سکتے ہیں۔ + +``` +influx -username 'username' -password 'password' +``` + +اس کے شیل میں InfluxDB کے ساتھ براہ راست بات چیت کرتے ہوئے، آپ geth میٹرکس کے لیے ڈیٹا بیس اور صارف بنا سکتے ہیں۔ + +``` +create database geth +create user geth with password choosepassword +``` + +تخلیق شدہ اندراجات کی تصدیق کریں: + +``` +show databases +show users +``` + +InfluxDB شیل چھوڑ دیں۔ + +``` +exit +``` + +InfluxDB چل رہا ہے اور Geth سے میٹرکس کو اسٹور کرنے کے لیے کنفیگر کیا گیا ہے۔ + +## Geth کی تیاری {#preparing-geth} + +ڈیٹا بیس سیٹ اپ کرنے کے بعد، ہمیں Geth میں میٹرکس کلیکشن کو فعال کرنے کی ضرورت ہے۔ `geth --help` میں `METRICS AND STATS OPTIONS` پر دھیان دیں۔ وہاں متعدد اختیارات مل سکتے ہیں، اس معاملے میں ہم چاہتے ہیں کہ Geth، InfluxDB میں ڈیٹا پش کرے۔ +بنیادی سیٹ اپ اس اینڈ پوائنٹ کی وضاحت کرتا ہے جہاں InfluxDB قابل رسائی ہے اور ڈیٹا بیس کے لیے توثیق۔ + +``` +geth --metrics --metrics.influxdb --metrics.influxdb.endpoint "http://0.0.0.0:8086" --metrics.influxdb.username "geth" --metrics.influxdb.password "chosenpassword" +``` + +یہ فلیگس کلائنٹ کو شروع کرنے والے کمانڈ میں شامل کیے جا سکتے ہیں یا کنفیگریشن فائل میں محفوظ کیے جا سکتے ہیں۔ + +آپ تصدیق کر سکتے ہیں کہ Geth کامیابی سے ڈیٹا پش کر رہا ہے، مثال کے طور پر ڈیٹا بیس میں میٹرکس کی فہرست بنا کر۔ InfluxDB شیل میں: + +``` +use geth +show measurements +``` + +## Grafana سیٹ اپ کرنا {#setting-up-grafana} + +اگلا مرحلہ Grafana کو انسٹال کرنا ہے جو ڈیٹا کو گرافیکل طور پر بیان کرے گا۔ Grafana دستاویزات میں اپنے ماحول کے لیے انسٹالیشن کے عمل پر عمل کریں۔ اگر آپ دوسری صورت میں نہیں چاہتے ہیں تو OSS ورژن انسٹال کرنا یقینی بنائیں۔ +ریپوزٹری کا استعمال کرتے ہوئے Debian ڈسٹری بیوشنز کے لیے انسٹالیشن کے مثال کے اقدامات: + +``` +curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add - +echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list +sudo apt update +sudo apt install grafana +sudo systemctl enable grafana-server +sudo systemctl start grafana-server +``` + +جب آپ Grafana چلا رہے ہوں، تو اسے `localhost:3000` پر قابل رسائی ہونا چاہئے۔ +اس پاتھ تک رسائی کے لیے اپنا پسندیدہ براؤزر استعمال کریں، پھر ڈیفالٹ اسناد (صارف: `admin` اور پاس ورڈ: `admin`) کے ساتھ لاگ ان کریں۔ جب کہا جائے تو ڈیفالٹ پاس ورڈ تبدیل کریں اور محفوظ کریں۔ + +![](./grafana1.png) + +آپ کو Grafana کے ہوم پیج پر ری ڈائریکٹ کر دیا جائے گا۔ سب سے پہلے، اپنا سورس ڈیٹا سیٹ اپ کریں۔ بائیں بار میں کنفیگریشن آئیکن پر کلک کریں اور "Data sources" منتخب کریں۔ + +![](./grafana2.png) + +ابھی تک کوئی ڈیٹا سورس نہیں بنایا گیا ہے، ایک کی وضاحت کرنے کے لیے "Add data source" پر کلک کریں۔ + +![](./grafana3.png) + +اس سیٹ اپ کے لیے، "InfluxDB" منتخب کریں اور آگے بڑھیں۔ + +![](./grafana4.png) + +اگر آپ ایک ہی مشین پر ٹولز چلا رہے ہیں تو ڈیٹا سورس کنفیگریشن کافی سیدھا ہے۔ آپ کو ڈیٹا بیس تک رسائی کے لیے InfluxDB ایڈریس اور تفصیلات سیٹ کرنے کی ضرورت ہے۔ نیچے دی گئی تصویر دیکھیں۔ + +![](./grafana5.png) + +اگر سب کچھ مکمل ہے اور InfluxDB قابل رسائی ہے، تو "Save and test" پر کلک کریں اور تصدیق کے پاپ اپ ہونے کا انتظار کریں۔ + +![](./grafana6.png) + +Grafana اب InfluxDB سے ڈیٹا پڑھنے کے لیے سیٹ اپ ہے۔ اب آپ کو ایک ڈیش بورڈ بنانے کی ضرورت ہے جو اس کی تشریح اور اسے ظاہر کرے گا۔ ڈیش بورڈز کی خصوصیات JSON فائلوں میں انکوڈ کی جاتی ہیں جنہیں کوئی بھی بنا سکتا ہے اور آسانی سے امپورٹ کیا جا سکتا ہے۔ بائیں بار پر، "Create and Import" پر کلک کریں۔ + +![](./grafana7.png) + +Geth مانیٹرنگ ڈیش بورڈ کے لیے، [اس ڈیش بورڈ](https://grafana.com/grafana/dashboards/13877/) کی ID کاپی کریں اور اسے Grafana میں "Import page" میں پیسٹ کریں۔ ڈیش بورڈ کو محفوظ کرنے کے بعد، یہ اس طرح نظر آنا چاہئے: + +![](./grafana8.png) + +آپ اپنے ڈیش بورڈز میں ترمیم کر سکتے ہیں۔ ہر پینل کو ایڈٹ کیا، منتقل کیا، ہٹایا یا شامل کیا جا سکتا ہے۔ آپ اپنی کنفیگریشنز کو تبدیل کر سکتے ہیں۔ یہ آپ پر منحصر ہے! ڈیش بورڈز کیسے کام کرتے ہیں اس کے بارے میں مزید جاننے کے لیے، [Grafana کی دستاویزات](https://grafana.com/docs/grafana/latest/dashboards/) سے رجوع کریں۔ +آپ کو [Alerting](https://grafana.com/docs/grafana/latest/alerting/) میں بھی دلچسپی ہو سکتی ہے۔ یہ آپ کو اس وقت کے لیے الرٹ نوٹیفکیشنز سیٹ اپ کرنے دیتا ہے جب میٹرکس کچھ خاص ویلیوز تک پہنچ جاتے ہیں۔ مختلف کمیونیکیشن چینلز معاون ہیں۔ diff --git a/public/content/translations/ur/developers/tutorials/nft-minter/index.md b/public/content/translations/ur/developers/tutorials/nft-minter/index.md new file mode 100644 index 00000000000..0e6c46f3fc8 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/nft-minter/index.md @@ -0,0 +1,874 @@ +--- +title: "NFT منٹر ٹیوٹوریل" +description: "اس ٹیوٹوریل میں، آپ ایک NFT منٹر بنائیں گے اور MetaMask اور Web3 ٹولز کا استعمال کرتے ہوئے اپنے اسمارٹ کنٹریکٹ کو React فرنٹ اینڈ سے جوڑ کر ایک فل اسٹیک dApp بنانا سیکھیں گے۔" +author: "smudgil" +tags: + [ + "solidity", + "NFT", + "alchemy", + "اسمارٹ معاہدات", + "فرنٹ اینڈ", + "Pinata" + ] +skill: intermediate +lang: ur-in +published: 2021-10-06 +--- + +Web2 پس منظر سے آنے والے ڈیولپرز کے لیے سب سے بڑے چیلنجوں میں سے ایک یہ ہے کہ وہ اپنے اسمارٹ کنٹریکٹ کو فرنٹ اینڈ پروجیکٹ سے کیسے جوڑیں اور اس کے ساتھ تعامل کریں۔ + +ایک NFT منٹر بنا کر — ایک سادہ UI جہاں آپ اپنے ڈیجیٹل اثاثے کا لنک، ایک عنوان، اور ایک تفصیل درج کر سکتے ہیں — آپ سیکھیں گے کہ کیسے: + +- اپنے فرنٹ اینڈ پروجیکٹ کے ذریعے MetaMask سے جڑیں +- اپنے فرنٹ اینڈ سے اسمارٹ کنٹریکٹ طریقوں کو کال کریں +- MetaMask کا استعمال کرتے ہوئے ٹرانزیکشنز پر دستخط کریں + +اس ٹیوٹوریل میں، ہم اپنے فرنٹ اینڈ فریم ورک کے طور پر [React](https://react.dev/) کا استعمال کریں گے۔ چونکہ یہ ٹیوٹوریل بنیادی طور پر Web3 ڈیولپمنٹ پر مرکوز ہے، ہم React کے بنیادی اصولوں کو سمجھنے میں زیادہ وقت نہیں گزاریں گے۔ اس کے بجائے، ہم اپنے پروجیکٹ میں فعالیت (functionality) لانے پر توجہ مرکوز کریں گے۔ + +ایک شرط کے طور پر، آپ کو React کی ابتدائی سطح کی سمجھ ہونی چاہیے— یہ جاننا کہ کمپونینٹس، پروپس، useState/useEffect، اور بنیادی فنکشن کالنگ کیسے کام کرتی ہے۔ اگر آپ نے پہلے ان میں سے کسی بھی اصطلاح کے بارے میں نہیں سنا ہے، تو آپ یہ [Intro to React tutorial](https://react.dev/learn/tutorial-tic-tac-toe) دیکھنا چاہیں گے۔ بصری طور پر سیکھنے والوں کے لیے، ہم Net Ninja کی طرف سے اس بہترین [Full Modern React Tutorial](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d) ویڈیو سیریز کی پرزور سفارش کرتے ہیں۔ + +اور اگر آپ نے پہلے سے ایسا نہیں کیا ہے، تو آپ کو اس ٹیوٹوریل کو مکمل کرنے کے ساتھ ساتھ بلاک چین پر کچھ بھی بنانے کے لیے یقینی طور پر ایک Alchemy اکاؤنٹ کی ضرورت ہوگی۔ [یہاں](https://alchemy.com/) ایک مفت اکاؤنٹ کے لیے سائن اپ کریں۔ + +مزید تاخیر کے بغیر، آئیے شروع کریں! + +## NFTs بنانا 101 {#making-nfts-101} + +کسی بھی کوڈ کو دیکھنے سے پہلے، یہ سمجھنا ضروری ہے کہ NFT بنانا کیسے کام کرتا ہے۔ اس میں دو مراحل شامل ہیں: + +### Ethereum بلاک چین پر ایک NFT اسمارٹ کنٹریکٹ شائع کریں {#publish-nft} + +دو NFT اسمارٹ کنٹریکٹ معیارات کے درمیان سب سے بڑا فرق یہ ہے کہ ERC-1155 ایک ملٹی ٹوکن معیار ہے اور اس میں بیچ کی فعالیت شامل ہے، جبکہ ERC-721 ایک سنگل ٹوکن معیار ہے اور اس لیے ایک وقت میں صرف ایک ٹوکن کی منتقلی کی حمایت کرتا ہے۔ + +### منٹنگ فنکشن کو کال کریں {#minting-function} + +عام طور پر، اس منٹنگ فنکشن کے لیے آپ کو پیرامیٹرز کے طور پر دو متغیرات (variables) پاس کرنے کی ضرورت ہوتی ہے، پہلا `recipient`، جو اس پتے کی وضاحت کرتا ہے جو آپ کا تازہ منٹ کیا ہوا NFT وصول کرے گا، اور دوسرا NFT کا `tokenURI`، ایک اسٹرنگ جو NFT کے میٹا ڈیٹا کو بیان کرنے والے JSON دستاویز میں حل ہوتا ہے۔ + +ایک NFT کا میٹا ڈیٹا ہی دراصل اسے زندگی بخشتا ہے، جو اسے نام، تفصیل، تصویر (یا مختلف ڈیجیٹل اثاثہ)، اور دیگر صفات جیسی خصوصیات رکھنے کی اجازت دیتا ہے۔ یہاں [tokenURI کی ایک مثال](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2) ہے، جس میں ایک NFT کا میٹا ڈیٹا ہوتا ہے۔ + +اس ٹیوٹوریل میں، ہم حصہ 2 پر توجہ مرکوز کرنے جا رہے ہیں، یعنی ہمارے React UI کا استعمال کرتے ہوئے ایک موجودہ NFT کے اسمارٹ کنٹریکٹ منٹنگ فنکشن کو کال کرنا۔ + +اس ٹیوٹوریل میں ہم جس ERC-721 NFT اسمارٹ کنٹریکٹ کو کال کریں گے اس کا [لنک یہاں ہے](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE)۔ اگر آپ یہ جاننا چاہتے ہیں کہ ہم نے اسے کیسے بنایا، تو ہم پرزور سفارش کرتے ہیں کہ آپ ہمارا دوسرا ٹیوٹوریل، ["How to Create an NFT"](https://www.alchemy.com/docs/how-to-create-an-nft) دیکھیں۔ + +بہت خوب، اب جب کہ ہم سمجھ گئے ہیں کہ NFT بنانا کیسے کام کرتا ہے، آئیے اپنی اسٹارٹر فائلیں کلون کریں! + +## اسٹارٹر فائلیں کلون کریں {#clone-the-starter-files} + +سب سے پہلے، اس پروجیکٹ کے لیے اسٹارٹر فائلیں حاصل کرنے کے لیے [nft-minter-tutorial GitHub repository](https://github.com/alchemyplatform/nft-minter-tutorial) پر جائیں۔ اس ریپوزٹری کو اپنے مقامی ماحول میں کلون کریں۔ + +جب آپ اس کلون کی ہوئی `nft-minter-tutorial` ریپوزٹری کو کھولیں گے، تو آپ دیکھیں گے کہ اس میں دو فولڈرز ہیں: `minter-starter-files` اور `nft-minter`۔ + +- `minter-starter-files` میں اس پروجیکٹ کے لیے اسٹارٹر فائلیں (بنیادی طور پر React UI) ہیں۔ اس ٹیوٹوریل میں، **ہم اس ڈائریکٹری میں کام کریں گے**، جہاں آپ سیکھیں گے کہ اس UI کو اپنے Ethereum والیٹ اور ایک NFT اسمارٹ کنٹریکٹ سے جوڑ کر اسے کیسے فعال بنایا جائے۔ +- `nft-minter` میں پورا مکمل ٹیوٹوریل ہے اور اگر آپ کہیں پھنس جاتے ہیں تو یہ آپ کے لیے ایک **حوالے** کے طور پر موجود ہے۔ + +اس کے بعد، اپنے کوڈ ایڈیٹر میں `minter-starter-files` کی اپنی کاپی کھولیں، اور پھر اپنے `src` فولڈر میں جائیں۔ + +ہمارا لکھا ہوا سارا کوڈ `src` فولڈر کے تحت رہے گا۔ ہم `Minter.js` کمپونینٹ میں ترمیم کریں گے اور اپنے پروجیکٹ کو Web3 کی فعالیت دینے کے لیے اضافی javascript فائلیں لکھیں گے۔ + +## مرحلہ 2: ہماری اسٹارٹر فائلیں دیکھیں {#step-2-check-out-our-starter-files} + +کوڈنگ شروع کرنے سے پہلے، یہ دیکھنا ضروری ہے کہ اسٹارٹر فائلوں میں ہمارے لیے پہلے سے کیا فراہم کیا گیا ہے۔ + +### اپنا react پروجیکٹ چلائیں {#get-your-react-project-running} + +آئیے اپنے براؤزر میں React پروجیکٹ چلا کر شروع کریں۔ React کی خوبصورتی یہ ہے کہ ایک بار جب ہمارا پروجیکٹ ہمارے براؤزر میں چل رہا ہو، تو ہمارے ذریعے محفوظ کی گئی کوئی بھی تبدیلی ہمارے براؤزر میں لائیو اپ ڈیٹ ہو جائے گی۔ + +پروجیکٹ کو چلانے کے لیے، `minter-starter-files` فولڈر کی روٹ ڈائرکٹری میں جائیں، اور پروجیکٹ کی ڈیپینڈینسیز (dependencies) کو انسٹال کرنے کے لیے اپنے ٹرمینل میں `npm install` چلائیں: + +```bash +cd minter-starter-files +npm install +``` + +ان کے انسٹال ہونے کے بعد، اپنے ٹرمینل میں `npm start` چلائیں: + +```bash +npm start +``` + +ایسا کرنے سے آپ کے براؤزر میں http://localhost:3000/ کھل جائے گا، جہاں آپ کو ہمارے پروجیکٹ کا فرنٹ اینڈ نظر آئے گا۔ اس میں 3 فیلڈز ہونے چاہئیں: آپ کے NFT کے اثاثے کا لنک داخل کرنے کی جگہ، اپنے NFT کا نام درج کرنے کی جگہ، اور تفصیل فراہم کرنے کی جگہ۔ + +اگر آپ "Connect Wallet" یا "Mint NFT" بٹنوں پر کلک کرنے کی کوشش کرتے ہیں، تو آپ دیکھیں گے کہ وہ کام نہیں کرتے—اس کی وجہ یہ ہے کہ ہمیں ابھی بھی ان کی فعالیت کو پروگرام کرنے کی ضرورت ہے! :\) + +### Minter.js کمپونینٹ {#minter-js} + +**نوٹ:** یقینی بنائیں کہ آپ `minter-starter-files` فولڈر میں ہیں نہ کہ `nft-minter` فولڈر میں! + +آئیے اپنے ایڈیٹر میں `src` فولڈر میں واپس جائیں اور `Minter.js` فائل کھولیں۔ یہ بہت ضروری ہے کہ ہم اس فائل میں ہر چیز کو سمجھیں، کیونکہ یہ بنیادی React کمپونینٹ ہے جس پر ہم کام کریں گے۔ + +اس فائل کے اوپری حصے میں، ہمارے پاس ہمارے اسٹیٹ متغیرات (state variables) ہیں جنہیں ہم مخصوص ایونٹس کے بعد اپ ڈیٹ کریں گے۔ + +```javascript +//اسٹیٹ متغیرات +const [walletAddress, setWallet] = useState("") +const [status, setStatus] = useState("") +const [name, setName] = useState("") +const [description, setDescription] = useState("") +const [url, setURL] = useState("") +``` + +React اسٹیٹ متغیرات (state variables) یا اسٹیٹ ہکس (state hooks) کے بارے میں کبھی نہیں سنا؟ [ان](https://legacy.reactjs.org/docs/hooks-state.html) دستاویزات کو دیکھیں۔ + +یہاں ہر متغیر کی نمائندگی دی گئی ہے: + +- `walletAddress` - ایک اسٹرنگ جو صارف کے والیٹ کا پتہ محفوظ کرتا ہے +- `status` - ایک اسٹرنگ جس میں UI کے نیچے دکھانے کے لیے ایک پیغام ہوتا ہے +- `name` - ایک اسٹرنگ جو NFT کا نام محفوظ کرتا ہے +- `description` - ایک اسٹرنگ جو NFT کی تفصیل محفوظ کرتا ہے +- `url` - ایک اسٹرنگ جو NFT کے ڈیجیٹل اثاثے کا لنک ہے + +اسٹیٹ متغیرات کے بعد، آپ کو تین غیر نافذ شدہ فنکشنز نظر آئیں گے: `useEffect`، `connectWalletPressed`، اور `onMintPressed`۔ آپ دیکھیں گے کہ یہ تمام فنکشنز `async` ہیں، اس کی وجہ یہ ہے کہ ہم ان میں غیر مطابقت پذیر (asynchronous) API کالز کریں گے! ان کے نام ان کی فعالیتوں کے ہم نام ہیں: + +```javascript +useEffect(async () => { + //TODO: نافذ کریں +}, []) + +const connectWalletPressed = async () => { + //TODO: نافذ کریں +} + +const onMintPressed = async () => { + //TODO: نافذ کریں +} +``` + +- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) - یہ ایک React ہک ہے جسے آپ کے کمپونینٹ کے رینڈر ہونے کے بعد کال کیا جاتا ہے۔ چونکہ اس میں ایک خالی اری `[]` پروپ پاس کیا گیا ہے (لائن 3 دیکھیں)، اسے صرف کمپونینٹ کے _پہلے_ رینڈر پر کال کیا جائے گا۔ یہاں ہم اپنے والیٹ لسنر اور ایک اور والیٹ فنکشن کو کال کریں گے تاکہ ہمارے UI کو اپ ڈیٹ کیا جا سکے تاکہ یہ ظاہر ہو سکے کہ آیا کوئی والیٹ پہلے سے جڑا ہوا ہے۔ +- `connectWalletPressed` - اس فنکشن کو صارف کے MetaMask والیٹ کو ہمارے dApp سے جوڑنے کے لیے کال کیا جائے گا۔ +- `onMintPressed` - اس فنکشن کو صارف کے NFT کو منٹ کرنے کے لیے کال کیا جائے گا۔ + +اس فائل کے آخر کے قریب، ہمارے پاس ہمارے کمپونینٹ کا UI ہے۔ اگر آپ اس کوڈ کو غور سے اسکین کرتے ہیں، تو آپ دیکھیں گے کہ جب ان کے متعلقہ ٹیکسٹ فیلڈز میں ان پٹ تبدیل ہوتا ہے تو ہم اپنے `url`، `name`، اور `description` اسٹیٹ متغیرات کو اپ ڈیٹ کرتے ہیں۔ + +آپ یہ بھی دیکھیں گے کہ جب بالترتیب `mintButton` اور `walletButton` IDs والے بٹنوں پر کلک کیا جاتا ہے تو `connectWalletPressed` اور `onMintPressed` کو کال کیا جاتا ہے۔ + +```javascript +//ہمارے کمپونینٹ کا UI +return ( +
+ + +

+

🧙‍♂️ Alchemy NFT منٹر

+

+ بس اپنے اثاثے کا لنک، نام، اور تفصیل شامل کریں، پھر "Mint" دبائیں۔ +

+
+

🖼 اثاثہ کا لنک:

+ setURL(event.target.value)} + /> +

🤔 نام:

+ setName(event.target.value)} + /> +

✍️ تفصیل:

+ setDescription(event.target.value)} + /> +
+ +

{status}

+
+) +``` + +آخر میں، آئیے اس بات پر غور کریں کہ یہ Minter کمپونینٹ کہاں شامل کیا گیا ہے۔ + +اگر آپ `App.js` فائل پر جاتے ہیں، جو React کا مرکزی کمپونینٹ ہے جو دیگر تمام کمپونینٹس کے لیے کنٹینر کے طور پر کام کرتا ہے، تو آپ دیکھیں گے کہ ہمارا Minter کمپونینٹ لائن 7 پر انجیکٹ کیا گیا ہے۔ + +**اس ٹیوٹوریل میں، ہم صرف `Minter.js` فائل میں ترمیم کریں گے اور اپنے `src` فولڈر میں فائلیں شامل کریں گے۔** + +اب جب کہ ہم سمجھ گئے ہیں کہ ہم کس چیز کے ساتھ کام کر رہے ہیں، آئیے اپنا Ethereum والیٹ سیٹ اپ کریں! + +## اپنا Ethereum والیٹ سیٹ اپ کریں {#set-up-your-ethereum-wallet} + +صارفین کو آپ کے اسمارٹ کنٹریکٹ کے ساتھ تعامل کرنے کے قابل ہونے کے لیے، انہیں اپنے Ethereum والیٹ کو آپ کے dApp سے جوڑنے کی ضرورت ہوگی۔ + +### MetaMask ڈاؤن لوڈ کریں {#download-metamask} + +اس ٹیوٹوریل کے لیے، ہم MetaMask استعمال کریں گے، جو براؤزر میں ایک ورچوئل والیٹ ہے جو آپ کے Ethereum اکاؤنٹ ایڈریس کو منظم کرنے کے لیے استعمال ہوتا ہے۔ اگر آپ Ethereum پر ٹرانزیکشنز کے کام کرنے کے بارے میں مزید سمجھنا چاہتے ہیں، تو [یہ صفحہ](/developers/docs/transactions/) دیکھیں۔ + +آپ [یہاں](https://metamask.io/download) مفت میں MetaMask اکاؤنٹ ڈاؤن لوڈ اور بنا سکتے ہیں۔ جب آپ ایک اکاؤنٹ بنا رہے ہوں، یا اگر آپ کے پاس پہلے سے ہی ایک اکاؤنٹ ہے، تو یقینی بنائیں کہ اوپر دائیں جانب "Ropsten Test Network" پر سوئچ کریں (تاکہ ہم اصلی پیسے سے نمٹ نہ رہے ہوں)۔ + +### ایک Faucet سے ether شامل کریں {#add-ether-from-faucet} + +اپنے NFTs کو منٹ کرنے (یا Ethereum بلاک چین پر کسی بھی ٹرانزیکشن پر دستخط کرنے) کے لیے، ہمیں کچھ جعلی Eth کی ضرورت ہوگی۔ Eth حاصل کرنے کے لیے آپ [Ropsten faucet](https://faucet.ropsten.be/) پر جا سکتے ہیں اور اپنا Ropsten اکاؤنٹ کا پتہ درج کر سکتے ہیں، پھر "Send Ropsten Eth" پر کلک کریں۔ اس کے فوراً بعد آپ کو اپنے MetaMask اکاؤنٹ میں Eth نظر آنا چاہیے! + +### اپنا بیلنس چیک کریں {#check-your-balance} + +ہمارا بیلنس موجود ہے یا نہیں اس کی دوبارہ جانچ کرنے کے لیے، آئیے [Alchemy کے کمپوزر ٹول](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) کا استعمال کرتے ہوئے ایک [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) کی درخواست کریں۔ یہ ہمارے والیٹ میں Eth کی رقم واپس کرے گا۔ اپنے MetaMask اکاؤنٹ کا ایڈریس درج کرنے اور "Send Request" پر کلک کرنے کے بعد، آپ کو اس طرح کا جواب نظر آنا چاہیے: + +```text +{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} +``` + +**نوٹ:** یہ نتیجہ wei میں ہے eth میں نہیں۔ Wei کو ایتھر کی سب سے چھوٹی اکائی کے طور پر استعمال کیا جاتا ہے۔ wei سے eth میں تبدیلی یہ ہے: 1 eth = 10¹⁸ wei۔ تو اگر ہم 0xde0b6b3a7640000 کو اعشاریہ میں تبدیل کرتے ہیں تو ہمیں 1\*10¹⁸ ملتا ہے جو 1 eth کے برابر ہے۔ + +اف! ہمارا جعلی پیسہ سب وہیں ہے! + +## MetaMask کو اپنے UI سے جوڑیں {#connect-metamask-to-your-UI} + +اب جب کہ ہمارا MetaMask والیٹ سیٹ اپ ہو گیا ہے، آئیے اپنے dApp کو اس سے جوڑتے ہیں! + +چونکہ ہم [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) پیراڈائم کی پابندی کرنا چاہتے ہیں، ہم ایک الگ فائل بنائیں گے جس میں ہمارے dApp کی منطق، ڈیٹا اور قواعد کو منظم کرنے کے لیے ہمارے فنکشنز ہوں گے، اور پھر ان فنکشنز کو اپنے فرنٹ اینڈ (ہمارے Minter.js کمپونینٹ) میں پاس کریں گے۔ + +### `connectWallet` فنکشن {#connect-wallet-function} + +ایسا کرنے کے لیے، آئیے اپنی `src` ڈائریکٹری میں `utils` نام کا ایک نیا فولڈر بنائیں اور اس کے اندر `interact.js` نام کی ایک فائل شامل کریں، جس میں ہمارے تمام والیٹ اور اسمارٹ کنٹریکٹ کے تعامل کے فنکشنز ہوں گے۔ + +ہماری `interact.js` فائل میں، ہم ایک `connectWallet` فنکشن لکھیں گے، جسے ہم پھر اپنے `Minter.js` کمپونینٹ میں امپورٹ اور کال کریں گے۔ + +اپنی `interact.js` فائل میں، درج ذیل شامل کریں + +```javascript +export const connectWallet = async () => { + if (window.ethereum) { + try { + const addressArray = await window.ethereum.request({ + method: "eth_requestAccounts", + }) + const obj = { + status: "👆🏽 اوپر ٹیکسٹ فیلڈ میں ایک پیغام لکھیں۔", + address: addressArray[0], + } + return obj + } catch (err) { + return { + address: "", + status: "😥 " + err.message, + } + } + } else { + return { + address: "", + status: ( + +

+ {" "} + 🦊 + آپ کو اپنے براؤزر میں MetaMask، ایک ورچوئل Ethereum والیٹ، انسٹال کرنا ہوگا۔ + +

+
+ ), + } + } +} +``` + +آئیے دیکھتے ہیں کہ یہ کوڈ کیا کرتا ہے: + +سب سے پہلے، ہمارا فنکشن چیک کرتا ہے کہ آیا آپ کے براؤزر میں `window.ethereum` فعال ہے یا نہیں۔ + +`window.ethereum` MetaMask اور دیگر والیٹ فراہم کنندگان کے ذریعے انجیکٹ کردہ ایک عالمی API ہے جو ویب سائٹس کو صارفین کے Ethereum اکاؤنٹس کی درخواست کرنے کی اجازت دیتا ہے۔ اگر منظوری مل جاتی ہے، تو یہ ان بلاک چینز سے ڈیٹا پڑھ سکتا ہے جن سے صارف جڑا ہوا ہے، اور صارف کو پیغامات اور ٹرانزیکشنز پر دستخط کرنے کا مشورہ دے سکتا ہے۔ مزید معلومات کے لیے [MetaMask دستاویزات](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) دیکھیں! + +اگر `window.ethereum` موجود _نہیں_ ہے، تو اس کا مطلب ہے کہ MetaMask انسٹال نہیں ہے۔ اس کے نتیجے میں ایک JSON آبجیکٹ واپس کیا جاتا ہے، جہاں واپس کیا گیا `address` ایک خالی اسٹرنگ ہوتا ہے، اور `status` JSX آبجیکٹ یہ بتاتا ہے کہ صارف کو MetaMask انسٹال کرنا ہوگا۔ + +**ہمارے لکھے ہوئے زیادہ تر فنکشنز JSON آبجیکٹ واپس کریں گے جن کا استعمال ہم اپنے اسٹیٹ متغیرات اور UI کو اپ ڈیٹ کرنے کے لیے کر سکتے ہیں۔** + +اب اگر `window.ethereum` موجود _ہے_، تو یہ وہ جگہ ہے جہاں چیزیں دلچسپ ہو جاتی ہیں۔ + +ایک try/catch لوپ کا استعمال کرتے ہوئے، ہم [`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts) کو کال کرکے MetaMask سے جڑنے کی کوشش کریں گے۔ اس فنکشن کو کال کرنے سے براؤزر میں MetaMask کھل جائے گا، جس کے تحت صارف سے اپنے والیٹ کو آپ کے dApp سے جوڑنے کا کہا جائے گا۔ + +- اگر صارف جڑنے کا انتخاب کرتا ہے، تو `method: "eth_requestAccounts"` ایک اری واپس کرے گا جس میں صارف کے تمام اکاؤنٹ پتے ہوں گے جو dApp سے جڑے ہوئے ہیں۔ مجموعی طور پر، ہمارا `connectWallet` فنکشن ایک JSON آبجیکٹ واپس کرے گا جس میں اس اری کا _پہلا_ `address` (لائن 9 دیکھیں) اور ایک `status` پیغام ہوگا جو صارف کو اسمارٹ کنٹریکٹ کے لیے ایک پیغام لکھنے کا کہے گا۔ +- اگر صارف کنکشن کو مسترد کر دیتا ہے، تو JSON آبجیکٹ میں واپس کیے گئے `address` کے لیے ایک خالی اسٹرنگ اور ایک `status` پیغام ہوگا جو یہ ظاہر کرے گا کہ صارف نے کنکشن کو مسترد کر دیا ہے۔ + +### اپنے Minter.js UI کمپونینٹ میں connectWallet فنکشن شامل کریں {#add-connect-wallet} + +اب جب کہ ہم نے یہ `connectWallet` فنکشن لکھ لیا ہے، آئیے اسے اپنے `Minter.js` کمپونینٹ سے جوڑتے ہیں۔ + +سب سے پہلے، ہمیں `Minter.js` فائل کے اوپری حصے میں `import { connectWallet } from "./utils/interact.js";` شامل کرکے اپنے فنکشن کو اپنی `Minter.js` فائل میں امپورٹ کرنا ہوگا۔ آپ کی `Minter.js` کی پہلی 11 لائنیں اب اس طرح نظر آنی چاہئیں: + +```javascript +import { useEffect, useState } from "react"; +import { connectWallet } from "./utils/interact.js"; + +const Minter = (props) => { + + //اسٹیٹ متغیرات + const [walletAddress, setWallet] = useState(""); + const [status, setStatus] = useState(""); + const [name, setName] = useState(""); + const [description, setDescription] = useState(""); + const [url, setURL] = useState(""); +``` + +پھر، اپنے `connectWalletPressed` فنکشن کے اندر، ہم اپنے امپورٹ کردہ `connectWallet` فنکشن کو اس طرح کال کریں گے: + +```javascript +const connectWalletPressed = async () => { + const walletResponse = await connectWallet() + setStatus(walletResponse.status) + setWallet(walletResponse.address) +} +``` + +دیکھیں کہ ہماری زیادہ تر فعالیت `interact.js` فائل سے ہمارے `Minter.js` کمپونینٹ سے کیسے الگ کی گئی ہے؟ یہ اس لیے ہے تاکہ ہم M-V-C پیراڈائم کی تعمیل کریں! + +`connectWalletPressed` میں، ہم صرف اپنے امپورٹ کردہ `connectWallet` فنکشن پر ایک await کال کرتے ہیں، اور اس کے جواب کا استعمال کرتے ہوئے، ہم اپنے `status` اور `walletAddress` متغیرات کو ان کے اسٹیٹ ہکس کے ذریعے اپ ڈیٹ کرتے ہیں۔ + +اب، آئیے دونوں فائلوں `Minter.js` اور `interact.js` کو محفوظ کریں اور اب تک اپنے UI کی جانچ کریں۔ + +اپنے براؤزر کو localhost:3000 پر کھولیں، اور صفحہ کے اوپر دائیں جانب "Connect Wallet" بٹن دبائیں۔ + +اگر آپ نے MetaMask انسٹال کیا ہوا ہے، تو آپ سے اپنے والیٹ کو اپنے dApp سے جوڑنے کا کہا جائے گا۔ جڑنے کی دعوت قبول کریں۔ + +آپ کو دیکھنا چاہیے کہ والیٹ بٹن اب یہ ظاہر کرتا ہے کہ آپ کا پتہ جڑ گیا ہے۔ + +اگلا، صفحہ کو ریفریش کرنے کی کوشش کریں... یہ عجیب ہے۔ ہمارا والیٹ بٹن ہمیں MetaMask سے جڑنے کا کہہ رہا ہے، حالانکہ یہ پہلے سے ہی جڑا ہوا ہے... + +لیکن فکر نہ کریں! ہم اسے `getCurrentWalletConnected` نامی فنکشن کو نافذ کرکے آسانی سے ٹھیک کر سکتے ہیں، جو یہ چیک کرے گا کہ آیا کوئی پتہ پہلے سے ہی ہمارے dApp سے جڑا ہوا ہے اور اسی کے مطابق ہمارے UI کو اپ ڈیٹ کرے گا! + +### getCurrentWalletConnected فنکشن {#get-current-wallet} + +اپنی `interact.js` فائل میں، درج ذیل `getCurrentWalletConnected` فنکشن شامل کریں: + +```javascript +export const getCurrentWalletConnected = async () => { + if (window.ethereum) { + try { + const addressArray = await window.ethereum.request({ + method: "eth_accounts", + }) + if (addressArray.length > 0) { + return { + address: addressArray[0], + status: "👆🏽 اوپر ٹیکسٹ فیلڈ میں ایک پیغام لکھیں۔", + } + } else { + return { + address: "", + status: "🦊 اوپر دائیں بٹن کا استعمال کرتے ہوئے MetaMask سے جڑیں۔", + } + } + } catch (err) { + return { + address: "", + status: "😥 " + err.message, + } + } + } else { + return { + address: "", + status: ( + +

+ {" "} + 🦊 + آپ کو اپنے براؤزر میں MetaMask، ایک ورچوئل Ethereum والیٹ، انسٹال کرنا ہوگا۔ + +

+
+ ), + } + } +} +``` + +یہ کوڈ ہمارے پہلے لکھے گئے `connectWallet` فنکشن سے _بہت_ ملتا جلتا ہے۔ + +بنیادی فرق یہ ہے کہ `eth_requestAccounts` میتھڈ کو کال کرنے کے بجائے، جو صارف کے لیے اپنے والیٹ کو جوڑنے کے لیے MetaMask کھولتا ہے، یہاں ہم `eth_accounts` میتھڈ کو کال کرتے ہیں، جو صرف ایک اری واپس کرتا ہے جس میں فی الحال ہمارے dApp سے جڑے ہوئے MetaMask پتے ہوتے ہیں۔ + +اس فنکشن کو عملی طور پر دیکھنے کے لیے، آئیے اسے اپنے `Minter.js` کمپونینٹ کے `useEffect` فنکشن میں کال کریں۔ + +جیسا کہ ہم نے `connectWallet` کے لیے کیا تھا، ہمیں اس فنکشن کو اپنی `interact.js` فائل سے اپنی `Minter.js` فائل میں اس طرح امپورٹ کرنا ہوگا: + +```javascript +import { useEffect, useState } from "react" +import { + connectWallet, + getCurrentWalletConnected, //یہاں امپورٹ کریں +} from "./utils/interact.js" +``` + +اب، ہم اسے صرف اپنے `useEffect` فنکشن میں کال کرتے ہیں: + +```javascript +useEffect(async () => { + const { address, status } = await getCurrentWalletConnected() + setWallet(address) + setStatus(status) +}, []) +``` + +نوٹ کریں، ہم اپنے `walletAddress` اور `status` اسٹیٹ متغیرات کو اپ ڈیٹ کرنے کے لیے `getCurrentWalletConnected` پر اپنی کال کے جواب کا استعمال کرتے ہیں۔ + +ایک بار جب آپ یہ کوڈ شامل کر لیں، تو اپنے براؤزر ونڈو کو ریفریش کرنے کی کوشش کریں۔ بٹن کو کہنا چاہیے کہ آپ جڑے ہوئے ہیں، اور آپ کے جڑے ہوئے والیٹ کے پتے کا ایک پیش نظارہ دکھانا چاہیے - یہاں تک کہ آپ کے ریفریش کرنے کے بعد بھی! + +### addWalletListener نافذ کریں {#implement-add-wallet-listener} + +ہمارے dApp والیٹ سیٹ اپ کا آخری مرحلہ والیٹ لسنر کو نافذ کرنا ہے تاکہ جب ہمارے والیٹ کی حالت تبدیل ہو تو ہمارا UI اپ ڈیٹ ہو، جیسے جب صارف منقطع ہوتا ہے یا اکاؤنٹس تبدیل کرتا ہے۔ + +اپنی `Minter.js` فائل میں، `addWalletListener` نامی ایک فنکشن شامل کریں جو درج ذیل کی طرح نظر آتا ہے: + +```javascript +function addWalletListener() { + if (window.ethereum) { + window.ethereum.on("accountsChanged", (accounts) => { + if (accounts.length > 0) { + setWallet(accounts[0]) + setStatus("👆🏽 اوپر ٹیکسٹ فیلڈ میں ایک پیغام لکھیں۔") + } else { + setWallet("") + setStatus("🦊 اوپر دائیں بٹن کا استعمال کرتے ہوئے MetaMask سے جڑیں۔") + } + }) + } else { + setStatus( +

+ {" "} + 🦊 + آپ کو اپنے براؤزر میں MetaMask، ایک ورچوئل Ethereum والیٹ، انسٹال کرنا ہوگا۔ + +

+ ) + } +} +``` + +آئیے جلدی سے دیکھتے ہیں کہ یہاں کیا ہو رہا ہے: + +- سب سے پہلے، ہمارا فنکشن چیک کرتا ہے کہ آیا `window.ethereum` فعال ہے (یعنی، MetaMask انسٹال ہے)۔ + - اگر ایسا نہیں ہے، تو ہم صرف اپنے `status` اسٹیٹ متغیر کو ایک JSX اسٹرنگ پر سیٹ کرتے ہیں جو صارف کو MetaMask انسٹال کرنے کا کہتا ہے۔ + - اگر یہ فعال ہے، تو ہم لائن 3 پر لسنر `window.ethereum.on("accountsChanged")` سیٹ اپ کرتے ہیں جو MetaMask والیٹ میں اسٹیٹ تبدیلیوں کو سنتا ہے، جس میں یہ شامل ہے کہ جب صارف dApp سے ایک اضافی اکاؤنٹ جوڑتا ہے، اکاؤنٹس تبدیل کرتا ہے، یا ایک اکاؤنٹ منقطع کرتا ہے۔ اگر کم از کم ایک اکاؤنٹ جڑا ہوا ہے، تو `walletAddress` اسٹیٹ متغیر کو لسنر کے ذریعے واپس کیے گئے `accounts` اری میں پہلے اکاؤنٹ کے طور پر اپ ڈیٹ کیا جاتا ہے۔ ورنہ، `walletAddress` کو ایک خالی اسٹرنگ کے طور پر سیٹ کیا جاتا ہے۔ + +آخر میں، ہمیں اسے اپنے `useEffect` فنکشن میں کال کرنا ہوگا: + +```javascript +useEffect(async () => { + const { address, status } = await getCurrentWalletConnected() + setWallet(address) + setStatus(status) + + addWalletListener() +}, []) +``` + +اور voila! ہم نے اپنی تمام والیٹ کی فعالیت کی پروگرامنگ مکمل کر لی ہے! اب جب کہ ہمارا والیٹ سیٹ اپ ہو گیا ہے، آئیے معلوم کریں کہ اپنا NFT کیسے منٹ کیا جائے! + +## NFT میٹا ڈیٹا 101 {#nft-metadata-101} + +تو یاد ہے اس ٹیوٹوریل کے مرحلہ 0 میں ہم نے جس NFT میٹا ڈیٹا کے بارے میں بات کی تھی — یہ ایک NFT کو زندگی بخشتا ہے، جس سے اسے ڈیجیٹل اثاثہ، نام، تفصیل، اور دیگر صفات جیسی خصوصیات رکھنے کی اجازت ملتی ہے۔ + +ہمیں اس میٹا ڈیٹا کو JSON آبجیکٹ کے طور پر کنفیگر کرنے اور اسے ذخیرہ کرنے کی ضرورت ہوگی، تاکہ ہم اسے اپنے اسمارٹ کنٹریکٹ کے `mintNFT` فنکشن کو کال کرتے وقت `tokenURI` پیرامیٹر کے طور پر پاس کر سکیں۔ + +"Link to Asset"، "Name"، "Description" فیلڈز میں موجود متن ہمارے NFT کے میٹا ڈیٹا کی مختلف خصوصیات پر مشتمل ہوگا۔ ہم اس میٹا ڈیٹا کو JSON آبجیکٹ کے طور پر فارمیٹ کریں گے، لیکن ہمارے پاس کچھ اختیارات ہیں کہ ہم اس JSON آبجیکٹ کو کہاں ذخیرہ کر سکتے ہیں: + +- ہم اسے Ethereum بلاک چین پر ذخیرہ کر سکتے ہیں؛ تاہم، ایسا کرنا بہت مہنگا ہوگا۔ +- ہم اسے ایک مرکزی سرور پر ذخیرہ کر سکتے ہیں، جیسے AWS یا Firebase۔ لیکن یہ ہمارے وکندریقرت کے اصول کو شکست دے گا۔ +- ہم IPFS، ایک وکندریقرت پروٹوکول اور پیئر ٹو پیئر نیٹ ورک کا استعمال کر سکتے ہیں جو ایک تقسیم شدہ فائل سسٹم میں ڈیٹا کو ذخیرہ کرنے اور شیئر کرنے کے لیے ہے۔ چونکہ یہ پروٹوکول وکندریقرت اور مفت ہے، یہ ہمارا بہترین آپشن ہے! + +IPFS پر اپنے میٹا ڈیٹا کو ذخیرہ کرنے کے لیے، ہم [Pinata](https://pinata.cloud/) کا استعمال کریں گے، جو ایک آسان IPFS API اور ٹول کٹ ہے۔ اگلے مرحلے میں، ہم بالکل وضاحت کریں گے کہ یہ کیسے کرنا ہے! + +## اپنے میٹا ڈیٹا کو IPFS پر پن کرنے کے لیے Pinata کا استعمال کریں {#use-pinata-to-pin-your-metadata-to-IPFS} + +اگر آپ کے پاس [Pinata](https://pinata.cloud/) اکاؤنٹ نہیں ہے، تو [یہاں](https://app.pinata.cloud/auth/signup) ایک مفت اکاؤنٹ کے لیے سائن اپ کریں اور اپنے ای میل اور اکاؤنٹ کی تصدیق کے لیے مراحل مکمل کریں۔ + +### اپنی Pinata API کی (key) بنائیں {#create-pinata-api-key} + +[https://pinata.cloud/keys](https://pinata.cloud/keys) صفحہ پر جائیں، پھر سب سے اوپر "New Key" بٹن کو منتخب کریں، ایڈمن ویجیٹ کو فعال کے طور پر سیٹ کریں، اور اپنی کی (key) کو نام دیں۔ + +پھر آپ کو اپنی API کی معلومات کے ساتھ ایک پاپ اپ دکھایا جائے گا۔ اسے کسی محفوظ جگہ پر رکھنا یقینی بنائیں۔ + +اب جب کہ ہماری کی (key) سیٹ اپ ہو گئی ہے، آئیے اسے اپنے پروجیکٹ میں شامل کریں تاکہ ہم اسے استعمال کر سکیں۔ + +### ایک .env فائل بنائیں {#create-a-env} + +ہم اپنی Pinata کی (key) اور سیکرٹ کو ایک انوائرمنٹ فائل میں محفوظ طریقے سے ذخیرہ کر سکتے ہیں۔ آئیے اپنی پروجیکٹ ڈائرکٹری میں [dotenv package](https://www.npmjs.com/package/dotenv) انسٹال کریں۔ + +اپنے ٹرمینل میں ایک نیا ٹیب کھولیں (مقامی ہوسٹ چلانے والے سے الگ) اور یقینی بنائیں کہ آپ `minter-starter-files` فولڈر میں ہیں، پھر اپنے ٹرمینل میں درج ذیل کمانڈ چلائیں: + +```text +npm install dotenv --save +``` + +اس کے بعد، اپنی کمانڈ لائن پر درج ذیل درج کرکے اپنی `minter-starter-files` کی روٹ ڈائرکٹری میں ایک `.env` فائل بنائیں: + +```javascript +vim.env +``` + +یہ آپ کی `.env` فائل کو vim (ایک ٹیکسٹ ایڈیٹر) میں کھول دے گا۔ اسے محفوظ کرنے کے لیے اپنے کی بورڈ پر "esc" + ":" + "q" اسی ترتیب میں دبائیں۔ + +اس کے بعد، VSCode میں، اپنی `.env` فائل پر جائیں اور اپنی Pinata API کی (key) اور API سیکرٹ کو اس میں شامل کریں، اس طرح: + +```text +REACT_APP_PINATA_KEY = +REACT_APP_PINATA_SECRET = +``` + +فائل کو محفوظ کریں، اور پھر آپ اپنے JSON میٹا ڈیٹا کو IPFS پر اپ لوڈ کرنے کے لیے فنکشن لکھنا شروع کرنے کے لیے تیار ہیں! + +### pinJSONToIPFS نافذ کریں {#pin-json-to-ipfs} + +خوش قسمتی سے ہمارے لیے، Pinata کے پاس [خاص طور پر JSON ڈیٹا کو IPFS پر اپ لوڈ کرنے کے لیے ایک API](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) ہے اور axios کے ساتھ ایک آسان JavaScript مثال ہے جسے ہم کچھ معمولی ترمیم کے ساتھ استعمال کر سکتے ہیں۔ + +اپنے `utils` فولڈر میں، آئیے `pinata.js` نام کی ایک اور فائل بنائیں اور پھر .env فائل سے اپنی Pinata سیکرٹ اور کی (key) کو اس طرح امپورٹ کریں: + +```javascript +require("dotenv").config() +const key = process.env.REACT_APP_PINATA_KEY +const secret = process.env.REACT_APP_PINATA_SECRET +``` + +اس کے بعد، نیچے سے اضافی کوڈ کو اپنی `pinata.js` فائل میں پیسٹ کریں۔ فکر نہ کریں، ہم ہر چیز کا مطلب سمجھائیں گے! + +```javascript +require("dotenv").config() +const key = process.env.REACT_APP_PINATA_KEY +const secret = process.env.REACT_APP_PINATA_SECRET + +const axios = require("axios") + +export const pinJSONToIPFS = async (JSONBody) => { + const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS` + //making axios POST request to Pinata ⬇️ + return axios + .post(url, JSONBody, { + headers: { + pinata_api_key: key, + pinata_secret_api_key: secret, + }, + }) + .then(function (response) { + return { + success: true, + pinataUrl: + "https://gateway.pinata.cloud/ipfs/" + response.data.IpfsHash, + } + }) + .catch(function (error) { + console.log(error) + return { + success: false, + message: error.message, + } + }) +} +``` + +تو یہ کوڈ بالکل کیا کرتا ہے؟ + +سب سے پہلے، یہ [axios](https://www.npmjs.com/package/axios) امپورٹ کرتا ہے، جو براؤزر اور node.js کے لیے ایک پرامس پر مبنی HTTP کلائنٹ ہے، جسے ہم Pinata سے درخواست کرنے کے لیے استعمال کریں گے۔ + +پھر ہمارے پاس ہمارا غیر مطابقت پذیر فنکشن `pinJSONToIPFS` ہے، جو اپنے ان پٹ کے طور پر `JSONBody` لیتا ہے اور اپنے ہیڈر میں Pinata api کی (key) اور سیکرٹ لیتا ہے، یہ سب ان کے `pinJSONToIPFS` API پر POST کی درخواست کرنے کے لیے ہے۔ + +- اگر یہ POST درخواست کامیاب ہوتی ہے، تو ہمارا فنکشن ایک JSON آبجیکٹ واپس کرتا ہے جس میں `success` بولین true ہوتا ہے اور `pinataUrl` ہوتا ہے جہاں ہمارا میٹا ڈیٹا پن کیا گیا تھا۔ ہم اس `pinataUrl` کو اپنے اسمارٹ کنٹریکٹ کے منٹ فنکشن میں `tokenURI` ان پٹ کے طور پر استعمال کریں گے۔ +- اگر یہ پوسٹ درخواست ناکام ہو جاتی ہے، تو ہمارا فنکشن ایک JSON آبجیکٹ واپس کرتا ہے جس میں `success` بولین false ہوتا ہے اور ایک `message` اسٹرنگ ہوتی ہے جو ہماری غلطی کو بتاتی ہے۔ + +ہمارے `connectWallet` فنکشن کی واپسی کی اقسام کی طرح، ہم JSON آبجیکٹ واپس کر رہے ہیں تاکہ ہم ان کے پیرامیٹرز کا استعمال اپنے اسٹیٹ متغیرات اور UI کو اپ ڈیٹ کرنے کے لیے کر سکیں۔ + +## اپنا اسمارٹ کنٹریکٹ لوڈ کریں {#load-your-smart-contract} + +اب جب کہ ہمارے پاس اپنے `pinJSONToIPFS` فنکشن کے ذریعے اپنے NFT میٹا ڈیٹا کو IPFS پر اپ لوڈ کرنے کا ایک طریقہ ہے، ہمیں اپنے اسمارٹ کنٹریکٹ کا ایک نمونہ لوڈ کرنے کا ایک طریقہ درکار ہوگا تاکہ ہم اس کے `mintNFT` فنکشن کو کال کر سکیں۔ + +جیسا کہ ہم نے پہلے ذکر کیا، اس ٹیوٹوریل میں ہم [یہ موجودہ NFT اسمارٹ کنٹریکٹ](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) استعمال کریں گے؛ تاہم، اگر آپ یہ جاننا چاہتے ہیں کہ ہم نے اسے کیسے بنایا، یا خود ایک بنانا چاہتے ہیں، تو ہم پرزور سفارش کرتے ہیں کہ آپ ہمارا دوسرا ٹیوٹوریل، ["How to Create an NFT"](https://www.alchemy.com/docs/how-to-create-an-nft) دیکھیں۔ + +### کنٹریکٹ ABI {#contract-abi} + +اگر آپ نے ہماری فائلوں کا بغور جائزہ لیا ہے، تو آپ نے دیکھا ہوگا کہ ہماری `src` ڈائرکٹری میں، ایک `contract-abi.json` فائل ہے۔ ایک ABI یہ بتانے کے لیے ضروری ہے کہ ایک کنٹریکٹ کس فنکشن کو طلب کرے گا اور یہ بھی یقینی بنانے کے لیے کہ فنکشن آپ کی متوقع شکل میں ڈیٹا واپس کرے گا۔ + +Ethereum بلاک چین سے جڑنے اور اپنا اسمارٹ کنٹریکٹ لوڈ کرنے کے لیے ہمیں ایک Alchemy API کی (key) اور Alchemy Web3 API کی بھی ضرورت ہوگی۔ + +### اپنی Alchemy API کی (key) بنائیں {#create-alchemy-api} + +اگر آپ کے پاس پہلے سے Alchemy اکاؤنٹ نہیں ہے، تو [یہاں مفت میں سائن اپ کریں۔](https://alchemy.com/?a=eth-org-nft-minter) + +ایک بار جب آپ Alchemy اکاؤنٹ بنا لیں، تو آپ ایک ایپ بنا کر API کلید تیار کر سکتے ہیں۔ یہ ہمیں Ropsten ٹیسٹ نیٹ ورک سے درخواستیں کرنے کی اجازت دے گا۔ + +نیو بار میں "Apps" پر ہوور کرکے اور "Create App" پر کلک کرکے اپنے Alchemy ڈیش بورڈ میں "Create App" صفحہ پر جائیں۔ + +اپنی ایپ کو نام دیں ہم نے "My First NFT!" کا انتخاب کیا، ایک مختصر تفصیل پیش کریں، اپنی ایپ کی بک کیپنگ کے لیے استعمال ہونے والے ماحول کے لیے "Staging" کو منتخب کریں، اور اپنے نیٹ ورک کے لیے "Ropsten" کا انتخاب کریں۔ + +“Create app” پر کلک کریں اور بس! آپ کی ایپ نیچے دی گئی ٹیبل میں ظاہر ہونی چاہیے۔ + +بہت خوب تو اب جب کہ ہم نے اپنا HTTP Alchemy API URL بنا لیا ہے، اسے اپنے کلپ بورڈ پر کاپی کریں... + +... اور پھر آئیے اسے اپنی `.env` فائل میں شامل کریں۔ مجموعی طور پر، آپ کی .env فائل اس طرح نظر آنی چاہیے: + +```text +REACT_APP_PINATA_KEY = +REACT_APP_PINATA_SECRET = +REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/ +``` + +اب جب کہ ہمارے پاس ہمارا کنٹریکٹ ABI اور ہماری Alchemy API کی (key) ہے، ہم [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) کا استعمال کرتے ہوئے اپنا اسمارٹ کنٹریکٹ لوڈ کرنے کے لیے تیار ہیں۔ + +### اپنا Alchemy Web3 اینڈ پوائنٹ اور کنٹریکٹ سیٹ اپ کریں {#setup-alchemy-endpoint} + +سب سے پہلے، اگر آپ کے پاس پہلے سے نہیں ہے، تو آپ کو ٹرمینل میں ہوم ڈائرکٹری: `nft-minter-tutorial` پر جا کر [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) انسٹال کرنے کی ضرورت ہوگی: + +```text +cd .. +npm install @alch/alchemy-web3 +``` + +اس کے بعد آئیے اپنی `interact.js` فائل پر واپس چلتے ہیں۔ فائل کے اوپری حصے میں، اپنی .env فائل سے اپنی Alchemy کی (key) امپورٹ کرنے اور اپنا Alchemy Web3 اینڈ پوائنٹ سیٹ اپ کرنے کے لیے درج ذیل کوڈ شامل کریں: + +```javascript +require("dotenv").config() +const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(alchemyKey) +``` + +[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) [Web3.js](https://docs.web3js.org/) کے ارد گرد ایک ریپر ہے، جو بہتر API طریقے اور دیگر اہم فوائد فراہم کرتا ہے تاکہ آپ کی زندگی کو ایک web3 ڈیولپر کے طور پر آسان بنایا جا سکے۔ یہ کم سے کم کنفیگریشن کی ضرورت کے لیے ڈیزائن کیا گیا ہے تاکہ آپ اسے اپنی ایپ میں فوراً استعمال کرنا شروع کر سکیں! + +اگلا، آئیے اپنی فائل میں اپنا کنٹریکٹ ABI اور کنٹریکٹ کا پتہ شامل کریں۔ + +```javascript +require("dotenv").config() +const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY +const { createAlchemyWeb3 } = require("@alch/alchemy-web3") +const web3 = createAlchemyWeb3(alchemyKey) + +const contractABI = require("../contract-abi.json") +const contractAddress = "0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE" +``` + +ایک بار جب ہمارے پاس یہ دونوں ہو جائیں، تو ہم اپنا منٹ فنکشن کوڈ کرنا شروع کرنے کے لیے تیار ہیں! + +## mintNFT فنکشن نافذ کریں {#implement-the-mintnft-function} + +اپنی `interact.js` فائل کے اندر، آئیے اپنے فنکشن، `mintNFT` کی وضاحت کریں، جو ہم نامی طور پر ہمارا NFT منٹ کرے گا۔ + +چونکہ ہم متعدد غیر مطابقت پذیر کالز کریں گے (Pinata سے اپنے میٹا ڈیٹا کو IPFS پر پن کرنے کے لیے، Alchemy Web3 سے اپنا اسمارٹ کنٹریکٹ لوڈ کرنے کے لیے، اور MetaMask سے اپنے ٹرانزیکشنز پر دستخط کرنے کے لیے)، ہمارا فنکشن بھی غیر مطابقت پذیر ہوگا۔ + +ہمارے فنکشن میں تین ان پٹ ہمارے ڈیجیٹل اثاثے کا `url`، `name`، اور `description` ہوں گے۔ `connectWallet` فنکشن کے نیچے درج ذیل فنکشن کا دستخط شامل کریں: + +```javascript +export const mintNFT = async (url, name, description) => {} +``` + +### ان پٹ کی خرابی کو ہینڈل کرنا {#input-error-handling} + +فطرتاً، فنکشن کے آغاز میں کسی قسم کی ان پٹ کی خرابی کو ہینڈل کرنا سمجھ میں آتا ہے، تاکہ اگر ہمارے ان پٹ پیرامیٹرز درست نہ ہوں تو ہم اس فنکشن سے باہر نکل جائیں۔ اپنے فنکشن کے اندر، آئیے درج ذیل کوڈ شامل کریں: + +```javascript +export const mintNFT = async (url, name, description) => { + //خرابی کو ہینڈل کرنا + if (url.trim() == "" || name.trim() == "" || description.trim() == "") { + return { + success: false, + status: "❗براہ کرم یقینی بنائیں کہ منٹ کرنے سے پہلے تمام فیلڈز مکمل ہیں۔", + } + } +} +``` + +بنیادی طور پر، اگر کوئی بھی ان پٹ پیرامیٹر ایک خالی اسٹرنگ ہے، تو ہم ایک JSON آبجیکٹ واپس کرتے ہیں جہاں `success` بولین false ہوتا ہے، اور `status` اسٹرنگ یہ بتاتی ہے کہ ہمارے UI میں تمام فیلڈز مکمل ہونے چاہئیں۔ + +### میٹا ڈیٹا کو IPFS پر اپ لوڈ کریں {#upload-metadata-to-ipfs} + +ایک بار جب ہم جان لیں کہ ہمارا میٹا ڈیٹا مناسب طریقے سے فارمیٹ کیا گیا ہے، تو اگلا مرحلہ اسے JSON آبجیکٹ میں لپیٹنا اور اسے اپنے لکھے ہوئے `pinJSONToIPFS` کے ذریعے IPFS پر اپ لوڈ کرنا ہے! + +ایسا کرنے کے لیے، ہمیں پہلے اپنی `interact.js` فائل میں `pinJSONToIPFS` فنکشن کو امپورٹ کرنا ہوگا۔ `interact.js` کے بالکل اوپر، آئیے شامل کریں: + +```javascript +import { pinJSONToIPFS } from "./pinata.js" +``` + +یاد رہے کہ `pinJSONToIPFS` ایک JSON باڈی لیتا ہے۔ تو اس پر کال کرنے سے پہلے، ہمیں اپنے `url`، `name`، اور `description` پیرامیٹرز کو JSON آبجیکٹ میں فارمیٹ کرنے کی ضرورت ہوگی۔ + +آئیے اپنے کوڈ کو `metadata` نامی ایک JSON آبجیکٹ بنانے کے لیے اپ ڈیٹ کریں اور پھر اس `metadata` پیرامیٹر کے ساتھ `pinJSONToIPFS` پر کال کریں: + +```javascript +export const mintNFT = async (url, name, description) => { + //خرابی کو ہینڈل کرنا + if (url.trim() == "" || name.trim() == "" || description.trim() == "") { + return { + success: false, + status: "❗براہ کرم یقینی بنائیں کہ منٹ کرنے سے پہلے تمام فیلڈز مکمل ہیں۔", + } + } + + //میٹا ڈیٹا بنائیں + const metadata = new Object() + metadata.name = name + metadata.image = url + metadata.description = description + + //pinata کال کریں + const pinataResponse = await pinJSONToIPFS(metadata) + if (!pinataResponse.success) { + return { + success: false, + status: "😢 آپ کا tokenURI اپ لوڈ کرتے وقت کچھ غلط ہو گیا۔", + } + } + const tokenURI = pinataResponse.pinataUrl +} +``` + +نوٹ کریں، ہم `pinJSONToIPFS(metadata)` پر اپنی کال کا جواب `pinataResponse` آبجیکٹ میں محفوظ کرتے ہیں۔ پھر، ہم اس آبجیکٹ کو کسی بھی خرابی کے لیے پارس کرتے ہیں۔ + +اگر کوئی خرابی ہوتی ہے، تو ہم ایک JSON آبجیکٹ واپس کرتے ہیں جہاں `success` بولین false ہوتا ہے اور ہماری `status` اسٹرنگ بتاتی ہے کہ ہماری کال ناکام ہوگئی۔ ورنہ، ہم `pinataResponse` سے `pinataURL` نکالتے ہیں اور اسے اپنے `tokenURI` متغیر کے طور پر محفوظ کرتے ہیں۔ + +اب وقت آگیا ہے کہ ہم اپنے اسمارٹ کنٹریکٹ کو Alchemy Web3 API کا استعمال کرتے ہوئے لوڈ کریں جسے ہم نے اپنی فائل کے اوپری حصے میں شروع کیا تھا۔ کنٹریکٹ کو `window.contract` عالمی متغیر پر سیٹ کرنے کے لیے `mintNFT` فنکشن کے نیچے کوڈ کی درج ذیل لائن شامل کریں: + +```javascript +window.contract = await new web3.eth.Contract(contractABI, contractAddress) +``` + +ہمارے `mintNFT` فنکشن میں شامل کرنے والی آخری چیز ہمارا Ethereum ٹرانزیکشن ہے: + +```javascript +//اپنا Ethereum ٹرانزیکشن سیٹ اپ کریں +const transactionParameters = { + to: contractAddress, // کنٹریکٹ کی اشاعت کے دوران کے علاوہ ضروری ہے۔ + from: window.ethereum.selectedAddress, // صارف کے فعال پتے سے مماثل ہونا چاہیے۔ + data: window.contract.methods + .mintNFT(window.ethereum.selectedAddress, tokenURI) + .encodeABI(), //NFT اسمارٹ کنٹریکٹ پر کال کریں +} + +//MetaMask کے ذریعے ٹرانزیکشن پر دستخط کریں +try { + const txHash = await window.ethereum.request({ + method: "eth_sendTransaction", + params: [transactionParameters], + }) + return { + success: true, + status: + "✅ Etherscan پر اپنے ٹرانزیکشن کو دیکھیں: https://ropsten.etherscan.io/tx/" + + txHash, + } +} catch (error) { + return { + success: false, + status: "😥 کچھ غلط ہو گیا: " + error.message, + } +} +``` + +اگر آپ پہلے سے ہی Ethereum ٹرانزیکشنز سے واقف ہیں، تو آپ دیکھیں گے کہ ساخت آپ نے جو دیکھا ہے اس سے کافی ملتی جلتی ہے۔ + +- سب سے پہلے، ہم اپنے ٹرانزیکشنز پیرامیٹرز سیٹ اپ کرتے ہیں۔ + - `to` وصول کنندہ کا پتہ (ہمارا اسمارٹ کنٹریکٹ) بتاتا ہے + - `from` ٹرانزیکشن کے دستخط کنندہ (صارف کا MetaMask سے جڑا ہوا پتہ: `window.ethereum.selectedAddress`) کی وضاحت کرتا ہے + - `data` میں ہمارے اسمارٹ کنٹریکٹ `mintNFT` میتھڈ پر کال شامل ہے، جو ہمارے `tokenURI` اور صارف کے والیٹ پتے، `window.ethereum.selectedAddress`، کو ان پٹ کے طور پر وصول کرتا ہے۔ +- پھر، ہم ایک await کال، `window.ethereum.request` کرتے ہیں، جہاں ہم MetaMask سے ٹرانزیکشن پر دستخط کرنے کو کہتے ہیں۔ نوٹ کریں، اس درخواست میں، ہم اپنے eth میتھڈ (eth_SentTransaction) کی وضاحت کر رہے ہیں اور اپنے `transactionParameters` پاس کر رہے ہیں۔ اس مقام پر، MetaMask براؤزر میں کھل جائے گا، اور صارف سے ٹرانزیکشن پر دستخط کرنے یا مسترد کرنے کا کہے گا۔ + - اگر ٹرانزیکشن کامیاب ہو جاتا ہے، تو فنکشن ایک JSON آبجیکٹ واپس کرے گا جہاں بولین `success` کو true پر سیٹ کیا گیا ہے اور `status` اسٹرنگ صارف کو اپنے ٹرانزیکشن کے بارے میں مزید معلومات کے لیے Etherscan چیک کرنے کا کہتی ہے۔ + - اگر ٹرانزیکشن ناکام ہو جاتا ہے، تو فنکشن ایک JSON آبجیکٹ واپس کرے گا جہاں `success` بولین کو false پر سیٹ کیا گیا ہے، اور `status` اسٹرنگ غلطی کا پیغام بتاتی ہے۔ + +مجموعی طور پر، ہمارا `mintNFT` فنکشن اس طرح نظر آنا چاہیے: + +```javascript +export const mintNFT = async (url, name, description) => { + //خرابی کو ہینڈل کرنا + if (url.trim() == "" || name.trim() == "" || description.trim() == "") { + return { + success: false, + status: "❗براہ کرم یقینی بنائیں کہ منٹ کرنے سے پہلے تمام فیلڈز مکمل ہیں۔", + } + } + + //میٹا ڈیٹا بنائیں + const metadata = new Object() + metadata.name = name + metadata.image = url + metadata.description = description + + //pinata پن کی درخواست + const pinataResponse = await pinJSONToIPFS(metadata) + if (!pinataResponse.success) { + return { + success: false, + status: "😢 آپ کا tokenURI اپ لوڈ کرتے وقت کچھ غلط ہو گیا۔", + } + } + const tokenURI = pinataResponse.pinataUrl + + //اسمارٹ کنٹریکٹ لوڈ کریں + window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract(); + + //اپنا Ethereum ٹرانزیکشن سیٹ اپ کریں + const transactionParameters = { + to: contractAddress, // کنٹریکٹ کی اشاعت کے دوران کے علاوہ ضروری ہے۔ + from: window.ethereum.selectedAddress, // صارف کے فعال پتے سے مماثل ہونا چاہیے۔ + data: window.contract.methods + .mintNFT(window.ethereum.selectedAddress, tokenURI) + .encodeABI(), //NFT اسمارٹ کنٹریکٹ پر کال کریں + } + + //MetaMask کے ذریعے ٹرانزیکشن پر دستخط کریں + try { + const txHash = await window.ethereum.request({ + method: "eth_sendTransaction", + params: [transactionParameters], + }) + return { + success: true, + status: + "✅ Etherscan پر اپنے ٹرانزیکشن کو دیکھیں: https://ropsten.etherscan.io/tx/" + + txHash, + } + } catch (error) { + return { + success: false, + status: "😥 کچھ غلط ہو گیا: " + error.message, + } + } +} +``` + +یہ ایک بہت بڑا فنکشن ہے! اب، ہمیں صرف اپنے `mintNFT` فنکشن کو اپنے `Minter.js` کمپونینٹ سے جوڑنے کی ضرورت ہے... + +## mintNFT کو ہمارے Minter.js فرنٹ اینڈ سے جوڑیں {#connect-our-frontend} + +اپنی `Minter.js` فائل کھولیں اور اوپر کی `import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";` لائن کو اپ ڈیٹ کرکے یہ کریں: + +```javascript +import { + connectWallet, + getCurrentWalletConnected, + mintNFT, +} from "./utils/interact.js" +``` + +آخر میں، اپنے امپورٹ کردہ `mintNFT` فنکشن پر await کال کرنے کے لیے `onMintPressed` فنکشن کو نافذ کریں اور `status` اسٹیٹ متغیر کو اپ ڈیٹ کریں تاکہ یہ ظاہر ہو سکے کہ ہمارا ٹرانزیکشن کامیاب ہوا یا ناکام: + +```javascript +const onMintPressed = async () => { + const { status } = await mintNFT(url, name, description) + setStatus(status) +} +``` + +## اپنا NFT ایک لائیو ویب سائٹ پر تعینات کریں {#deploy-your-NFT} + +صارفین کے ساتھ تعامل کے لیے اپنے پروجیکٹ کو لائیو کرنے کے لیے تیار ہیں؟ اپنے منٹر کو ایک لائیو ویب سائٹ پر تعینات کرنے کے لیے [یہ ٹیوٹوریل](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) دیکھیں۔ + +ایک آخری قدم... + +## بلاک چین کی دنیا میں طوفان برپا کریں {#take-the-blockchain-world-by-storm} + +مذاق کر رہا ہوں، آپ ٹیوٹوریل کے آخر تک پہنچ گئے ہیں! + +خلاصہ یہ کہ، ایک NFT منٹر بنا کر، آپ نے کامیابی سے سیکھا کہ: + +- اپنے فرنٹ اینڈ پروجیکٹ کے ذریعے MetaMask سے جڑیں +- اپنے فرنٹ اینڈ سے اسمارٹ کنٹریکٹ طریقوں کو کال کریں +- MetaMask کا استعمال کرتے ہوئے ٹرانزیکشنز پر دستخط کریں + +یقیناً، آپ اپنے والیٹ میں اپنے dApp کے ذریعے منٹ کیے گئے NFTs کو دکھانا چاہیں گے — تو ہمارا فوری ٹیوٹوریل [اپنے NFT کو اپنے والیٹ میں کیسے دیکھیں](https://www.alchemy.com/docs/how-to-view-your-nft-in-your-mobile-wallet) ضرور دیکھیں۔ + +اور، ہمیشہ کی طرح، اگر آپ کے کوئی سوالات ہیں، تو ہم [Alchemy Discord](https://discord.gg/gWuC7zB) میں مدد کے لیے موجود ہیں۔ ہم یہ دیکھنے کے لیے انتظار نہیں کر سکتے کہ آپ اس ٹیوٹوریل کے تصورات کو اپنے مستقبل کے پروجیکٹس پر کیسے لاگو کرتے ہیں! diff --git a/public/content/translations/ur/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/ur/developers/tutorials/optimism-std-bridge-annotated-code/index.md new file mode 100644 index 00000000000..496e13470c4 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -0,0 +1,1354 @@ +--- +title: "Optimism معیاری برج کنٹریکٹ واک تھرو" +description: "Optimism کے لیے معیاری برج کیسے کام کرتا ہے؟ یہ اس طرح کیوں کام کرتا ہے؟" +author: Ori Pomerantz +tags: [ "solidity", "برج", "لیئر 2" ] +skill: intermediate +published: 2022-03-30 +lang: ur-in +--- + +[Optimism](https://www.optimism.io/) ایک [Optimistic Rollup](/developers/docs/scaling/optimistic-rollups/) ہے۔ +Optimistic rollups ٹرانزیکشنز کو Ethereum Mainnet (جسے layer 1 یا L1 بھی کہا جاتا ہے) کے مقابلے میں بہت کم قیمت پر پراسیس کر سکتے ہیں کیونکہ ٹرانزیکشنز کو نیٹ ورک پر ہر نوڈ کے بجائے صرف چند نوڈز کے ذریعے پراسیس کیا جاتا ہے۔ +ایک ہی وقت میں، تمام ڈیٹا L1 پر لکھا جاتا ہے تاکہ Mainnet کی تمام سالمیت اور دستیابی کی ضمانتوں کے ساتھ ہر چیز کو ثابت اور دوبارہ تعمیر کیا جا سکے۔ + +Optimism (یا کسی دوسرے L2) پر L1 اثاثے استعمال کرنے کے لیے، اثاثوں کو [bridged](/bridges/#prerequisites) کرنے کی ضرورت ہے۔ +اس کو حاصل کرنے کا ایک طریقہ یہ ہے کہ صارفین L1 پر اثاثوں (ETH اور [ERC-20 tokens](/developers/docs/standards/tokens/erc-20/) سب سے عام ہیں) کو لاک کریں، اور L2 پر استعمال کرنے کے لیے مساوی اثاثے حاصل کریں۔ +بالآخر، جو بھی ان کے ساتھ ختم ہوتا ہے وہ انہیں واپس L1 پر برج کرنا چاہے گا۔ +ایسا کرتے وقت، اثاثے L2 پر جلا دیے جاتے ہیں اور پھر L1 پر صارف کو واپس جاری کر دیے جاتے ہیں۔ + +یہ وہ طریقہ ہے جس سے [Optimism standard bridge](https://docs.optimism.io/app-developers/bridging/standard-bridge) کام کرتا ہے۔ +اس مضمون میں ہم اس برج کے سورس کوڈ کا جائزہ لیتے ہیں تاکہ یہ دیکھیں کہ یہ کیسے کام کرتا ہے اور اسے اچھی طرح سے لکھے گئے Solidity کوڈ کی مثال کے طور پر مطالعہ کریں۔ + +## کنٹرول فلو {#control-flows} + +برج کے دو اہم فلو ہیں: + +- ڈپازٹ (L1 سے L2 تک) +- واپسی (L2 سے L1 تک) + +### ڈپازٹ فلو {#deposit-flow} + +#### لیئر 1 {#deposit-flow-layer-1} + +1. اگر ERC-20 جمع کر رہے ہیں، تو جمع کنندہ برج کو جمع کی جا رہی رقم خرچ کرنے کی اجازت دیتا ہے +2. جمع کنندہ L1 برج کو کال کرتا ہے (`depositERC20`, `depositERC20To`, `depositETH`, یا `depositETHTo`) +3. L1 برج برجڈ اثاثے کا قبضہ لیتا ہے + - ETH: اثاثہ کال کے حصے کے طور پر جمع کنندہ کے ذریعے منتقل کیا جاتا ہے + - ERC-20: اثاثہ برج کے ذریعے جمع کنندہ کی طرف سے فراہم کردہ الاؤنس کا استعمال کرتے ہوئے خود کو منتقل کیا جاتا ہے +4. L1 برج L2 برج پر `finalizeDeposit` کو کال کرنے کے لیے کراس ڈومین میسج میکانزم کا استعمال کرتا ہے + +#### لیئر 2 {#deposit-flow-layer-2} + +5. L2 برج `finalizeDeposit` کی کال کی تصدیق کرتا ہے کہ یہ جائز ہے: + - کراس ڈومین میسج کنٹریکٹ سے آیا ہے + - اصل میں L1 پر برج سے تھا +6. L2 برج چیک کرتا ہے کہ آیا L2 پر ERC-20 ٹوکن کنٹریکٹ درست ہے: + - L2 کنٹریکٹ رپورٹ کرتا ہے کہ اس کا L1 ہم منصب وہی ہے جہاں سے L1 پر ٹوکن آئے تھے + - L2 کنٹریکٹ رپورٹ کرتا ہے کہ یہ درست انٹرفیس کو سپورٹ کرتا ہے ([using ERC-165](https://eips.ethereum.org/EIPS/eip-165)). +7. اگر L2 کنٹریکٹ درست ہے، تو اسے مناسب ایڈریس پر مناسب تعداد میں ٹوکن منٹ کرنے کے لیے کال کریں۔ اگر نہیں، تو صارف کو L1 پر ٹوکن کا دعویٰ کرنے کی اجازت دینے کے لیے واپسی کا عمل شروع کریں۔ + +### واپسی کا فلو {#withdrawal-flow} + +#### لیئر 2 {#withdrawal-flow-layer-2} + +1. واپس لینے والا L2 برج (`withdraw` یا `withdrawTo`) کو کال کرتا ہے +2. L2 برج `msg.sender` سے تعلق رکھنے والے ٹوکنز کی مناسب تعداد کو جلا دیتا ہے +3. L2 برج کراس ڈومین میسج میکانزم کا استعمال L1 برج پر `finalizeETHWithdrawal` یا `finalizeERC20Withdrawal` کو کال کرنے کے لیے کرتا ہے + +#### لیئر 1 {#withdrawal-flow-layer-1} + +4. L1 برج `finalizeETHWithdrawal` یا `finalizeERC20Withdrawal` کی کال کی تصدیق کرتا ہے کہ یہ جائز ہے: + - کراس ڈومین میسج میکانزم سے آیا ہے + - اصل میں L2 پر برج سے تھا +5. L1 برج مناسب اثاثہ (ETH یا ERC-20) کو مناسب ایڈریس پر منتقل کرتا ہے + +## لیئر 1 کوڈ {#layer-1-code} + +یہ وہ کوڈ ہے جو L1، Ethereum Mainnet پر چلتا ہے۔ + +### IL1ERC20Bridge {#IL1ERC20Bridge} + +[یہ انٹرفیس یہاں بیان کیا گیا ہے](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol)۔ +اس میں ERC-20 ٹوکنز کو برج کرنے کے لیے درکار فنکشنز اور تعریفیں شامل ہیں۔ + +```solidity +// SPDX-License-Identifier: MIT +``` + +[Optimism کا زیادہ تر کوڈ MIT لائسنس کے تحت جاری کیا گیا ہے](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-). + +```solidity +pragma solidity >0.5.0 <0.9.0; +``` + +لکھنے کے وقت Solidity کا تازہ ترین ورژن 0.8.12 ہے۔ +جب تک ورژن 0.9.0 جاری نہیں ہو جاتا، ہم نہیں جانتے کہ یہ کوڈ اس کے ساتھ مطابقت رکھتا ہے یا نہیں۔ + +```solidity +/** + * @title IL1ERC20Bridge + */ +interface IL1ERC20Bridge { + /********** + * ایونٹس * + **********/ + + event ERC20DepositInitiated( +``` + +Optimism برج کی اصطلاح میں _ڈپازٹ_ کا مطلب L1 سے L2 میں منتقلی ہے، اور _واپسی_ کا مطلب L2 سے L1 میں منتقلی ہے۔ + +```solidity + address indexed _l1Token, + address indexed _l2Token, +``` + +زیادہ تر معاملات میں L1 پر ERC-20 کا ایڈریس L2 پر مساوی ERC-20 کے ایڈریس کے برابر نہیں ہوتا ہے۔ +[آپ ٹوکن ایڈریس کی فہرست یہاں دیکھ سکتے ہیں](https://static.optimism.io/optimism.tokenlist.json)۔ +`chainId` 1 والا ایڈریس L1 (Mainnet) پر ہے اور `chainId` 10 والا ایڈریس L2 (Optimism) پر ہے۔ +دیگر دو `chainId` قدریں Kovan ٹیسٹ نیٹ ورک (42) اور Optimistic Kovan ٹیسٹ نیٹ ورک (69) کے لیے ہیں۔ + +```solidity + address indexed _from, + address _to, + uint256 _amount, + bytes _data + ); +``` + +منتقلی میں نوٹس شامل کرنا ممکن ہے، اس صورت میں انہیں ان ایونٹس میں شامل کیا جاتا ہے جو ان کی رپورٹ کرتے ہیں۔ + +```solidity + event ERC20WithdrawalFinalized( + address indexed _l1Token, + address indexed _l2Token, + address indexed _from, + address _to, + uint256 _amount, + bytes _data + ); +``` + +وہی برج کنٹریکٹ دونوں سمتوں میں منتقلی کو سنبھالتا ہے۔ +L1 برج کے معاملے میں، اس کا مطلب ہے ڈپازٹ کا آغاز اور واپسی کی حتمی شکل۔ + +```solidity + + /******************** + * پبلک فنکشنز * + ********************/ + + /** + * @dev متعلقہ L2 برج کنٹریکٹ کا ایڈریس حاصل کریں۔ + * @return متعلقہ L2 برج کنٹریکٹ کا ایڈریس۔ + */ + function l2TokenBridge() external returns (address); +``` + +اس فنکشن کی واقعی ضرورت نہیں ہے، کیونکہ L2 پر یہ ایک پہلے سے تعینات کنٹریکٹ ہے، لہذا یہ ہمیشہ ایڈریس `0x4200000000000000000000000000000000000010` پر ہوتا ہے۔ +یہاں L2 برج کے ساتھ ہم آہنگی کے لیے ہے، کیونکہ L1 برج کا ایڈریس جاننا معمولی بات نہیں ہے۔ + +```solidity + /** + * @dev L2 پر کالر کے بیلنس میں ERC20 کی رقم جمع کریں۔ + * @param _l1Token L1 ERC20 کا ایڈریس جسے ہم جمع کر رہے ہیں + * @param _l2Token L1 متعلقہ L2 ERC20 کا ایڈریس + * @param _amount جمع کرنے کے لیے ERC20 کی رقم + * @param _l2Gas L2 پر ڈپازٹ مکمل کرنے کے لیے درکار گیس کی حد۔ + * @param _data L2 کو فارورڈ کرنے کے لیے اختیاری ڈیٹا۔ یہ ڈیٹا + * صرف بیرونی کنٹریکٹس کی سہولت کے لیے فراہم کیا گیا ہے۔ زیادہ سے زیادہ + * لمبائی نافذ کرنے کے علاوہ، یہ کنٹریکٹس اس کے مواد کے بارے میں کوئی ضمانت نہیں دیتے ہیں۔ + */ + function depositERC20( + address _l1Token, + address _l2Token, + uint256 _amount, + uint32 _l2Gas, + bytes calldata _data + ) external; +``` + +`_l2Gas` پیرامیٹر L2 گیس کی وہ مقدار ہے جو ٹرانزیکشن خرچ کرنے کی اجازت ہے۔ +[ایک مخصوص (اعلی) حد تک، یہ مفت ہے](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2)، لہذا جب تک ERC-20 کنٹریکٹ منٹنگ کے وقت کچھ واقعی عجیب کام نہیں کرتا، یہ کوئی مسئلہ نہیں ہونا چاہئے۔ +یہ فنکشن عام منظر نامے کا خیال رکھتا ہے، جہاں ایک صارف ایک مختلف بلاک چین پر ایک ہی ایڈریس پر اثاثوں کو برج کرتا ہے۔ + +```solidity + /** + * @dev L2 پر وصول کنندہ کے بیلنس میں ERC20 کی رقم جمع کریں۔ + * @param _l1Token L1 ERC20 کا ایڈریس جسے ہم جمع کر رہے ہیں + * @param _l2Token L1 متعلقہ L2 ERC20 کا ایڈریس + * @param _to L2 ایڈریس جس پر واپسی کریڈٹ کی جائے گی۔ + * @param _amount جمع کرنے کے لیے ERC20 کی رقم۔ + * @param _l2Gas L2 پر ڈپازٹ مکمل کرنے کے لیے درکار گیس کی حد۔ + * @param _data L2 کو فارورڈ کرنے کے لیے اختیاری ڈیٹا۔ یہ ڈیٹا + * صرف بیرونی کنٹریکٹس کی سہولت کے لیے فراہم کیا گیا ہے۔ زیادہ سے زیادہ + * لمبائی نافذ کرنے کے علاوہ، یہ کنٹریکٹس اس کے مواد کے بارے میں کوئی ضمانت نہیں دیتے ہیں۔ + */ + function depositERC20To( + address _l1Token, + address _l2Token, + address _to, + uint256 _amount, + uint32 _l2Gas, + bytes calldata _data + ) external; +``` + +یہ فنکشن تقریباً `depositERC20` جیسا ہی ہے، لیکن یہ آپ کو ERC-20 کو ایک مختلف ایڈریس پر بھیجنے دیتا ہے۔ + +```solidity + /************************* + * کراس چین فنکشنز * + *************************/ + + /** + * @dev L2 سے L1 تک کی واپسی کو مکمل کریں، اور فنڈز کو + * L1 ERC20 ٹوکن کے وصول کنندہ کے بیلنس میں کریڈٹ کریں۔ + * اگر L2 سے شروع کی گئی واپسی کو حتمی شکل نہیں دی گئی ہے تو یہ کال ناکام ہو جائے گی۔ + * + * @param _l1Token L1 ٹوکن کا ایڈریس جس کے لیے finalizeWithdrawal کرنا ہے۔ + * @param _l2Token L2 ٹوکن کا ایڈریس جہاں سے واپسی شروع کی گئی تھی۔ + * @param _from منتقلی شروع کرنے والا L2 ایڈریس۔ + * @param _to L1 ایڈریس جس پر واپسی کریڈٹ کی جائے گی۔ + * @param _amount جمع کرنے کے لیے ERC20 کی رقم۔ + * @param _data L2 پر بھیجنے والے کی طرف سے فراہم کردہ ڈیٹا۔ یہ ڈیٹا + * صرف بیرونی کنٹریکٹس کی سہولت کے لیے فراہم کیا گیا ہے۔ زیادہ سے زیادہ + * لمبائی نافذ کرنے کے علاوہ، یہ کنٹریکٹس اس کے مواد کے بارے میں کوئی ضمانت نہیں دیتے ہیں۔ + */ + function finalizeERC20Withdrawal( + address _l1Token, + address _l2Token, + address _from, + address _to, + uint256 _amount, + bytes calldata _data + ) external; +} +``` + +Optimism میں واپسی (اور L2 سے L1 تک کے دیگر پیغامات) دو مرحلوں کا عمل ہے: + +1. L2 پر ایک ابتدائی ٹرانزیکشن۔ +2. L1 پر ایک حتمی یا دعویٰ کرنے والی ٹرانزیکشن۔ + یہ ٹرانزیکشن L2 ٹرانزیکشن کے لیے [fault challenge period](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) کے ختم ہونے کے بعد ہونا ضروری ہے۔ + +### IL1StandardBridge {#il1standardbridge} + +[یہ انٹرفیس یہاں بیان کیا گیا ہے](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol)۔ +اس فائل میں ETH کے لیے ایونٹ اور فنکشن کی تعریفیں ہیں۔ +یہ تعریفیں ERC-20 کے لیے اوپر `IL1ERC20Bridge` میں بیان کردہ تعریفوں سے بہت ملتی جلتی ہیں۔ + +برج انٹرفیس کو دو فائلوں کے درمیان تقسیم کیا گیا ہے کیونکہ کچھ ERC-20 ٹوکنز کو اپنی مرضی کے مطابق پروسیسنگ کی ضرورت ہوتی ہے اور معیاری برج کے ذریعے انہیں ہینڈل نہیں کیا جا سکتا۔ +اس طرح کسٹم برج جو ایسے ٹوکن کو ہینڈل کرتا ہے وہ `IL1ERC20Bridge` کو لاگو کر سکتا ہے اور اسے ETH کو بھی برج کرنے کی ضرورت نہیں ہوتی ہے۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity >0.5.0 <0.9.0; + +import "./IL1ERC20Bridge.sol"; + +/** + * @title IL1StandardBridge + */ +interface IL1StandardBridge is IL1ERC20Bridge { + /********** + * ایونٹس * + **********/ + event ETHDepositInitiated( + address indexed _from, + address indexed _to, + uint256 _amount, + bytes _data + ); +``` + +یہ ایونٹ تقریباً ERC-20 ورژن (`ERC20DepositInitiated`) جیسا ہی ہے، سوائے L1 اور L2 ٹوکن ایڈریس کے۔ +دیگر ایونٹس اور فنکشنز کے لیے بھی یہی سچ ہے۔ + +```solidity + event ETHWithdrawalFinalized( + . + . + . + ); + + /******************** + * پبلک فنکشنز * + ********************/ + + /** + * @dev L2 پر کالر کے بیلنس میں ETH کی رقم جمع کریں۔ + . + . + . + */ + function depositETH(uint32 _l2Gas, bytes calldata _data) external payable; + + /** + * @dev L2 پر وصول کنندہ کے بیلنس میں ETH کی رقم جمع کریں۔ + . + . + . + */ + function depositETHTo( + address _to, + uint32 _l2Gas, + bytes calldata _data + ) external payable; + + /************************* + * کراس چین فنکشنز * + *************************/ + + /** + * @dev L2 سے L1 تک کی واپسی کو مکمل کریں، اور فنڈز کو + * L1 ETH ٹوکن کے وصول کنندہ کے بیلنس میں کریڈٹ کریں۔ چونکہ صرف xDomainMessenger ہی اس فنکشن کو کال کر سکتا ہے، اس لیے اسے + * واپسی کے حتمی ہونے سے پہلے کبھی کال نہیں کیا جائے گا۔ + . + . + . + */ + function finalizeETHWithdrawal( + address _from, + address _to, + uint256 _amount, + bytes calldata _data + ) external; +} +``` + +### CrossDomainEnabled {#crossdomainenabled} + +[یہ کنٹریکٹ](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol) دونوں برجز ([L1](#the-l1-bridge-contract) اور [L2](#the-l2-bridge-contract)) کے ذریعے وراثت میں ملا ہے تاکہ دوسری لیئر کو پیغامات بھیج سکیں۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity >0.5.0 <0.9.0; + +/* انٹرفیس امپورٹس */ +import { ICrossDomainMessenger } from "./ICrossDomainMessenger.sol"; +``` + +[یہ انٹرفیس](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) کنٹریکٹ کو بتاتا ہے کہ کراس ڈومین میسنجر کا استعمال کرتے ہوئے دوسری لیئر کو پیغامات کیسے بھیجیں۔ +یہ کراس ڈومین میسنجر ایک بالکل مختلف نظام ہے، اور اس کا اپنا مضمون ہونا چاہیے، جو مجھے امید ہے کہ مستقبل میں لکھوں گا۔ + +```solidity +/** + * @title CrossDomainEnabled + * @dev کراس ڈومین کمیونیکیشن کرنے والے کنٹریکٹس کے لیے ہیلپر کنٹریکٹ + * + * استعمال شدہ کمپائلر: وراثت میں ملنے والے کنٹریکٹ کے ذریعے بیان کیا گیا ہے + */ +contract CrossDomainEnabled { + /************* + * متغیرات * + *************/ + + // دوسرے ڈومین سے پیغامات بھیجنے اور وصول کرنے کے لیے استعمال ہونے والا میسنجر کنٹریکٹ۔ + address public messenger; + + /*************** + * کنسٹرکٹر * + ***************/ + + /** + * @param _messenger موجودہ لیئر پر CrossDomainMessenger کا ایڈریس۔ + */ + constructor(address _messenger) { + messenger = _messenger; + } +``` + +ایک پیرامیٹر جو کنٹریکٹ کو جاننے کی ضرورت ہے، وہ اس لیئر پر کراس ڈومین میسنجر کا ایڈریس ہے۔ +یہ پیرامیٹر ایک بار کنسٹرکٹر میں سیٹ کیا جاتا ہے، اور کبھی تبدیل نہیں ہوتا ہے۔ + +```solidity + + /********************** + * فنکشن موڈیفائرز * + **********************/ + + /** + * نافذ کرتا ہے کہ ترمیم شدہ فنکشن صرف ایک مخصوص کراس ڈومین اکاؤنٹ کے ذریعے کال کیا جا سکتا ہے۔ + * @param _sourceDomainAccount اصل ڈومین پر واحد اکاؤنٹ جو + * اس فنکشن کو کال کرنے کے لیے مستند ہے۔ + */ + modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) { +``` + +کراس ڈومین میسجنگ بلاک چین پر کسی بھی کنٹریکٹ کے ذریعے قابل رسائی ہے جہاں یہ چل رہا ہے (یا تو Ethereum mainnet یا Optimism)۔ +لیکن ہمیں ہر طرف برج کی ضرورت ہے تاکہ وہ _صرف_ کچھ پیغامات پر بھروسہ کرے اگر وہ دوسری طرف کے برج سے آتے ہیں۔ + +```solidity + require( + msg.sender == address(getCrossDomainMessenger()), + "OVM_XCHAIN: میسنجر کنٹریکٹ غیر مستند" + ); +``` + +صرف مناسب کراس ڈومین میسنجر (`messenger`, جیسا کہ آپ نیچے دیکھتے ہیں) سے آنے والے پیغامات پر بھروسہ کیا جا سکتا ہے۔ + +```solidity + + require( + getCrossDomainMessenger().xDomainMessageSender() == _sourceDomainAccount, + "OVM_XCHAIN: کراس ڈومین پیغام کا غلط بھیجنے والا" + ); +``` + +کراس ڈومین میسنجر جس طرح سے دوسری لیئر کے ساتھ پیغام بھیجنے والے ایڈریس کو فراہم کرتا ہے وہ ہے [ `.xDomainMessageSender()` فنکشن](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128)۔ +جب تک اسے اس ٹرانزیکشن میں کال کیا جاتا ہے جو پیغام کے ذریعے شروع کی گئی تھی، یہ یہ معلومات فراہم کر سکتا ہے۔ + +ہمیں یہ یقینی بنانا ہوگا کہ ہمیں موصول ہونے والا پیغام دوسرے برج سے آیا ہے۔ + +```solidity + _; + } + + /********************** + * اندرونی فنکشنز * + **********************/ + + /** + * میسنجر حاصل کرتا ہے، عام طور پر اسٹوریج سے۔ یہ فنکشن اس صورت میں ظاہر ہوتا ہے جب کسی چائلڈ کنٹریکٹ + * کو اوور رائڈ کرنے کی ضرورت ہو۔ + * @return کراس ڈومین میسنجر کنٹریکٹ کا ایڈریس جو استعمال کیا جانا چاہئے۔ + */ + function getCrossDomainMessenger() internal virtual returns (ICrossDomainMessenger) { + return ICrossDomainMessenger(messenger); + } +``` + +یہ فنکشن کراس ڈومین میسنجر کو واپس کرتا ہے۔ +ہم متغیر `messenger` کے بجائے ایک فنکشن استعمال کرتے ہیں تاکہ اس سے وراثت میں ملنے والے کنٹریکٹس کو ایک الگورتھم استعمال کرنے کی اجازت دی جا سکے تاکہ یہ بتایا جا سکے کہ کون سا کراس ڈومین میسنجر استعمال کرنا ہے۔ + +```solidity + + /** + * دوسرے ڈومین پر ایک اکاؤنٹ کو ایک پیغام بھیجتا ہے + * @param _crossDomainTarget منزل کے ڈومین پر مطلوبہ وصول کنندہ + * @param _message ہدف کو بھیجنے کے لیے ڈیٹا (عام طور پر ایک فنکشن کے لیے کال ڈیٹا + * `onlyFromCrossDomainAccount()` کے ساتھ) + * @param _gasLimit ہدف ڈومین پر پیغام کی رسید کے لیے گیس کی حد۔ + */ + function sendCrossDomainMessage( + address _crossDomainTarget, + uint32 _gasLimit, + bytes memory _message +``` + +آخر میں، وہ فنکشن جو دوسری لیئر کو ایک پیغام بھیجتا ہے۔ + +```solidity + ) internal { + // slither-disable-next-line reentrancy-events, reentrancy-benign +``` + +[Slither](https://github.com/crytic/slither) ایک جامد تجزیہ کار ہے جسے Optimism ہر کنٹریکٹ پر کمزوریوں اور دیگر ممکنہ مسائل کو تلاش کرنے کے لیے چلاتا ہے۔ +اس معاملے میں، مندرجہ ذیل لائن دو کمزوریوں کو متحرک کرتی ہے: + +1. [Reentrancy events](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3) +2. [Benign reentrancy](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2) + +```solidity + getCrossDomainMessenger().sendMessage(_crossDomainTarget, _message, _gasLimit); + } +} +``` + +اس معاملے میں ہم reentrancy کے بارے میں فکر مند نہیں ہیں کیونکہ ہم جانتے ہیں کہ `getCrossDomainMessenger()` ایک قابل اعتماد ایڈریس واپس کرتا ہے، چاہے Slither کو یہ جاننے کا کوئی طریقہ نہ ہو۔ + +### L1 برج کنٹریکٹ {#the-l1-bridge-contract} + +[اس کنٹریکٹ کا سورس کوڈ یہاں ہے](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol)۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.9; +``` + +انٹرفیس دوسرے کنٹریکٹس کا حصہ ہو سکتے ہیں، لہذا انہیں Solidity ورژن کی ایک وسیع رینج کو سپورٹ کرنا ہوگا۔ +لیکن برج خود ہمارا کنٹریکٹ ہے، اور ہم اس بارے میں سخت ہو سکتے ہیں کہ یہ کون سا Solidity ورژن استعمال کرتا ہے۔ + +```solidity +/* انٹرفیس امپورٹس */ +import { IL1StandardBridge } from "./IL1StandardBridge.sol"; +import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol"; +``` + +[IL1ERC20Bridge](#IL1ERC20Bridge) اور [IL1StandardBridge](#IL1StandardBridge) اوپر بیان کیے گئے ہیں۔ + +```solidity +import { IL2ERC20Bridge } from "../../L2/messaging/IL2ERC20Bridge.sol"; +``` + +[یہ انٹرفیس](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) ہمیں L2 پر معیاری برج کو کنٹرول کرنے کے لیے پیغامات بنانے دیتا ہے۔ + +```solidity +import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; +``` + +[یہ انٹرفیس](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) ہمیں ERC-20 کنٹریکٹس کو کنٹرول کرنے دیتا ہے۔ +[آپ اس کے بارے میں مزید یہاں پڑھ سکتے ہیں](/developers/tutorials/erc20-annotated-code/#the-interface)۔ + +```solidity +/* لائبریری امپورٹس */ +import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol"; +``` + +[جیسا کہ اوپر بیان کیا گیا ہے](#crossdomainenabled)، یہ کنٹریکٹ انٹر لیئر میسجنگ کے لیے استعمال ہوتا ہے۔ + +```solidity +import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol"; +``` + +[`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) میں L2 کنٹریکٹس کے ایڈریس ہیں جن کا ہمیشہ ایک ہی ایڈریس ہوتا ہے۔ اس میں L2 پر معیاری برج شامل ہے۔ + +```solidity +import { Address } from "@openzeppelin/contracts/utils/Address.sol"; +``` + +[OpenZeppelin کی ایڈریس یوٹیلیٹیز](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol)۔ اس کا استعمال کنٹریکٹ ایڈریس اور بیرونی طور پر ملکیت والے اکاؤنٹس (EOA) سے تعلق رکھنے والوں کے درمیان فرق کرنے کے لیے کیا جاتا ہے۔ + +نوٹ کریں کہ یہ ایک بہترین حل نہیں ہے، کیونکہ براہ راست کالز اور کنٹریکٹ کے کنسٹرکٹر سے کی گئی کالز کے درمیان فرق کرنے کا کوئی طریقہ نہیں ہے، لیکن کم از کم یہ ہمیں کچھ عام صارف کی غلطیوں کی نشاندہی کرنے اور انہیں روکنے دیتا ہے۔ + +```solidity +import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol"; +``` + +[ERC-20 معیار](https://eips.ethereum.org/EIPS/eip-20) ایک کنٹریکٹ کے لیے ناکامی کی رپورٹ کرنے کے دو طریقے سپورٹ کرتا ہے: + +1. واپس کریں +2. `false` واپس کریں + +دونوں صورتوں کو ہینڈل کرنے سے ہمارا کوڈ مزید پیچیدہ ہو جائے گا، لہذا اس کے بجائے ہم [OpenZeppelin کا `SafeERC20`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol) استعمال کرتے ہیں، جو یقینی بناتا ہے کہ [تمام ناکامیوں کے نتیجے میں ایک ریورٹ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96) ہو۔ + +```solidity +/** + * @title L1StandardBridge + * @dev L1 ETH اور ERC20 برج ایک کنٹریکٹ ہے جو جمع شدہ L1 فنڈز اور + * L2 پر استعمال ہونے والے معیاری ٹوکنز کو اسٹور کرتا ہے۔ یہ ایک متعلقہ L2 برج کو سنکرونائز کرتا ہے، اسے ڈپازٹ کے بارے میں مطلع کرتا ہے + * اور نئی حتمی واپسیوں کے لیے اسے سنتا ہے۔ + * + */ +contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { + using SafeERC20 for IERC20; +``` + +یہ لائن ہے کہ ہم `IERC20` انٹرفیس استعمال کرتے وقت ہر بار `SafeERC20` ریپر استعمال کرنے کی وضاحت کیسے کرتے ہیں۔ + +```solidity + + /******************************** + * بیرونی کنٹریکٹ کے حوالے * + ********************************/ + + address public l2TokenBridge; +``` + +[L2StandardBridge](#the-l2-bridge-contract) کا ایڈریس۔ + +```solidity + + // L1 ٹوکن کو L2 ٹوکن سے جمع شدہ L1 ٹوکن کے بیلنس پر میپ کرتا ہے + mapping(address => mapping(address => uint256)) public deposits; +``` + +اس طرح کی ایک ڈبل [mapping](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) وہ طریقہ ہے جس سے آپ ایک [دو جہتی اسپارس ارے](https://en.wikipedia.org/wiki/Sparse_matrix) کی تعریف کرتے ہیں۔ +اس ڈیٹا ڈھانچے میں قدروں کی شناخت `deposit[L1 token addr][L2 token addr]` کے طور پر کی جاتی ہے۔ +پہلے سے طے شدہ قدر صفر ہے۔ +صرف وہ سیلز جو ایک مختلف قدر پر سیٹ ہیں اسٹوریج میں لکھے جاتے ہیں۔ + +```solidity + + /*************** + * کنسٹرکٹر * + ***************/ + + // یہ کنٹریکٹ ایک پراکسی کے پیچھے رہتا ہے، لہذا کنسٹرکٹر پیرامیٹرز استعمال نہیں ہوں گے۔ + constructor() CrossDomainEnabled(address(0)) {} +``` + +اسٹوریج میں تمام متغیرات کو کاپی کیے بغیر اس کنٹریکٹ کو اپ گریڈ کرنے کے قابل ہونا چاہتے ہیں۔ +ایسا کرنے کے لیے ہم ایک [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy) کا استعمال کرتے ہیں، ایک کنٹریکٹ جو [`delegatecall`](https://solidity-by-example.org/delegatecall/) کا استعمال کرتا ہے تاکہ کالز کو ایک علیحدہ کنٹریکٹ میں منتقل کیا جا سکے جس کا ایڈریس پراکسی کنٹریکٹ کے ذریعے اسٹور کیا جاتا ہے (جب آپ اپ گریڈ کرتے ہیں تو آپ پراکسی کو اس ایڈریس کو تبدیل کرنے کے لیے کہتے ہیں)۔ +جب آپ `delegatecall` استعمال کرتے ہیں تو اسٹوریج _کالنگ_ کنٹریکٹ کا اسٹوریج رہتا ہے، لہذا تمام کنٹریکٹ اسٹیٹ متغیرات کی قدریں غیر متاثر رہتی ہیں۔ + +اس پیٹرن کا ایک اثر یہ ہے کہ کنٹریکٹ کا اسٹوریج جو `delegatecall` کا _کال کیا گیا_ ہے استعمال نہیں ہوتا ہے اور اس لیے اسے بھیجی گئی کنسٹرکٹر قدریں کوئی معنی نہیں رکھتیں۔ +یہی وجہ ہے کہ ہم `CrossDomainEnabled` کنسٹرکٹر کو ایک بے معنی قدر فراہم کر سکتے ہیں۔ +یہی وجہ ہے کہ نیچے دی گئی شروعات کنسٹرکٹر سے الگ ہے۔ + +```solidity + /****************** + * شروعات * + ******************/ + + /** + * @param _l1messenger کراس چین کمیونیکیشنز کے لیے استعمال ہونے والا L1 میسنجر ایڈریس۔ + * @param _l2TokenBridge L2 معیاری برج ایڈریس۔ + */ + // slither-disable-next-line external-function +``` + +یہ [Slither ٹیسٹ](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external) ان فنکشنز کی نشاندہی کرتا ہے جو کنٹریکٹ کوڈ سے کال نہیں کیے جاتے ہیں اور اس لیے انہیں `public` کے بجائے `external` قرار دیا جا سکتا ہے۔ +`external` فنکشنز کی گیس کی لاگت کم ہو سکتی ہے، کیونکہ انہیں کال ڈیٹا میں پیرامیٹرز فراہم کیے جا سکتے ہیں۔ +`public` قرار دیے گئے فنکشنز کو کنٹریکٹ کے اندر سے قابل رسائی ہونا چاہیے۔ +کنٹریکٹس اپنے کال ڈیٹا میں ترمیم نہیں کر سکتے، لہذا پیرامیٹرز میموری میں ہونے چاہئیں۔ +جب ایسے فنکشن کو بیرونی طور پر کال کیا جاتا ہے، تو کال ڈیٹا کو میموری میں کاپی کرنا ضروری ہوتا ہے، جس میں گیس خرچ ہوتی ہے۔ +اس معاملے میں فنکشن صرف ایک بار کال کیا جاتا ہے، لہذا نااہلی ہمارے لیے کوئی معنی نہیں رکھتی۔ + +```solidity + function initialize(address _l1messenger, address _l2TokenBridge) public { + require(messenger == address(0), "کنٹریکٹ پہلے ہی شروع کیا جا چکا ہے۔"); +``` + +`initialize` فنکشن کو صرف ایک بار کال کیا جانا چاہیے۔ +اگر L1 کراس ڈومین میسنجر یا L2 ٹوکن برج کا ایڈریس تبدیل ہوتا ہے، تو ہم ایک نیا پراکسی اور ایک نیا برج بناتے ہیں جو اسے کال کرتا ہے۔ +یہ ہونے کا امکان نہیں ہے سوائے اس کے کہ جب پورا نظام اپ گریڈ کیا جائے، جو کہ ایک بہت ہی نایاب واقعہ ہے۔ + +نوٹ کریں کہ اس فنکشن میں کوئی ایسا میکانزم نہیں ہے جو اس بات کو محدود کرے کہ اسے _کون_ کال کر سکتا ہے۔ +اس کا مطلب ہے کہ نظریاتی طور پر ایک حملہ آور اس وقت تک انتظار کر سکتا ہے جب تک کہ ہم پراکسی اور برج کا پہلا ورژن تعینات نہ کر دیں اور پھر [front-run](https://solidity-by-example.org/hacks/front-running/) کریں تاکہ جائز صارف سے پہلے `initialize` فنکشن تک پہنچ سکیں۔ لیکن اسے روکنے کے دو طریقے ہیں: + +1. اگر کنٹریکٹس براہ راست EOA کے ذریعے نہیں بلکہ [ایک ٹرانزیکشن میں جس میں دوسرا کنٹریکٹ انہیں بناتا ہے](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595) تعینات کیے گئے ہیں تو پورا عمل ایٹمی ہو سکتا ہے، اور کسی بھی دوسری ٹرانزیکشن کے عملدرآمد سے پہلے ختم ہو سکتا ہے۔ +2. اگر `initialize` کی جائز کال ناکام ہو جاتی ہے تو نئے بنائے گئے پراکسی اور برج کو نظر انداز کرنا اور نئے بنانا ہمیشہ ممکن ہوتا ہے۔ + +```solidity + messenger = _l1messenger; + l2TokenBridge = _l2TokenBridge; + } +``` + +یہ وہ دو پیرامیٹرز ہیں جو برج کو جاننے کی ضرورت ہے۔ + +```solidity + + /************** + * جمع کرنا * + **************/ + + /** @dev موڈیفائر جس میں بھیجنے والے کو EOA ہونا ضروری ہے۔ اس چیک کو ایک بدنیتی پر مبنی + * کنٹریکٹ کے ذریعے initcode کے ذریعے بائی پاس کیا جا سکتا ہے، لیکن یہ اس صارف کی غلطی کا خیال رکھتا ہے جس سے ہم بچنا چاہتے ہیں۔ + */ + modifier onlyEOA() { + // کنٹریکٹس سے ڈپازٹ روکنے کے لیے استعمال کیا جاتا ہے (حادثاتی طور پر کھوئے ہوئے ٹوکن سے بچنے کے لیے) + require(!Address.isContract(msg.sender), "اکاؤنٹ EOA نہیں ہے"); + _; + } +``` + +یہی وجہ ہے کہ ہمیں OpenZeppelin کی `Address` یوٹیلیٹیز کی ضرورت تھی۔ + +```solidity + /** + * @dev اس فنکشن کو بغیر کسی ڈیٹا کے + * L2 پر کالر کے بیلنس میں ETH کی رقم جمع کرنے کے لیے کال کیا جا سکتا ہے۔ + * چونکہ وصول کرنے والا فنکشن ڈیٹا نہیں لیتا، لہذا ایک قدامت پسند + * پہلے سے طے شدہ رقم L2 کو بھیجی جاتی ہے۔ + */ + receive() external payable onlyEOA { + _initiateETHDeposit(msg.sender, msg.sender, 200_000, bytes("")); + } +``` + +یہ فنکشن جانچ کے مقاصد کے لیے موجود ہے۔ +نوٹ کریں کہ یہ انٹرفیس کی تعریفوں میں ظاہر نہیں ہوتا - یہ عام استعمال کے لیے نہیں ہے۔ + +```solidity + /** + * @inheritdoc IL1StandardBridge + */ + function depositETH(uint32 _l2Gas, bytes calldata _data) external payable onlyEOA { + _initiateETHDeposit(msg.sender, msg.sender, _l2Gas, _data); + } + + /** + * @inheritdoc IL1StandardBridge + */ + function depositETHTo( + address _to, + uint32 _l2Gas, + bytes calldata _data + ) external payable { + _initiateETHDeposit(msg.sender, _to, _l2Gas, _data); + } +``` + +یہ دو فنکشنز `_initiateETHDeposit` کے ارد گرد ریپر ہیں، وہ فنکشن جو اصل ETH ڈپازٹ کو ہینڈل کرتا ہے۔ + +```solidity + /** + * @dev ETH کو اسٹور کرکے اور L2 ETH گیٹ وے کو + * ڈپازٹ کے بارے میں مطلع کرکے ڈپازٹ کے لیے منطق انجام دیتا ہے۔ + * @param _from L1 پر ڈپازٹ نکالنے کے لیے اکاؤنٹ۔ + * @param _to L2 پر ڈپازٹ دینے کے لیے اکاؤنٹ۔ + * @param _l2Gas L2 پر ڈپازٹ مکمل کرنے کے لیے درکار گیس کی حد۔ + * @param _data L2 کو فارورڈ کرنے کے لیے اختیاری ڈیٹا۔ یہ ڈیٹا + * صرف بیرونی کنٹریکٹس کی سہولت کے لیے فراہم کیا گیا ہے۔ زیادہ سے زیادہ + * لمبائی نافذ کرنے کے علاوہ، یہ کنٹریکٹس اس کے مواد کے بارے میں کوئی ضمانت نہیں دیتے ہیں۔ + */ + function _initiateETHDeposit( + address _from, + address _to, + uint32 _l2Gas, + bytes memory _data + ) internal { + // finalizeDeposit کال کے لیے کال ڈیٹا تعمیر کریں + bytes memory message = abi.encodeWithSelector( +``` + +کراس ڈومین پیغامات جس طرح کام کرتے ہیں وہ یہ ہے کہ منزل کا کنٹریکٹ پیغام کے ساتھ اس کے کال ڈیٹا کے طور پر کال کیا جاتا ہے۔ +Solidity کنٹریکٹس ہمیشہ اپنے کال ڈیٹا کی تشریح +[ABI وضاحتوں](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html) کے مطابق کرتے ہیں۔ +Solidity فنکشن [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) وہ کال ڈیٹا بناتا ہے۔ + +```solidity + IL2ERC20Bridge.finalizeDeposit.selector, + address(0), + Lib_PredeployAddresses.OVM_ETH, + _from, + _to, + msg.value, + _data + ); +``` + +یہاں پیغام یہ ہے کہ ان پیرامیٹرز کے ساتھ [`finalizeDeposit` فنکشن](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148) کو کال کریں: + +| پیرامیٹر | قدر | مطلب | +| ------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| \_l1Token | address(0) | L1 پر ETH (جو کہ ERC-20 ٹوکن نہیں ہے) کے لیے کھڑے ہونے کی خاص قدر | +| \_l2Token | Lib_PredeployAddresses.OVM_ETH | Optimism پر ETH کا انتظام کرنے والا L2 کنٹریکٹ، `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (یہ کنٹریکٹ صرف اندرونی Optimism استعمال کے لیے ہے) | +| \_from | \_from | L1 پر وہ ایڈریس جو ETH بھیجتا ہے | +| \_to | \_to | L2 پر وہ ایڈریس جو ETH وصول کرتا ہے | +| رقم | msg.value | بھیجے گئے wei کی رقم (جو پہلے ہی برج کو بھیجی جا چکی ہے) | +| \_data | \_data | ڈپازٹ کے ساتھ منسلک کرنے کے لیے اضافی ڈیٹا | + +```solidity + // L2 میں کال ڈیٹا بھیجیں + // slither-disable-next-line reentrancy-events + sendCrossDomainMessage(l2TokenBridge, _l2Gas, message); +``` + +کراس ڈومین میسنجر کے ذریعے پیغام بھیجیں۔ + +```solidity + // slither-disable-next-line reentrancy-events + emit ETHDepositInitiated(_from, _to, msg.value, _data); + } +``` + +اس منتقلی کے بارے میں سننے والی کسی بھی وکندریقرت ایپلیکیشن کو مطلع کرنے کے لیے ایک ایونٹ خارج کریں۔ + +```solidity + /** + * @inheritdoc IL1ERC20Bridge + */ + function depositERC20( + . + . + . + ) external virtual onlyEOA { + _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data); + } + + /** + * @inheritdoc IL1ERC20Bridge + */ + function depositERC20To( + . + . + . + ) external virtual { + _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, _to, _amount, _l2Gas, _data); + } +``` + +یہ دو فنکشنز `_initiateERC20Deposit` کے ارد گرد ریپر ہیں، وہ فنکشن جو اصل ERC-20 ڈپازٹ کو ہینڈل کرتا ہے۔ + +```solidity + /** + * @dev L2 جمع شدہ ٹوکن + * کنٹریکٹ کو ڈپازٹ کے بارے میں مطلع کرکے اور L1 فنڈز کو لاک کرنے کے لیے ایک ہینڈلر کو کال کرکے ڈپازٹ کے لیے منطق انجام دیتا ہے۔ (مثلاً، transferFrom) + * + * @param _l1Token L1 ERC20 کا ایڈریس جسے ہم جمع کر رہے ہیں + * @param _l2Token L1 متعلقہ L2 ERC20 کا ایڈریس + * @param _from L1 پر ڈپازٹ نکالنے کے لیے اکاؤنٹ + * @param _to L2 پر ڈپازٹ دینے کے لیے اکاؤنٹ + * @param _amount جمع کرنے کے لیے ERC20 کی رقم۔ + * @param _l2Gas L2 پر ڈپازٹ مکمل کرنے کے لیے درکار گیس کی حد۔ + * @param _data L2 کو فارورڈ کرنے کے لیے اختیاری ڈیٹا۔ یہ ڈیٹا + * صرف بیرونی کنٹریکٹس کی سہولت کے لیے فراہم کیا گیا ہے۔ زیادہ سے زیادہ + * لمبائی نافذ کرنے کے علاوہ، یہ کنٹریکٹس اس کے مواد کے بارے میں کوئی ضمانت نہیں دیتے ہیں۔ + */ + function _initiateERC20Deposit( + address _l1Token, + address _l2Token, + address _from, + address _to, + uint256 _amount, + uint32 _l2Gas, + bytes calldata _data + ) internal { +``` + +یہ فنکشن اوپر `_initiateETHDeposit` سے ملتا جلتا ہے، چند اہم فرق کے ساتھ۔ +پہلا فرق یہ ہے کہ یہ فنکشن ٹوکن ایڈریس اور منتقل کرنے کی رقم پیرامیٹرز کے طور پر وصول کرتا ہے۔ +ETH کے معاملے میں برج کو کال میں پہلے ہی برج اکاؤنٹ (`msg.value`) میں اثاثے کی منتقلی شامل ہے۔ + +```solidity + // جب L1 پر ڈپازٹ شروع کیا جاتا ہے، تو L1 برج فنڈز کو مستقبل + // کی واپسیوں کے لیے خود کو منتقل کرتا ہے۔ safeTransferFrom یہ بھی چیک کرتا ہے کہ آیا کنٹریکٹ میں کوڈ ہے، لہذا یہ ناکام ہو جائے گا اگر + // _from ایک EOA یا address(0) ہے۔ + // slither-disable-next-line reentrancy-events, reentrancy-benign + IERC20(_l1Token).safeTransferFrom(_from, address(this), _amount); +``` + +ERC-20 ٹوکن کی منتقلی ETH سے ایک مختلف عمل کی پیروی کرتی ہے: + +1. صارف (`_from`) برج کو مناسب ٹوکن منتقل کرنے کی اجازت دیتا ہے۔ +2. صارف برج کو ٹوکن کنٹریکٹ کے ایڈریس، رقم وغیرہ کے ساتھ کال کرتا ہے۔ +3. برج ڈپازٹ کے عمل کے حصے کے طور پر ٹوکن (خود کو) منتقل کرتا ہے۔ + +پہلا قدم آخری دو سے الگ ٹرانزیکشن میں ہو سکتا ہے۔ +تاہم، فرنٹ رننگ کوئی مسئلہ نہیں ہے کیونکہ دو فنکشنز جو `_initiateERC20Deposit` (`depositERC20` اور `depositERC20To`) کو کال کرتے ہیں وہ اس فنکشن کو صرف `msg.sender` کے ساتھ `_from` پیرامیٹر کے طور پر کال کرتے ہیں۔ + +```solidity + // _l2Token.finalizeDeposit(_to, _amount) کے لیے کال ڈیٹا تعمیر کریں + bytes memory message = abi.encodeWithSelector( + IL2ERC20Bridge.finalizeDeposit.selector, + _l1Token, + _l2Token, + _from, + _to, + _amount, + _data + ); + + // L2 میں کال ڈیٹا بھیجیں + // slither-disable-next-line reentrancy-events, reentrancy-benign + sendCrossDomainMessage(l2TokenBridge, _l2Gas, message); + + // slither-disable-next-line reentrancy-benign + deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] + _amount; +``` + +جمع شدہ ٹوکن کی رقم `deposits` ڈیٹا ڈھانچے میں شامل کریں۔ +L2 پر متعدد ایڈریس ہو سکتے ہیں جو ایک ہی L1 ERC-20 ٹوکن کے مطابق ہوں، لہذا ڈپازٹ کا ٹریک رکھنے کے لیے برج کے L1 ERC-20 ٹوکن کے بیلنس کا استعمال کافی نہیں ہے۔ + +```solidity + + // slither-disable-next-line reentrancy-events + emit ERC20DepositInitiated(_l1Token, _l2Token, _from, _to, _amount, _data); + } + + /************************* + * کراس چین فنکشنز * + *************************/ + + /** + * @inheritdoc IL1StandardBridge + */ + function finalizeETHWithdrawal( + address _from, + address _to, + uint256 _amount, + bytes calldata _data +``` + +L2 برج L2 کراس ڈومین میسنجر کو ایک پیغام بھیجتا ہے جس کی وجہ سے L1 کراس ڈومین میسنجر اس فنکشن کو کال کرتا ہے (ایک بار جب [وہ ٹرانزیکشن جو پیغام کو حتمی شکل دیتا ہے](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions) L1 پر جمع ہو جاتا ہے، یقیناً)۔ + +```solidity + ) external onlyFromCrossDomainAccount(l2TokenBridge) { +``` + +یقینی بنائیں کہ یہ ایک _جائز_ پیغام ہے، جو کراس ڈومین میسنجر سے آرہا ہے اور L2 ٹوکن برج سے شروع ہو رہا ہے۔ +یہ فنکشن برج سے ETH نکالنے کے لیے استعمال ہوتا ہے، لہذا ہمیں یہ یقینی بنانا ہوگا کہ اسے صرف مجاز کالر کے ذریعے ہی کال کیا جائے۔ + +```solidity + // slither-disable-next-line reentrancy-events + (bool success, ) = _to.call{ value: _amount }(new bytes(0)); +``` + +ETH منتقل کرنے کا طریقہ یہ ہے کہ وصول کنندہ کو `msg.value` میں wei کی رقم کے ساتھ کال کریں۔ + +```solidity + require(success, "TransferHelper::safeTransferETH: ETH منتقلی ناکام"); + + // slither-disable-next-line reentrancy-events + emit ETHWithdrawalFinalized(_from, _to, _amount, _data); +``` + +واپسی کے بارے میں ایک ایونٹ خارج کریں۔ + +```solidity + } + + /** + * @inheritdoc IL1ERC20Bridge + */ + function finalizeERC20Withdrawal( + address _l1Token, + address _l2Token, + address _from, + address _to, + uint256 _amount, + bytes calldata _data + ) external onlyFromCrossDomainAccount(l2TokenBridge) { +``` + +یہ فنکشن اوپر `finalizeETHWithdrawal` سے ملتا جلتا ہے، ERC-20 ٹوکنز کے لیے ضروری تبدیلیوں کے ساتھ۔ + +```solidity + deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] - _amount; +``` + +`deposits` ڈیٹا ڈھانچے کو اپ ڈیٹ کریں۔ + +```solidity + + // جب L1 پر واپسی کو حتمی شکل دی جاتی ہے، تو L1 برج فنڈز کو واپس لینے والے کو منتقل کرتا ہے + // slither-disable-next-line reentrancy-events + IERC20(_l1Token).safeTransfer(_to, _amount); + + // slither-disable-next-line reentrancy-events + emit ERC20WithdrawalFinalized(_l1Token, _l2Token, _from, _to, _amount, _data); + } + + + /***************************** + * عارضی - ETH کی منتقلی * + *****************************/ + + /** + * @dev اکاؤنٹ میں ETH بیلنس شامل کرتا ہے۔ اس کا مقصد ETH + * کو پرانے گیٹ وے سے نئے گیٹ وے میں منتقل کرنے کی اجازت دینا ہے۔ + * نوٹ: یہ صرف ایک اپ گریڈ کے لیے چھوڑ دیا گیا ہے تاکہ ہم پرانے کنٹریکٹ سے + * منتقل شدہ ETH وصول کر سکیں + */ + function donateETH() external payable {} +} +``` + +برج کا ایک پہلے کا نفاذ تھا۔ +جب ہم نفاذ سے اس کی طرف منتقل ہوئے، تو ہمیں تمام اثاثے منتقل کرنے پڑے۔ +ERC-20 ٹوکن صرف منتقل کیے جا سکتے ہیں۔ +تاہم، ایک کنٹریکٹ میں ETH منتقل کرنے کے لیے آپ کو اس کنٹریکٹ کی منظوری کی ضرورت ہے، جو کہ `donateETH` ہمیں فراہم کرتا ہے۔ + +## L2 پر ERC-20 ٹوکنز {#erc-20-tokens-on-l2} + +ایک ERC-20 ٹوکن کو معیاری برج میں فٹ ہونے کے لیے، اسے معیاری برج، اور _صرف_ معیاری برج کو ٹوکن منٹ کرنے کی اجازت دینی ہوگی۔ +یہ ضروری ہے کیونکہ برجز کو یہ یقینی بنانا ہوگا کہ Optimism پر گردش کرنے والے ٹوکنز کی تعداد L1 برج کنٹریکٹ کے اندر لاک کیے گئے ٹوکنز کی تعداد کے برابر ہو۔ +اگر L2 پر بہت زیادہ ٹوکنز ہیں تو کچھ صارفین اپنے اثاثوں کو L1 پر واپس برج نہیں کر پائیں گے۔ +ایک قابل اعتماد برج کے بجائے، ہم بنیادی طور پر [فرکشنل ریزرو بینکنگ](https://www.investopedia.com/terms/f/fractionalreservebanking.asp) کو دوبارہ بنائیں گے۔ +اگر L1 پر بہت زیادہ ٹوکنز ہیں، تو ان میں سے کچھ ٹوکنز برج کنٹریکٹ کے اندر ہمیشہ کے لیے لاک ہو جائیں گے کیونکہ L2 ٹوکنز کو جلائے بغیر انہیں جاری کرنے کا کوئی طریقہ نہیں ہے۔ + +### IL2StandardERC20 {#il2standarderc20} + +L2 پر ہر ERC-20 ٹوکن جو معیاری برج کا استعمال کرتا ہے اسے [یہ انٹرفیس](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol) فراہم کرنا ہوگا، جس میں وہ فنکشنز اور ایونٹس ہیں جن کی معیاری برج کو ضرورت ہے۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.9; + +import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; +``` + +[معیاری ERC-20 انٹرفیس](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) میں `mint` اور `burn` فنکشنز شامل نہیں ہیں۔ +ان طریقوں کی ضرورت [ERC-20 معیار](https://eips.ethereum.org/EIPS/eip-20) کے ذریعہ نہیں ہے، جو ٹوکن بنانے اور تباہ کرنے کے میکانزم کو غیر متعین چھوڑ دیتا ہے۔ + +```solidity +import { IERC165 } from "@openzeppelin/contracts/utils/introspection/IERC165.sol"; +``` + +[ERC-165 انٹرفیس](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol) اس بات کی وضاحت کے لیے استعمال ہوتا ہے کہ ایک کنٹریکٹ کون سے فنکشنز فراہم کرتا ہے۔ +[آپ معیار یہاں پڑھ سکتے ہیں](https://eips.ethereum.org/EIPS/eip-165)۔ + +```solidity +interface IL2StandardERC20 is IERC20, IERC165 { + function l1Token() external returns (address); +``` + +یہ فنکشن L1 ٹوکن کا ایڈریس فراہم کرتا ہے جو اس کنٹریکٹ سے برجڈ ہے۔ +نوٹ کریں کہ ہمارے پاس مخالف سمت میں اسی طرح کا فنکشن نہیں ہے۔ +ہمیں کسی بھی L1 ٹوکن کو برج کرنے کے قابل ہونے کی ضرورت ہے، چاہے L2 سپورٹ کی منصوبہ بندی کی گئی ہو یا نہیں جب اسے لاگو کیا گیا تھا۔ + +```solidity + + function mint(address _to, uint256 _amount) external; + + function burn(address _from, uint256 _amount) external; + + event Mint(address indexed _account, uint256 _amount); + event Burn(address indexed _account, uint256 _amount); +} +``` + +ٹوکن منٹ (بنانے) اور جلانے (تباہ کرنے) کے لیے فنکشنز اور ایونٹس۔ +برج کو واحد ادارہ ہونا چاہئے جو ان فنکشنز کو چلا سکتا ہے تاکہ یہ یقینی بنایا جا سکے کہ ٹوکنز کی تعداد درست ہے (L1 پر لاک کیے گئے ٹوکنز کی تعداد کے برابر)۔ + +### L2StandardERC20 {#L2StandardERC20} + +[یہ `IL2StandardERC20` انٹرفیس کا ہمارا نفاذ ہے](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol)۔ +جب تک آپ کو کسی قسم کی اپنی مرضی کی منطق کی ضرورت نہ ہو، آپ کو یہ استعمال کرنا چاہیے۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.9; + +import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; +``` + +[OpenZeppelin ERC-20 کنٹریکٹ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)۔ +Optimism پہیے کو دوبارہ ایجاد کرنے میں یقین نہیں رکھتا، خاص طور پر جب پہیہ اچھی طرح سے آڈٹ کیا گیا ہو اور اثاثوں کو رکھنے کے لیے کافی قابل اعتماد ہونے کی ضرورت ہو۔ + +```solidity +import "./IL2StandardERC20.sol"; + +contract L2StandardERC20 is IL2StandardERC20, ERC20 { + address public l1Token; + address public l2Bridge; +``` + +یہ دو اضافی کنفیگریشن پیرامیٹرز ہیں جن کی ہمیں ضرورت ہے اور ERC-20 عام طور پر نہیں کرتا ہے۔ + +```solidity + + /** + * @param _l2Bridge L2 معیاری برج کا ایڈریس۔ + * @param _l1Token متعلقہ L1 ٹوکن کا ایڈریس۔ + * @param _name ERC20 نام۔ + * @param _symbol ERC20 علامت۔ + */ + constructor( + address _l2Bridge, + address _l1Token, + string memory _name, + string memory _symbol + ) ERC20(_name, _symbol) { + l1Token = _l1Token; + l2Bridge = _l2Bridge; + } +``` + +پہلے اس کنٹریکٹ کے لیے کنسٹرکٹر کو کال کریں جس سے ہم وراثت میں ہیں (`ERC20(_name, _symbol)`) اور پھر اپنے متغیرات سیٹ کریں۔ + +```solidity + + modifier onlyL2Bridge() { + require(msg.sender == l2Bridge, "صرف L2 برج منٹ اور برن کر سکتا ہے"); + _; + } + + + // slither-disable-next-line external-function + function supportsInterface(bytes4 _interfaceId) public pure returns (bool) { + bytes4 firstSupportedInterface = bytes4(keccak256("supportsInterface(bytes4)")); // ERC165 + bytes4 secondSupportedInterface = IL2StandardERC20.l1Token.selector ^ + IL2StandardERC20.mint.selector ^ + IL2StandardERC20.burn.selector; + return _interfaceId == firstSupportedInterface || _interfaceId == secondSupportedInterface; + } +``` + +یہ وہ طریقہ ہے جس سے [ERC-165](https://eips.ethereum.org/EIPS/eip-165) کام کرتا ہے۔ +ہر انٹرفیس معاون فنکشنز کی ایک تعداد ہے، اور اس کی شناخت ان فنکشنز کے [ABI فنکشن سلیکٹرز](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) کے [exclusive or](https://en.wikipedia.org/wiki/Exclusive_or) کے طور پر کی جاتی ہے۔ + +L2 برج ERC-165 کو ایک سینیٹی چیک کے طور پر استعمال کرتا ہے تاکہ یہ یقینی بنایا جا سکے کہ جس ERC-20 کنٹریکٹ کو یہ اثاثے بھیجتا ہے وہ `IL2StandardERC20` ہے۔ + +**نوٹ:** `supportsInterface` کو غلط جواب دینے سے بدمعاش کنٹریکٹ کو روکنے کے لیے کچھ بھی نہیں ہے، لہذا یہ ایک سینیٹی چیک میکانزم ہے، _سیکیورٹی میکانزم نہیں_۔ + +```solidity + // slither-disable-next-line external-function + function mint(address _to, uint256 _amount) public virtual onlyL2Bridge { + _mint(_to, _amount); + + emit Mint(_to, _amount); + } + + // slither-disable-next-line external-function + function burn(address _from, uint256 _amount) public virtual onlyL2Bridge { + _burn(_from, _amount); + + emit Burn(_from, _amount); + } +} +``` + +صرف L2 برج کو اثاثے منٹ اور برن کرنے کی اجازت ہے۔ + +_mint`اور`_burn` دراصل [OpenZeppelin ERC-20 کنٹریکٹ](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn) میں بیان کیے گئے ہیں۔ +وہ کنٹریکٹ صرف انہیں بیرونی طور پر ظاہر نہیں کرتا، کیونکہ ٹوکن منٹ اور برن کرنے کی شرائط اتنی ہی متنوع ہیں جتنی ERC-20 استعمال کرنے کے طریقے۔ + +## L2 برج کوڈ {#l2-bridge-code} + +یہ وہ کوڈ ہے جو Optimism پر برج کو چلاتا ہے۔ +[اس کنٹریکٹ کا ماخذ یہاں ہے](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol)۔ + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.9; + +/* انٹرفیس امپورٹس */ +import { IL1StandardBridge } from "../../L1/messaging/IL1StandardBridge.sol"; +import { IL1ERC20Bridge } from "../../L1/messaging/IL1ERC20Bridge.sol"; +import { IL2ERC20Bridge } from "./IL2ERC20Bridge.sol"; +``` + +[IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) انٹرفیس اوپر دیکھے گئے [L1 کے مساوی](#IL1ERC20Bridge) سے بہت ملتا جلتا ہے۔ +دو اہم فرق ہیں: + +1. L1 پر آپ ڈپازٹ شروع کرتے ہیں اور واپسیوں کو حتمی شکل دیتے ہیں۔ + یہاں آپ واپسی شروع کرتے ہیں اور ڈپازٹ کو حتمی شکل دیتے ہیں۔ +2. L1 پر ETH اور ERC-20 ٹوکنز کے درمیان فرق کرنا ضروری ہے۔ + L2 پر ہم دونوں کے لیے ایک ہی فنکشنز استعمال کر سکتے ہیں کیونکہ اندرونی طور پر Optimism پر ETH بیلنس کو ایڈریس [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000) والے ERC-20 ٹوکن کے طور پر ہینڈل کیا جاتا ہے۔ + +```solidity +/* لائبریری امپورٹس */ +import { ERC165Checker } from "@openzeppelin/contracts/utils/introspection/ERC165Checker.sol"; +import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol"; +import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol"; + +/* کنٹریکٹ امپورٹس */ +import { IL2StandardERC20 } from "../../standards/IL2StandardERC20.sol"; + +/** + * @title L2StandardBridge + * @dev L2 معیاری برج ایک کنٹریکٹ ہے جو L1 معیاری برج کے ساتھ مل کر + * L1 اور L2 کے درمیان ETH اور ERC20 منتقلی کو فعال کرتا ہے۔ + * یہ کنٹریکٹ نئے ٹوکنز کے لیے ایک منٹر کے طور پر کام کرتا ہے جب یہ L1 معیاری برج میں ڈپازٹ کے بارے میں سنتا ہے۔ + * یہ کنٹریکٹ واپسی کے لیے مطلوبہ ٹوکنز کے برنر کے طور پر بھی کام کرتا ہے، L1 برج کو L1 فنڈز جاری کرنے کے بارے میں مطلع کرتا ہے۔ + */ +contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { + /******************************** + * بیرونی کنٹریکٹ کے حوالے * + ********************************/ + + address public l1TokenBridge; +``` + +L1 برج کے ایڈریس کا ٹریک رکھیں۔ +نوٹ کریں کہ L1 کے مساوی کے برعکس، یہاں ہمیں اس متغیر کی _ضرورت_ ہے۔ +L1 برج کا ایڈریس پہلے سے معلوم نہیں ہے۔ + +```solidity + + /*************** + * کنسٹرکٹر * + ***************/ + + /** + * @param _l2CrossDomainMessenger اس کنٹریکٹ کے ذریعے استعمال ہونے والا کراس ڈومین میسنجر۔ + * @param _l1TokenBridge مرکزی چین پر تعینات L1 برج کا ایڈریس۔ + */ + constructor(address _l2CrossDomainMessenger, address _l1TokenBridge) + CrossDomainEnabled(_l2CrossDomainMessenger) + { + l1TokenBridge = _l1TokenBridge; + } + + /*************** + * واپسی * + ***************/ + + /** + * @inheritdoc IL2ERC20Bridge + */ + function withdraw( + address _l2Token, + uint256 _amount, + uint32 _l1Gas, + bytes calldata _data + ) external virtual { + _initiateWithdrawal(_l2Token, msg.sender, msg.sender, _amount, _l1Gas, _data); + } + + /** + * @inheritdoc IL2ERC20Bridge + */ + function withdrawTo( + address _l2Token, + address _to, + uint256 _amount, + uint32 _l1Gas, + bytes calldata _data + ) external virtual { + _initiateWithdrawal(_l2Token, msg.sender, _to, _amount, _l1Gas, _data); + } +``` + +یہ دو فنکشنز واپسی شروع کرتے ہیں۔ +نوٹ کریں کہ L1 ٹوکن ایڈریس کی وضاحت کرنے کی کوئی ضرورت نہیں ہے۔ +L2 ٹوکنز سے توقع کی جاتی ہے کہ وہ ہمیں L1 کے مساوی ایڈریس بتائیں گے۔ + +```solidity + + /** + * @dev ٹوکن کو جلا کر اور + * L1 ٹوکن گیٹ وے کو واپسی کے بارے میں مطلع کرکے واپسی کے لیے منطق انجام دیتا ہے۔ + * @param _l2Token L2 ٹوکن کا ایڈریس جہاں سے واپسی شروع کی گئی ہے۔ + * @param _from L2 پر واپسی نکالنے کے لیے اکاؤنٹ۔ + * @param _to L1 پر واپسی دینے کے لیے اکاؤنٹ۔ + * @param _amount واپس لینے کے لیے ٹوکن کی رقم۔ + * @param _l1Gas غیر استعمال شدہ، لیکن ممکنہ فارورڈ مطابقت کے تحفظات کے لیے شامل ہے۔ + * @param _data L1 کو فارورڈ کرنے کے لیے اختیاری ڈیٹا۔ یہ ڈیٹا + * صرف بیرونی کنٹریکٹس کی سہولت کے لیے فراہم کیا گیا ہے۔ زیادہ سے زیادہ + * لمبائی نافذ کرنے کے علاوہ، یہ کنٹریکٹس اس کے مواد کے بارے میں کوئی ضمانت نہیں دیتے ہیں۔ + */ + function _initiateWithdrawal( + address _l2Token, + address _from, + address _to, + uint256 _amount, + uint32 _l1Gas, + bytes calldata _data + ) internal { + // جب واپسی شروع کی جاتی ہے، تو ہم بعد میں L2 + // کے استعمال کو روکنے کے لیے واپس لینے والے کے فنڈز کو جلا دیتے ہیں + // slither-disable-next-line reentrancy-events + IL2StandardERC20(_l2Token).burn(msg.sender, _amount); +``` + +نوٹ کریں کہ ہم `_from` پیرامیٹر پر انحصار نہیں کر رہے ہیں بلکہ `msg.sender` پر کر رہے ہیں جسے جعلی بنانا بہت مشکل ہے (جہاں تک میں جانتا ہوں، ناممکن)۔ + +```solidity + + // l1TokenBridge.finalizeERC20Withdrawal(_to, _amount) کے لیے کال ڈیٹا تعمیر کریں + // slither-disable-next-line reentrancy-events + address l1Token = IL2StandardERC20(_l2Token).l1Token(); + bytes memory message; + + if (_l2Token == Lib_PredeployAddresses.OVM_ETH) { +``` + +L1 پر ETH اور ERC-20 کے درمیان فرق کرنا ضروری ہے۔ + +```solidity + message = abi.encodeWithSelector( + IL1StandardBridge.finalizeETHWithdrawal.selector, + _from, + _to, + _amount, + _data + ); + } else { + message = abi.encodeWithSelector( + IL1ERC20Bridge.finalizeERC20Withdrawal.selector, + l1Token, + _l2Token, + _from, + _to, + _amount, + _data + ); + } + + // L1 برج کو پیغام بھیجیں + // slither-disable-next-line reentrancy-events + sendCrossDomainMessage(l1TokenBridge, _l1Gas, message); + + // slither-disable-next-line reentrancy-events + emit WithdrawalInitiated(l1Token, _l2Token, msg.sender, _to, _amount, _data); + } + + /************************************ + * کراس چین فنکشن: جمع کرنا * + ************************************/ + + /** + * @inheritdoc IL2ERC20Bridge + */ + function finalizeDeposit( + address _l1Token, + address _l2Token, + address _from, + address _to, + uint256 _amount, + bytes calldata _data +``` + +اس فنکشن کو `L1StandardBridge` کے ذریعے کال کیا جاتا ہے۔ + +```solidity + ) external virtual onlyFromCrossDomainAccount(l1TokenBridge) { +``` + +یقینی بنائیں کہ پیغام کا ماخذ جائز ہے۔ +یہ اہم ہے کیونکہ یہ فنکشن `_mint` کو کال کرتا ہے اور اس کا استعمال ایسے ٹوکن دینے کے لیے کیا جا سکتا ہے جو L1 پر برج کے ملکیت والے ٹوکنز کے تحت نہیں آتے ہیں۔ + +```solidity + // چیک کریں کہ ہدف ٹوکن مطابقت رکھتا ہے اور + // تصدیق کریں کہ L1 پر جمع شدہ ٹوکن یہاں L2 جمع شدہ ٹوکن کی نمائندگی سے میل کھاتا ہے + if ( + // slither-disable-next-line reentrancy-events + ERC165Checker.supportsInterface(_l2Token, 0x1d1d8b63) && + _l1Token == IL2StandardERC20(_l2Token).l1Token() +``` + +سینیٹی چیکس: + +1. درست انٹرفیس سپورٹ کیا جاتا ہے +2. L2 ERC-20 کنٹریکٹ کا L1 ایڈریس ٹوکنز کے L1 ماخذ سے میل کھاتا ہے + +```solidity + ) { + // جب ڈپازٹ کو حتمی شکل دی جاتی ہے، تو ہم L2 پر اکاؤنٹ کو اتنی ہی رقم + // کے ٹوکنز کے ساتھ کریڈٹ کرتے ہیں۔ + // slither-disable-next-line reentrancy-events + IL2StandardERC20(_l2Token).mint(_to, _amount); + // slither-disable-next-line reentrancy-events + emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data); +``` + +اگر سینیٹی چیکس پاس ہو جاتے ہیں، تو ڈپازٹ کو حتمی شکل دیں: + +1. ٹوکن منٹ کریں +2. مناسب ایونٹ خارج کریں + +```solidity + } else { + // یا تو L2 ٹوکن جس میں جمع کیا جا رہا ہے، اس کے L1 ٹوکن کے + // درست ایڈریس کے بارے میں اختلاف کرتا ہے، یا درست انٹرفیس کو سپورٹ نہیں کرتا ہے۔ + // یہ صرف اس صورت میں ہونا چاہئے جب کوئی بدنیتی پر مبنی L2 ٹوکن ہو، یا اگر کوئی صارف کسی طرح + // جمع کرنے کے لیے غلط L2 ٹوکن ایڈریس کی وضاحت کرے۔ + // دونوں صورتوں میں، ہم یہاں عمل کو روکتے ہیں اور ایک واپسی کا + // پیغام بناتے ہیں تاکہ صارفین کچھ معاملات میں اپنے فنڈز نکال سکیں۔ + // بدنیتی پر مبنی ٹوکن کنٹریکٹس کو مکمل طور پر روکنے کا کوئی طریقہ نہیں ہے، لیکن یہ + // صارف کی غلطی کو محدود کرتا ہے اور بدنیتی پر مبنی کنٹریکٹ کے رویے کی کچھ شکلوں کو کم کرتا ہے۔ +``` + +اگر کسی صارف نے غلط L2 ٹوکن ایڈریس کا استعمال کرکے قابل شناخت غلطی کی ہے، تو ہم ڈپازٹ کو منسوخ کرنا چاہتے ہیں اور L1 پر ٹوکن واپس کرنا چاہتے ہیں۔ +L2 سے ایسا کرنے کا واحد طریقہ یہ ہے کہ ایک پیغام بھیجا جائے جسے فالٹ چیلنج کی مدت کا انتظار کرنا پڑے گا، لیکن یہ صارف کے لیے ٹوکن کو مستقل طور پر کھونے سے بہت بہتر ہے۔ + +```solidity + bytes memory message = abi.encodeWithSelector( + IL1ERC20Bridge.finalizeERC20Withdrawal.selector, + _l1Token, + _l2Token, + _to, // ڈپازٹ کو بھیجنے والے کو واپس بھیجنے کے لیے یہاں _to اور _from کو تبدیل کیا + _from, + _amount, + _data + ); + + // L1 برج کو پیغام بھیجیں + // slither-disable-next-line reentrancy-events + sendCrossDomainMessage(l1TokenBridge, 0, message); + // slither-disable-next-line reentrancy-events + emit DepositFailed(_l1Token, _l2Token, _from, _to, _amount, _data); + } + } +} +``` + +## نتیجہ {#conclusion} + +معیاری برج اثاثوں کی منتقلی کے لیے سب سے زیادہ لچکدار میکانزم ہے۔ +تاہم، چونکہ یہ بہت عام ہے، اس لیے یہ استعمال کرنے کے لیے ہمیشہ سب سے آسان میکانزم نہیں ہے۔ +خاص طور پر واپسی کے لیے، زیادہ تر صارفین [تھرڈ پارٹی برجز](https://optimism.io/apps#bridge) کا استعمال کرنا پسند کرتے ہیں جو چیلنج کی مدت کا انتظار نہیں کرتے اور واپسی کو حتمی شکل دینے کے لیے Merkle پروف کی ضرورت نہیں ہوتی۔ + +یہ برجز عام طور پر L1 پر اثاثے رکھ کر کام کرتے ہیں، جو وہ فوری طور پر ایک چھوٹی سی فیس کے لیے فراہم کرتے ہیں (اکثر معیاری برج کی واپسی کے لیے گیس کی لاگت سے کم)۔ +جب برج (یا اسے چلانے والے لوگ) L1 اثاثوں کی کمی کا اندازہ لگاتے ہیں تو یہ L2 سے کافی اثاثے منتقل کرتا ہے۔ چونکہ یہ بہت بڑی واپسی ہیں، واپسی کی لاگت ایک بڑی رقم پر تقسیم کی جاتی ہے اور یہ ایک بہت چھوٹا فیصد ہے۔ + +امید ہے کہ اس مضمون نے آپ کو لیئر 2 کے کام کرنے کے طریقے، اور واضح اور محفوظ Solidity کوڈ لکھنے کے بارے میں مزید سمجھنے میں مدد کی ہوگی۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/ur/developers/tutorials/reverse-engineering-a-contract/index.md new file mode 100644 index 00000000000..314b06e852b --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/reverse-engineering-a-contract/index.md @@ -0,0 +1,744 @@ +--- +title: "ایک کنٹریکٹ کی ریورس انجینئرنگ" +description: "جب آپ کے پاس سورس کوڈ نہ ہو تو کنٹریکٹ کو کیسے سمجھیں" +author: Ori Pomerantz +lang: ur-in +tags: [ "evm", "opcodes" ] +skill: advanced +published: 2021-12-30 +--- + +## تعارف {#introduction} + +_بلاک چین پر کوئی راز نہیں ہیں_، جو کچھ بھی ہوتا ہے وہ مستقل، قابل تصدیق، اور عوامی طور پر دستیاب ہے۔ مثالی طور پر، [کنٹریکٹس کا سورس کوڈ Etherscan پر شائع اور تصدیق شدہ ہونا چاہیے](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code)۔ تاہم، [ہمیشہ ایسا نہیں ہوتا](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code)۔ اس مضمون میں آپ بغیر سورس کوڈ والے کنٹریکٹ، [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f) کو دیکھ کر کنٹریکٹس کی ریورس انجینئرنگ کرنا سیکھیں گے۔ + +ریورس کمپائلرز موجود ہیں، لیکن وہ ہمیشہ [قابل استعمال نتائج](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f) نہیں دیتے۔ اس مضمون میں آپ [opcodes](https://github.com/wolflo/evm-opcodes) سے ایک کنٹریکٹ کو دستی طور پر ریورس انجینئر کرنا اور سمجھنا سیکھیں گے، اور ساتھ ہی ایک ڈی کمپائلر کے نتائج کی تشریح کرنا بھی سیکھیں گے۔ + +اس مضمون کو سمجھنے کے لیے آپ کو EVM کی بنیادی باتیں پہلے سے معلوم ہونی چاہئیں، اور EVM اسمبلر سے کم از کم کچھ حد تک واقف ہونا چاہیے۔ [آپ ان موضوعات کے بارے میں یہاں پڑھ سکتے ہیں](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e)۔ + +## قابل عمل کوڈ تیار کریں {#prepare-the-executable-code} + +آپ کنٹریکٹ کے لیے Etherscan پر جا کر، **کنٹریکٹ** ٹیب پر کلک کرکے اور پھر **Switch to Opcodes View** پر کلک کرکے opcodes حاصل کرسکتے ہیں۔ آپ کو ایک ویو ملتا ہے جس میں ہر لائن پر ایک opcode ہوتا ہے۔ + +![Etherscan سے Opcode ویو](opcode-view.png) + +تاہم، جمپس کو سمجھنے کے لیے، آپ کو یہ جاننا ہوگا کہ کوڈ میں ہر opcode کہاں واقع ہے۔ ایسا کرنے کے لیے، ایک طریقہ یہ ہے کہ ایک Google Spreadsheet کھولیں اور کالم C میں opcodes پیسٹ کریں۔ [آپ اس پہلے سے تیار شدہ اسپریڈشیٹ کی ایک کاپی بنا کر درج ذیل مراحل کو چھوڑ سکتے ہیں](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing)۔ + +اگلا مرحلہ کوڈ کے صحیح مقامات حاصل کرنا ہے تاکہ ہم جمپس کو سمجھ سکیں۔ ہم کالم B میں opcode کا سائز، اور کالم A میں مقام (ہیکسا ڈیسیمل میں) رکھیں گے۔ سیل `B1` میں یہ فنکشن ٹائپ کریں اور پھر اسے کوڈ کے آخر تک باقی کالم B کے لیے کاپی اور پیسٹ کریں۔ ایسا کرنے کے بعد آپ کالم B کو چھپا سکتے ہیں۔ + +``` +=1+IF(REGEXMATCH(C1,\"PUSH\"),REGEXEXTRACT(C1,\"PUSH(\\d+)\"),0) +``` + +پہلے یہ فنکشن خود opcode کے لیے ایک بائٹ کا اضافہ کرتا ہے، اور پھر `PUSH` کو تلاش کرتا ہے۔ پش opcodes خاص ہوتے ہیں کیونکہ انہیں پش کی جانے والی ویلیو کے لیے اضافی بائٹس کی ضرورت ہوتی ہے۔ اگر opcode ایک `PUSH` ہے، تو ہم بائٹس کی تعداد نکالتے ہیں اور اسے جوڑ دیتے ہیں۔ + +`A1` میں پہلا آفسیٹ، صفر ڈالیں۔ پھر، `A2` میں، یہ فنکشن ڈالیں اور اسے دوبارہ کالم A کے باقی حصے کے لیے کاپی اور پیسٹ کریں: + +``` +=dec2hex(hex2dec(A1)+B1) +``` + +ہمیں اس فنکشن کی ضرورت ہے تاکہ یہ ہمیں ہیکسا ڈیسیمل ویلیو دے کیونکہ جمپس (`JUMP` اور `JUMPI`) سے پہلے پش کی جانے والی ویلیوز ہمیں ہیکسا ڈیسیمل میں دی جاتی ہیں۔ + +## انٹری پوائنٹ (0x00) {#the-entry-point-0x00} + +کنٹریکٹس ہمیشہ پہلے بائٹ سے ایگزیکیوٹ ہوتے ہیں۔ یہ کوڈ کا ابتدائی حصہ ہے: + +| آفسیٹ | Opcode | اسٹیک (opcode کے بعد) | +| ----: | ------------ | ---------------------------------------------- | +| 0 | PUSH1 0x80 | 0x80 | +| 2 | PUSH1 0x40 | 0x40, 0x80 | +| 4 | MSTORE | خالی | +| 5 | PUSH1 0x04 | 0x04 | +| 7 | CALLDATASIZE | CALLDATASIZE 0x04 | +| 8 | LT | CALLDATASIZE\<4 | +| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 | +| C | JUMPI | خالی | + +یہ کوڈ دو کام کرتا ہے: + +1. 0x80 کو 32 بائٹ ویلیو کے طور پر میموری کے مقامات 0x40-0x5F پر لکھیں (0x80 کو 0x5F میں اسٹور کیا جاتا ہے، اور 0x40-0x5E سب صفر ہیں)۔ +2. calldata کا سائز پڑھیں۔ عام طور پر ایک Ethereum کنٹریکٹ کے لیے کال ڈیٹا [ABI (ایپلیکیشن بائنری انٹرفیس)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html) کی پیروی کرتا ہے، جس کے لیے فنکشن سلیکٹر کے لیے کم از کم چار بائٹس کی ضرورت ہوتی ہے۔ اگر کال ڈیٹا کا سائز چار سے کم ہے، تو 0x5E پر جمپ کریں۔ + +![اس حصے کے لیے فلو چارٹ](flowchart-entry.png) + +### 0x5E پر ہینڈلر (غیر-ABI کال ڈیٹا کے لیے) {#the-handler-at-0x5e-for-non-abi-call-data} + +| آفسیٹ | Opcode | +| ----: | ------------ | +| 5E | JUMPDEST | +| 5F | CALLDATASIZE | +| 60 | PUSH2 0x007c | +| 63 | JUMPI | + +یہ سنیپٹ `JUMPDEST` سے شروع ہوتا ہے۔ EVM (Ethereum ورچوئل مشین) پروگرام ایک استثناء (exception) دیتے ہیں اگر آپ کسی ایسے opcode پر جمپ کرتے ہیں جو `JUMPDEST` نہیں ہے۔ پھر یہ CALLDATASIZE کو دیکھتا ہے، اور اگر یہ "درست" ہے (یعنی، صفر نہیں ہے) تو 0x7C پر جمپ کرتا ہے۔ ہم اس پر نیچے بات کریں گے۔ + +| آفسیٹ | Opcode | اسٹیک (opcode کے بعد) | +| ----: | ---------- | -------------------------------------------------------------------------------------- | +| 64 | CALLVALUE | کال کے ذریعے فراہم کردہ [Wei](/glossary/#wei)۔ Solidity میں `msg.value` کہلاتا ہے۔ | +| 65 | PUSH1 0x06 | 6 CALLVALUE | +| 67 | PUSH1 0x00 | 0 6 CALLVALUE | +| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE | +| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE | +| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE | + +لہذا جب کوئی کال ڈیٹا نہیں ہوتا ہے تو ہم Storage[6] کی ویلیو پڑھتے ہیں۔ ہمیں ابھی تک نہیں معلوم کہ یہ ویلیو کیا ہے، لیکن ہم ان ٹرانزیکشنز کو تلاش کر سکتے ہیں جو کنٹریکٹ نے بغیر کال ڈیٹا کے وصول کی ہیں۔ وہ ٹرانزیکشنز جو بغیر کسی کال ڈیٹا کے صرف ETH ٹرانسفر کرتی ہیں (اور اس لیے کوئی میتھڈ نہیں) Etherscan میں ان کا میتھڈ `Transfer` ہوتا ہے۔ درحقیقت، [کنٹریکٹ کو موصول ہونے والی سب سے پہلی ٹرانزیکشن](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7) ایک ٹرانسفر ہے۔ + +اگر ہم اس ٹرانزیکشن میں دیکھیں اور **Click to see More** پر کلک کریں، تو ہم دیکھتے ہیں کہ کال ڈیٹا، جسے ان پٹ ڈیٹا کہا جاتا ہے، واقعی خالی (`0x`) ہے۔ یہ بھی نوٹ کریں کہ ویلیو 1.559 ETH ہے، جو بعد میں متعلقہ ہوگا۔ + +![کال ڈیٹا خالی ہے](calldata-empty.png) + +اگلا، **اسٹیٹ** ٹیب پر کلک کریں اور جس کنٹریکٹ کی ہم ریورس انجینئرنگ کر رہے ہیں اسے پھیلائیں (0x2510...)۔ آپ دیکھ سکتے ہیں کہ ٹرانزیکشن کے دوران `Storage[6]` تبدیل ہوا، اور اگر آپ Hex کو **نمبر** میں تبدیل کرتے ہیں، تو آپ دیکھتے ہیں کہ یہ 1,559,000,000,000,000,000 ہو گیا، جو wei میں منتقل کی گئی ویلیو ہے (میں نے وضاحت کے لیے کوما شامل کیے ہیں)، اور یہ اگلے کنٹریکٹ کی ویلیو کے مطابق ہے۔ + +![Storage[6] میں تبدیلی](storage6.png) + +اگر ہم اسی مدت کی [دیگر `Transfer` ٹرانزیکشنز](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b866fd5d6a6863db627067167cbf93d84d1#statechange) کی وجہ سے ہونے والی اسٹیٹ تبدیلیوں کو دیکھیں تو ہم دیکھتے ہیں کہ `Storage[6]` نے کچھ وقت کے لیے کنٹریکٹ کی ویلیو کو ٹریک کیا۔ ابھی کے لیے ہم اسے `Value*` کہیں گے۔ ستارے کا نشان (`*`) ہمیں یاد دلاتا ہے کہ ہم ابھی تک نہیں _جانتے_ کہ یہ متغیر کیا کرتا ہے، لیکن یہ صرف کنٹریکٹ کی ویلیو کو ٹریک کرنے کے لیے نہیں ہو سکتا کیونکہ اسٹوریج، جو بہت مہنگا ہے، استعمال کرنے کی کوئی ضرورت نہیں ہے، جب آپ `ADDRESS BALANCE` استعمال کرکے اپنے اکاؤنٹس کا بیلنس حاصل کرسکتے ہیں۔ پہلا opcode کنٹریکٹ کا اپنا ایڈریس پش کرتا ہے۔ دوسرا والا اسٹیک کے اوپری حصے میں موجود ایڈریس کو پڑھتا ہے اور اسے اس ایڈریس کے بیلنس سے بدل دیتا ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------- | +| 6C | PUSH2 0x0075 | 0x75 Value\* CALLVALUE 0 6 CALLVALUE | +| 6F | SWAP2 | CALLVALUE Value\* 0x75 0 6 CALLVALUE | +| 70 | SWAP1 | Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 71 | PUSH2 0x01a7 | 0x01A7 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 74 | JUMP | | + +ہم اس کوڈ کو جمپ ڈیسٹینیشن پر ٹریس کرنا جاری رکھیں گے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------- | ----------------------------------------------------------- | +| 1A7 | JUMPDEST | Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1A8 | PUSH1 0x00 | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AA | DUP3 | CALLVALUE 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | + +`NOT` بٹ وائز ہے، لہذا یہ کال ویلیو میں ہر بٹ کی ویلیو کو الٹ دیتا ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------------------------------------------------------------------ | +| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1B2 | JUMPI | | + +ہم جمپ کرتے ہیں اگر `Value*`، 2^256-CALLVALUE-1 سے چھوٹا یا اس کے برابر ہو۔ یہ اوور فلو کو روکنے کی منطق کی طرح لگتا ہے۔ اور درحقیقت، ہم دیکھتے ہیں کہ کچھ بے معنی آپریشنز کے بعد (میموری میں لکھنا حذف ہونے والا ہے، مثال کے طور پر) آفسیٹ 0x01DE پر کنٹریکٹ ریورٹ ہوجاتا ہے اگر اوور فلو کا پتہ چلتا ہے، جو کہ عام رویہ ہے۔ + +نوٹ کریں کہ اس طرح کا اوور فلو انتہائی غیر متوقع ہے، کیونکہ اس کے لیے کال ویلیو اور `Value*` کا موازنہ 2^256 wei، تقریباً 10^59 ETH سے کرنا ہوگا۔ [لکھنے کے وقت، کل ETH سپلائی دو سو ملین سے کم ہے](https://etherscan.io/stat/supply)۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | -------- | ----------------------------------------- | +| 1DF | JUMPDEST | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1E0 | POP | Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1E1 | ADD | Value\*+CALLVALUE 0x75 0 6 CALLVALUE | +| 1E2 | SWAP1 | 0x75 Value\*+CALLVALUE 0 6 CALLVALUE | +| 1E3 | JUMP | | + +اگر ہم یہاں پہنچ گئے تو، `Value* + CALLVALUE` حاصل کریں اور آفسیٹ 0x75 پر جمپ کریں۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | -------- | ------------------------------- | +| 75 | JUMPDEST | Value\*+CALLVALUE 0 6 CALLVALUE | +| 76 | SWAP1 | 0 Value\*+CALLVALUE 6 CALLVALUE | +| 77 | SWAP2 | 6 Value\*+CALLVALUE 0 CALLVALUE | +| 78 | SSTORE | 0 CALLVALUE | + +اگر ہم یہاں پہنچتے ہیں (جس کے لیے کال ڈیٹا کا خالی ہونا ضروری ہے) تو ہم `Value*` میں کال ویلیو کا اضافہ کرتے ہیں۔ یہ اس کے مطابق ہے جو ہم کہتے ہیں کہ `Transfer` ٹرانزیکشنز کرتی ہیں۔ + +| آفسیٹ | Opcode | +| ----: | ------ | +| 79 | POP | +| 7A | POP | +| 7B | STOP | + +آخر میں، اسٹیک کو صاف کریں (جو ضروری نہیں ہے) اور ٹرانزیکشن کے کامیاب اختتام کا اشارہ دیں۔ + +اس سب کا خلاصہ کرنے کے لیے، یہاں ابتدائی کوڈ کے لیے ایک فلو چارٹ ہے۔ + +![انٹری پوائنٹ فلو چارٹ](flowchart-entry.png) + +## 0x7C پر ہینڈلر {#the-handler-at-0x7c} + +میں نے جان بوجھ کر ہیڈنگ میں یہ نہیں بتایا کہ یہ ہینڈلر کیا کرتا ہے۔ مقصد آپ کو یہ سکھانا نہیں ہے کہ یہ مخصوص کنٹریکٹ کیسے کام کرتا ہے، بلکہ یہ سکھانا ہے کہ کنٹریکٹس کو کیسے ریورس انجینئر کیا جائے۔ آپ اسی طرح سیکھیں گے جیسے میں نے کوڈ کی پیروی کرکے سیکھا تھا۔ + +ہم یہاں کئی جگہوں سے آتے ہیں: + +- اگر 1، 2، یا 3 بائٹس کا کال ڈیٹا ہے (آفسیٹ 0x63 سے) +- اگر میتھڈ سگنیچر نامعلوم ہے (آفسیٹس 0x42 اور 0x5D سے) + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------------------------------------ | +| 7C | JUMPDEST | | +| 7D | PUSH1 0x00 | 0x00 | +| 7F | PUSH2 0x009d | 0x9D 0x00 | +| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 | +| 84 | SLOAD | Storage[3] 0x9D 0x00 | + +یہ ایک اور اسٹوریج سیل ہے، جسے میں کسی بھی ٹرانزیکشن میں نہیں ڈھونڈ سکا لہذا یہ جاننا مشکل ہے کہ اس کا کیا مطلب ہے۔ نیچے دیا گیا کوڈ اسے مزید واضح کر دے گا۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | +| 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 | +| 9A | AND | Storage[3]-بطور-ایڈریس 0x9D 0x00 | + +یہ opcodes اس ویلیو کو جو ہم Storage[3] سے پڑھتے ہیں، اسے 160 بٹس تک چھوٹا کر دیتے ہیں، جو کہ ایک Ethereum ایڈریس کی لمبائی ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------ | ------------------------------------------------------------------------------------ | +| 9B | SWAP1 | 0x9D Storage[3]-بطور-ایڈریس 0x00 | +| 9C | JUMP | Storage[3]-بطور-ایڈریس 0x00 | + +یہ جمپ فالتو ہے، کیونکہ ہم اگلے opcode پر جا رہے ہیں۔ یہ کوڈ اتنا گیس-ایفیشنٹ نہیں ہے جتنا ہو سکتا تھا۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------- | +| 9D | JUMPDEST | Storage[3]-بطور-ایڈریس 0x00 | +| 9E | SWAP1 | 0x00 Storage[3]-بطور-ایڈریس | +| 9F | POP | Storage[3]-بطور-ایڈریس | +| A0 | PUSH1 0x40 | 0x40 Storage[3]-بطور-ایڈریس | +| A2 | MLOAD | Mem[0x40] Storage[3]-بطور-ایڈریس | + +کوڈ کے بالکل شروع میں ہم نے Mem[0x40] کو 0x80 پر سیٹ کیا تھا۔ اگر ہم بعد میں 0x40 کو تلاش کریں تو ہم دیکھتے ہیں کہ ہم اسے تبدیل نہیں کرتے ہیں - لہذا ہم فرض کر سکتے ہیں کہ یہ 0x80 ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------------------------------------------------------------------ | +| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-بطور-ایڈریس | +| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-بطور-ایڈریس | +| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-بطور-ایڈریس | +| A7 | CALLDATACOPY | 0x80 Storage[3]-بطور-ایڈریس | + +تمام کال ڈیٹا کو میموری میں کاپی کریں، 0x80 سے شروع کرتے ہوئے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-بطور-ایڈریس | +| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-بطور-ایڈریس | +| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-بطور-ایڈریس | +| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-بطور-ایڈریس | +| AD | DUP6 | Storage[3]-بطور-ایڈریس 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-بطور-ایڈریس | +| AE | GAS | GAS Storage[3]-بطور-ایڈریس 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-بطور-ایڈریس | +| AF | DELEGATE_CALL | | + +اب چیزیں بہت واضح ہو گئی ہیں۔ یہ کنٹریکٹ ایک [پراکسی](https://blog.openzeppelin.com/proxy-patterns/) کے طور پر کام کر سکتا ہے، جو اصل کام کرنے کے لیے Storage[3] میں موجود ایڈریس کو کال کرتا ہے۔ `DELEGATE_CALL` ایک الگ کنٹریکٹ کو کال کرتا ہے، لیکن اسی اسٹوریج میں رہتا ہے۔ اس کا مطلب یہ ہے کہ ڈیلیگیٹڈ کنٹریکٹ، جس کے لیے ہم ایک پراکسی ہیں، اسی اسٹوریج اسپیس تک رسائی حاصل کرتا ہے۔ کال کے پیرامیٹرز یہ ہیں: + +- _گیس_: باقی تمام گیس +- _کال کیا گیا ایڈریس_: Storage[3]-بطور-ایڈریس +- _کال ڈیٹا_: CALLDATASIZE بائٹس 0x80 سے شروع ہوتی ہیں، جہاں ہم نے اصل کال ڈیٹا ڈالا تھا +- _ریٹرن ڈیٹا_: کوئی نہیں (0x00 - 0x00) ہم ریٹرن ڈیٹا دوسرے طریقوں سے حاصل کریں گے (نیچے دیکھیں) + +| آفسیٹ | Opcode | اسٹیک | +| ----: | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| B0 | RETURNDATASIZE | RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B5 | RETURNDATACOPY | RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | + +یہاں ہم تمام ریٹرن ڈیٹا کو 0x80 سے شروع ہونے والے میموری بفر میں کاپی کرتے ہیں۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| B6 | DUP2 | (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B7 | DUP1 | (((کال کی کامیابی/ناکامی))) (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B8 | ISZERO | (((کیا کال ناکام ہوئی))) (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| B9 | PUSH2 0x00c0 | 0xC0 (((کیا کال ناکام ہوئی))) (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| BC | JUMPI | (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| BD | DUP2 | RETURNDATASIZE (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| BE | DUP5 | 0x80 RETURNDATASIZE (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| BF | RETURN | | + +لہذا کال کے بعد ہم ریٹرن ڈیٹا کو بفر 0x80 - 0x80+RETURNDATASIZE میں کاپی کرتے ہیں، اور اگر کال کامیاب ہوتی ہے تو ہم بالکل اسی بفر کے ساتھ `RETURN` کرتے ہیں۔ + +### DELEGATECALL ناکام {#delegatecall-failed} + +اگر ہم یہاں، 0xC0 پر پہنچتے ہیں، تو اس کا مطلب ہے کہ ہم نے جس کنٹریکٹ کو کال کیا تھا وہ ریورٹ ہو گیا ہے۔ چونکہ ہم اس کنٹریکٹ کے لیے صرف ایک پراکسی ہیں، ہم وہی ڈیٹا واپس کرنا چاہتے ہیں اور ریورٹ بھی کرنا چاہتے ہیں۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| C0 | JUMPDEST | (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| C1 | DUP2 | RETURNDATASIZE (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| C2 | DUP5 | 0x80 RETURNDATASIZE (((کال کی کامیابی/ناکامی))) RETURNDATASIZE (((کال کی کامیابی/ناکامی))) 0x80 Storage[3]-بطور-ایڈریس | +| C3 | REVERT | | + +لہذا ہم اسی بفر کے ساتھ `REVERT` کرتے ہیں جو ہم نے پہلے `RETURN` کے لیے استعمال کیا تھا: 0x80 - 0x80+RETURNDATASIZE + +![پراکسی پر کال کرنے کا فلو چارٹ](flowchart-proxy.png) + +## ABI کالز {#abi-calls} + +اگر کال ڈیٹا کا سائز چار بائٹس یا اس سے زیادہ ہے تو یہ ایک درست ABI کال ہو سکتی ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | --------------------------------------------------------------------------------------------------------------------- | +| D | PUSH1 0x00 | 0x00 | +| F | CALLDATALOAD | (((کال ڈیٹا کا پہلا لفظ (256 بٹس)))) | +| 10 | PUSH1 0xe0 | 0xE0 (((کال ڈیٹا کا پہلا لفظ (256 بٹس)))) | +| 12 | SHR | (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس)))) | + +Etherscan ہمیں بتاتا ہے کہ `1C` ایک نامعلوم opcode ہے، کیونکہ [اسے Etherscan کے اس فیچر کو لکھنے کے بعد شامل کیا گیا تھا](https://eips.ethereum.org/EIPS/eip-145) اور انہوں نے اسے اپ ڈیٹ نہیں کیا ہے۔ ایک [اپ ٹو ڈیٹ opcode ٹیبل](https://github.com/wolflo/evm-opcodes) ہمیں دکھاتا ہے کہ یہ شفٹ رائٹ ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 13 | DUP1 | (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس))) (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس)))) | +| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس))) (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس)))) | +| 19 | GT | 0x3CD8045E>کال-ڈیٹا-کے-پہلے-32-بٹس (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس)))) | +| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>کال-ڈیٹا-کے-پہلے-32-بٹس (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس)))) | +| 1D | JUMPI | (((کال ڈیٹا کے پہلے 32 بٹس (4 بائٹس)))) | + +اس طرح میتھڈ سگنیچر میچنگ ٹیسٹس کو دو حصوں میں تقسیم کرنے سے اوسطاً آدھے ٹیسٹ بچ جاتے ہیں۔ اس کے فوراً بعد آنے والا کوڈ اور 0x43 میں موجود کوڈ ایک ہی پیٹرن کی پیروی کرتا ہے: کال ڈیٹا کے پہلے 32 بٹس کو `DUP1` کریں، `PUSH4 (((میتھڈ سگنیچر))`، برابری کی جانچ کے لیے `EQ` چلائیں، اور پھر اگر میتھڈ سگنیچر میچ کرتا ہے تو `JUMPI` کریں۔ یہاں میتھڈ سگنیچرز، ان کے ایڈریسز، اور اگر معلوم ہو تو [متعلقہ میتھڈ ڈیفینیشن](https://www.4byte.directory/) ہیں: + +| میتھڈ | میتھڈ سگنیچر | جمپ کرنے کے لیے آفسیٹ | +| --------------------------------------------------------------------------------------------------------- | ------------ | --------------------- | +| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 | +| ؟؟؟ | 0x81e580d3 | 0x0138 | +| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 | +| ؟؟؟ | 0x1f135823 | 0x00C4 | +| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED | + +اگر کوئی میچ نہیں ملتا ہے، تو کوڈ [پراکسی ہینڈلر پر 0x7C](#the-handler-at-0x7c) پر جمپ کرتا ہے، اس امید پر کہ جس کنٹریکٹ کے لیے ہم پراکسی ہیں اس کا کوئی میچ ہوگا۔ + +![ABI کالز فلو چارٹ](flowchart-abi.png) + +## splitter() {#splitter} + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ----------------------------- | +| 103 | JUMPDEST | | +| 104 | CALLVALUE | CALLVALUE | +| 105 | DUP1 | CALLVALUE CALLVALUE | +| 106 | ISZERO | CALLVALUE==0 CALLVALUE | +| 107 | PUSH2 0x010f | 0x010F CALLVALUE==0 CALLVALUE | +| 10A | JUMPI | CALLVALUE | +| 10B | PUSH1 0x00 | 0x00 CALLVALUE | +| 10D | DUP1 | 0x00 0x00 CALLVALUE | +| 10E | REVERT | | + +یہ فنکشن سب سے پہلے یہ چیک کرتا ہے کہ کال نے کوئی ETH نہیں بھیجا ہے۔ یہ فنکشن [`payable`](https://solidity-by-example.org/payable/) نہیں ہے۔ اگر کسی نے ہمیں ETH بھیجا ہے تو یہ ایک غلطی ہونی چاہیے اور ہم `REVERT` کرنا چاہتے ہیں تاکہ اس ETH کو ایسی جگہ رکھنے سے بچا جا سکے جہاں وہ اسے واپس نہ لے سکیں۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 10F | JUMPDEST | | +| 110 | POP | | +| 111 | PUSH1 0x03 | 0x03 | +| 113 | SLOAD | (((Storage[3] یعنی وہ کنٹریکٹ جس کے لیے ہم پراکسی ہیں))) | +| 114 | PUSH1 0x40 | 0x40 (((Storage[3] یعنی وہ کنٹریکٹ جس کے لیے ہم پراکسی ہیں))) | +| 116 | MLOAD | 0x80 (((Storage[3] یعنی وہ کنٹریکٹ جس کے لیے ہم پراکسی ہیں))) | +| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] یعنی وہ کنٹریکٹ جس کے لیے ہم پراکسی ہیں))) | +| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] یعنی وہ کنٹریکٹ جس کے لیے ہم پراکسی ہیں))) | +| 12D | SWAP2 | (((Storage[3] یعنی وہ کنٹریکٹ جس کے لیے ہم پراکسی ہیں))) 0xFF...FF 0x80 | +| 12E | AND | پراکسی ایڈریس 0x80 | +| 12F | DUP2 | 0x80 پراکسی ایڈریس 0x80 | +| 130 | MSTORE | 0x80 | + +اور 0x80 میں اب پراکسی ایڈریس موجود ہے + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | --------- | +| 131 | PUSH1 0x20 | 0x20 0x80 | +| 133 | ADD | 0xA0 | +| 134 | PUSH2 0x00e4 | 0xE4 0xA0 | +| 137 | JUMP | 0xA0 | + +### E4 کوڈ {#the-e4-code} + +یہ پہلی بار ہے جب ہم یہ لائنیں دیکھ رہے ہیں، لیکن یہ دیگر میتھڈز کے ساتھ بھی شیئر کی گئی ہیں (نیچے دیکھیں)۔ لہذا ہم اسٹیک میں موجود ویلیو کو X کہیں گے، اور بس یاد رکھیں گے کہ `splitter()` میں اس X کی ویلیو 0xA0 ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------- | ----------- | +| E4 | JUMPDEST | X | +| E5 | PUSH1 0x40 | 0x40 X | +| E7 | MLOAD | 0x80 X | +| E8 | DUP1 | 0x80 0x80 X | +| E9 | SWAP2 | X 0x80 0x80 | +| EA | SUB | X-0x80 0x80 | +| EB | SWAP1 | 0x80 X-0x80 | +| EC | RETURN | | + +لہذا یہ کوڈ اسٹیک میں ایک میموری پوائنٹر (X) وصول کرتا ہے، اور کنٹریکٹ کو ایک ایسے بفر کے ساتھ `RETURN` کرنے کا سبب بنتا ہے جو 0x80 - X ہے۔ + +`splitter()` کے معاملے میں، یہ وہ ایڈریس واپس کرتا ہے جس کے لیے ہم پراکسی ہیں۔ `RETURN` بفر کو 0x80-0x9F میں واپس کرتا ہے، جو وہ جگہ ہے جہاں ہم نے یہ ڈیٹا لکھا تھا (اوپر آفسیٹ 0x130)۔ + +## currentWindow() {#currentwindow} + +آفسیٹس 0x158-0x163 میں موجود کوڈ اس سے مماثل ہے جو ہم نے `splitter()` میں 0x103-0x10E میں دیکھا تھا (`JUMPI` کی منزل کے علاوہ)، لہذا ہم جانتے ہیں کہ `currentWindow()` بھی `payable` نہیں ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------------------------------------ | +| 164 | JUMPDEST | | +| 165 | POP | | +| 166 | PUSH2 0x00da | 0xDA | +| 169 | PUSH1 0x01 | 0x01 0xDA | +| 16B | SLOAD | Storage[1] 0xDA | +| 16C | DUP2 | 0xDA Storage[1] 0xDA | +| 16D | JUMP | Storage[1] 0xDA | + +### DA کوڈ {#the-da-code} + +یہ کوڈ دیگر میتھڈز کے ساتھ بھی شیئر کیا گیا ہے۔ لہذا ہم اسٹیک میں موجود ویلیو کو Y کہیں گے، اور بس یاد رکھیں گے کہ `currentWindow()` میں اس Y کی ویلیو Storage[1] ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------- | ---------------- | +| DA | JUMPDEST | Y 0xDA | +| DB | PUSH1 0x40 | 0x40 Y 0xDA | +| DD | MLOAD | 0x80 Y 0xDA | +| DE | SWAP1 | Y 0x80 0xDA | +| DF | DUP2 | 0x80 Y 0x80 0xDA | +| E0 | MSTORE | 0x80 0xDA | + +Y کو 0x80-0x9F پر لکھیں۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ---------- | -------------- | +| E1 | PUSH1 0x20 | 0x20 0x80 0xDA | +| E3 | ADD | 0xA0 0xDA | + +اور باقی کی وضاحت [اوپر](#the-e4-code) پہلے ہی کی جا چکی ہے۔ لہذا 0xDA پر جمپ اسٹیک ٹاپ (Y) کو 0x80-0x9F پر لکھتے ہیں، اور اس ویلیو کو واپس کرتے ہیں۔ `currentWindow()` کے معاملے میں، یہ Storage[1] واپس کرتا ہے۔ + +## merkleRoot() {#merkleroot} + +آفسیٹس 0xED-0xF8 میں موجود کوڈ اس سے مماثل ہے جو ہم نے `splitter()` میں 0x103-0x10E میں دیکھا تھا (`JUMPI` کی منزل کے علاوہ)، لہذا ہم جانتے ہیں کہ `merkleRoot()` بھی `payable` نہیں ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------------------------------------ | +| F9 | JUMPDEST | | +| FA | POP | | +| FB | PUSH2 0x00da | 0xDA | +| FE | PUSH1 0x00 | 0x00 0xDA | +| 100 | SLOAD | Storage[0] 0xDA | +| 101 | DUP2 | 0xDA Storage[0] 0xDA | +| 102 | JUMP | Storage[0] 0xDA | + +جمپ کے بعد کیا ہوتا ہے [یہ ہم پہلے ہی معلوم کر چکے ہیں](#the-da-code)۔ لہذا `merkleRoot()`، Storage[0] واپس کرتا ہے۔ + +## 0x81e580d3 {#0x81e580d3} + +آفسیٹس 0x138-0x143 میں موجود کوڈ اس سے مماثل ہے جو ہم نے `splitter()` میں 0x103-0x10E میں دیکھا تھا (`JUMPI` کی منزل کے علاوہ)، لہذا ہم جانتے ہیں کہ یہ فنکشن بھی `payable` نہیں ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ------------------------------------------------------------------------------- | +| 144 | JUMPDEST | | +| 145 | POP | | +| 146 | PUSH2 0x00da | 0xDA | +| 149 | PUSH2 0x0153 | 0x0153 0xDA | +| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA | +| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA | +| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA | +| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA | +| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA | +| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | + +ایسا لگتا ہے کہ یہ فنکشن کم از کم 32 بائٹس (ایک لفظ) کال ڈیٹا لیتا ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------ | -------------------------------------------- | +| 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 19F | REVERT | | + +اگر اسے کال ڈیٹا نہیں ملتا ہے تو ٹرانزیکشن بغیر کسی ریٹرن ڈیٹا کے ریورٹ ہو جاتی ہے۔ + +آئیے دیکھتے ہیں کہ اگر فنکشن کو _واقعی_ وہ کال ڈیٹا ملتا ہے جس کی اسے ضرورت ہے۔ + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | ----------------------------------------------------------- | +| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA | +| 1A2 | CALLDATALOAD | calldataload(4) CALLDATASIZE 0x0153 0xDA | + +`calldataload(4)` میتھڈ سگنیچر کے _بعد_ کال ڈیٹا کا پہلا لفظ ہے + +| آفسیٹ | Opcode | اسٹیک | +| ----: | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA | +| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA | +| 1A5 | POP | 0x0153 calldataload(4) 0xDA | +| 1A6 | JUMP | calldataload(4) 0xDA | +| 153 | JUMPDEST | calldataload(4) 0xDA | +| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA | +| 157 | JUMP | calldataload(4) 0xDA | +| 16E | JUMPDEST | calldataload(4) 0xDA | +| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA | +| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA | +| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA | +| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | +| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | +| 175 | LT | calldataload(4)\)` ہے، اور دوسرا `isClaimed()` ہے، لہذا یہ ایک ایئر ڈراپ کنٹریکٹ کی طرح لگتا ہے۔ باقی کو opcode-به-opcode دیکھنے کے بجائے، ہم [ڈی کمپائلر کو آزما سکتے ہیں](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761)، جو اس کنٹریکٹ سے تین فنکشنز کے لیے قابل استعمال نتائج دیتا ہے۔ باقی کی ریورس انجینئرنگ قارئین کے لیے ایک مشق کے طور پر چھوڑی گئی ہے۔ + +### scaleAmountByPercentage {#scaleamountbypercentage} + +یہ وہ ہے جو ڈی کمپائلر ہمیں اس فنکشن کے لیے دیتا ہے: + +```python +def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable: + require calldata.size - 4 >=′ 64 + if _param1 and _param2 > -1 / _param1: + revert with 0, 17 + return (_param1 * _param2 / 100 * 10^6) +``` + +پہلا `require` یہ جانچتا ہے کہ کال ڈیٹا میں، فنکشن سگنیچر کے چار بائٹس کے علاوہ، کم از کم 64 بائٹس ہیں، جو دو پیرامیٹرز کے لیے کافی ہیں۔ اگر نہیں تو ظاہر ہے کچھ گڑبڑ ہے۔ + +`if` اسٹیٹمنٹ یہ چیک کرتا ہے کہ `_param1` صفر نہیں ہے، اور یہ کہ `_param1 * _param2` منفی نہیں ہے۔ یہ شاید ریپ اراؤنڈ کے کیسز کو روکنے کے لیے ہے۔ + +آخر میں، فنکشن ایک اسکیلڈ ویلیو واپس کرتا ہے۔ + +### claim {#claim} + +جو کوڈ ڈی کمپائلر بناتا ہے وہ پیچیدہ ہے، اور اس کا سارا حصہ ہمارے لیے متعلقہ نہیں ہے۔ میں اس کے کچھ حصوں کو چھوڑنے جا رہا ہوں تاکہ ان لائنوں پر توجہ مرکوز کی جا سکے جو میرے خیال میں مفید معلومات فراہم کرتی ہیں۔ + +```python +def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable: + ... + require _param2 == addr(_param2) + ... + if currentWindow <= _param1: + revert with 0, 'cannot claim for a future window' +``` + +ہم یہاں دو اہم چیزیں دیکھتے ہیں: + +- `_param2`، اگرچہ اسے `uint256` کے طور پر ڈکلیئر کیا گیا ہے، دراصل ایک ایڈریس ہے +- `_param1` وہ ونڈو ہے جس کا دعوی کیا جا رہا ہے، جو `currentWindow` یا اس سے پہلے کی ہونی چاہیے۔ + +```python + ... + if stor5[_claimWindow][addr(_claimFor)]: + revert with 0, 'Account already claimed the given window' +``` + +تو اب ہم جانتے ہیں کہ Storage[5] ونڈوز اور ایڈریسز کا ایک ایرے ہے، اور یہ کہ کیا ایڈریس نے اس ونڈو کے لیے انعام کا دعوی کیا ہے۔ + +```python + ... + idx = 0 + s = 0 + while idx < _param4.length: + ... + if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]: + mem[mem[64] + 32] = mem[(32 * idx) + 296] + ... + s = sha3(mem[_62 + 32 len mem[_62]]) + continue + ... + s = sha3(mem[_66 + 32 len mem[_66]]) + continue + if unknown2eb4a7ab != s: + revert with 0, 'Invalid proof' +``` + +ہم جانتے ہیں کہ `unknown2eb4a7ab` دراصل فنکشن `merkleRoot()` ہے، لہذا یہ کوڈ ایسا لگتا ہے جیسے یہ ایک [merkle proof](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5) کی تصدیق کر رہا ہے۔ اس کا مطلب یہ ہے کہ `_param4` ایک merkle proof ہے۔ + +```python + call addr(_param2) with: + value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei + gas 30000 wei +``` + +یہ وہ طریقہ ہے جس سے ایک کنٹریکٹ اپنے ETH کو دوسرے ایڈریس (کنٹریکٹ یا بیرونی ملکیت والے) میں منتقل کرتا ہے۔ یہ اسے ایک ایسی ویلیو کے ساتھ کال کرتا ہے جو منتقل کی جانے والی رقم ہے۔ تو ایسا لگتا ہے کہ یہ ETH کا ایک ایئر ڈراپ ہے۔ + +```python + if not return_data.size: + if not ext_call.success: + require ext_code.size(stor2) + call stor2.deposit() with: + value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei +``` + +نچلی دو لائنیں ہمیں بتاتی ہیں کہ Storage[2] بھی ایک کنٹریکٹ ہے جسے ہم کال کرتے ہیں۔ اگر ہم [کنسٹرکٹر ٹرانزیکشن کو دیکھیں](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange) تو ہم دیکھتے ہیں کہ یہ کنٹریکٹ [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) ہے، جو ایک Wrapped Ether کنٹریکٹ ہے [جس کا سورس کوڈ Etherscan پر اپ لوڈ کیا گیا ہے](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code)۔ + +تو ایسا لگتا ہے کہ کنٹریکٹس `_param2` کو ETH بھیجنے کی کوشش کرتے ہیں۔ اگر یہ کر سکتا ہے تو بہت اچھا۔ اگر نہیں، تو یہ [WETH](https://weth.tkn.eth.limo/) بھیجنے کی کوشش کرتا ہے۔ اگر `_param2` ایک بیرونی ملکیت والا اکاؤنٹ (EOA) ہے تو یہ ہمیشہ ETH وصول کر سکتا ہے، لیکن کنٹریکٹس ETH وصول کرنے سے انکار کر سکتے ہیں۔ تاہم، WETH ایک ERC-20 ہے اور کنٹریکٹس اسے قبول کرنے سے انکار نہیں کر سکتے۔ + +```python + ... + log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success) +``` + +فنکشن کے آخر میں ہم دیکھتے ہیں کہ ایک لاگ انٹری تیار کی جا رہی ہے۔ [تیار کردہ لاگ انٹریز کو دیکھیں](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) اور اس موضوع پر فلٹر کریں جو `0xdbd5...` سے شروع ہوتا ہے۔ اگر ہم [ان ٹرانزیکشنز میں سے کسی ایک پر کلک کرتے ہیں جس نے ایسی انٹری تیار کی ہے](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274) تو ہم دیکھتے ہیں کہ واقعی یہ ایک دعوے کی طرح لگتا ہے - اکاؤنٹ نے اس کنٹریکٹ کو ایک پیغام بھیجا جس کی ہم ریورس انجینئرنگ کر رہے ہیں، اور بدلے میں اسے ETH ملا۔ + +![ایک دعوے کی ٹرانزیکشن](claim-tx.png) + +### 1e7df9d3 {#1e7df9d3} + +یہ فنکشن اوپر [`claim`](#claim) سے بہت ملتا جلتا ہے۔ یہ ایک merkle proof بھی چیک کرتا ہے، پہلے کو ETH منتقل کرنے کی کوشش کرتا ہے، اور اسی قسم کی لاگ انٹری تیار کرتا ہے۔ + +```python +def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable: + ... + idx = 0 + s = 0 + while idx < _param3.length: + if idx >= mem[96]: + revert with 0, 50 + _55 = mem[(32 * idx) + 128] + if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]: + ... + s = sha3(mem[_58 + 32 len mem[_58]]) + continue + mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) + ... + if unknown2eb4a7ab != s: + revert with 0, 'Invalid proof' + ... + call addr(_param1) with: + value s wei + gas 30000 wei + if not return_data.size: + if not ext_call.success: + require ext_code.size(stor2) + call stor2.deposit() with: + value s wei + gas gas_remaining wei + ... + log 0xdbd5389f: addr(_param1), s, bool(ext_call.success) +``` + +بنیادی فرق یہ ہے کہ پہلا پیرامیٹر، یعنی جس ونڈو سے ودڈرا کرنا ہے، وہ وہاں نہیں ہے۔ اس کے بجائے، ان تمام ونڈوز پر ایک لوپ ہے جن کا دعوی کیا جا سکتا ہے۔ + +```python + idx = 0 + s = 0 + while idx < currentWindow: + ... + if stor5[mem[0]]: + if idx == -1: + revert with 0, 17 + idx = idx + 1 + s = s + continue + ... + stor5[idx][addr(_param1)] = 1 + if idx >= unknown81e580d3.length: + revert with 0, 50 + mem[0] = 4 + if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]: + revert with 0, 17 + if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6): + revert with 0, 17 + if idx == -1: + revert with 0, 17 + idx = idx + 1 + s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6) + continue +``` + +لہذا یہ ایک `claim` کا ویرینٹ لگتا ہے جو تمام ونڈوز کا دعوی کرتا ہے۔ + +## نتیجہ {#conclusion} + +اب تک آپ کو یہ جان لینا چاہیے کہ ان کنٹریکٹس کو کیسے سمجھا جائے جن کا سورس کوڈ دستیاب نہیں ہے، یا تو opcodes کا استعمال کرکے یا (جب یہ کام کرتا ہے) ڈی کمپائلر کا استعمال کرکے۔ جیسا کہ اس مضمون کی طوالت سے ظاہر ہے، ایک کنٹریکٹ کی ریورس انجینئرنگ کوئی معمولی کام نہیں ہے، لیکن ایک ایسے نظام میں جہاں سیکیورٹی ضروری ہے، یہ ایک اہم ہنر ہے کہ کنٹریکٹس کے وعدے کے مطابق کام کرنے کی تصدیق کی جا سکے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/ur/developers/tutorials/run-node-raspberry-pi/index.md new file mode 100644 index 00000000000..a65345098e8 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/run-node-raspberry-pi/index.md @@ -0,0 +1,184 @@ +--- +title: "Raspeberry Pi 4 پر ایک ایتھیریم نوڈ چلائیں" +description: "اپنے Raspberry Pi 4 کو فلیش کریں، ایک ایتھرنیٹ کیبل لگائیں، SSD ڈسک کو جوڑیں اور Raspberry Pi 4 کو ایک مکمل ایتھیریم نوڈ + ویلیڈیٹر میں تبدیل کرنے کے لئے ڈیوائس کو پاور اپ کریں" +author: "EthereumOnArm" +tags: [ "کلائنٹس", "ایگزیکیوشن لیئر", "کنسینسس لیئر", "نوڈز" ] +lang: ur-in +skill: intermediate +published: 2022-06-10 +source: Ethereum on ARM +sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/ +--- + +**ARM پر ایتھیریم ایک کسٹم لینکس امیج ہے جو Raspberry Pi کو ایتھیریم نوڈ میں تبدیل کر سکتا ہے۔** + +ARM پر ایتھیریم کا استعمال کرکے Raspberry Pi کو ایتھیریم نوڈ میں تبدیل کرنے کے لئے، درج ذیل ہارڈویئر کی سفارش کی جاتی ہے: + +- Raspberry 4 (model B 8GB), Odroid M1 or Rock 5B (8GB/16GB RAM) board +- مائیکرو ایس ڈی کارڈ (کم از کم 16 جی بی کلاس 10) +- کم از کم 2 TB SSD USB 3.0 ڈسک یا USB سے SATA کیس کے ساتھ ایک SSD۔ +- پاور سپلائی +- ایتھرنیٹ کیبل +- پورٹ فارورڈنگ (مزید معلومات کے لئے کلائنٹس دیکھیں) +- ہیٹ سنک اور پنکھے کے ساتھ ایک کیس +- USB کی بورڈ، مانیٹر اور HDMI کیبل (مائیکرو-HDMI) (اختیاری) + +## ARM پر ایتھیریم کیوں چلائیں؟ {#why-run-ethereum-on-arm} + +ARM بورڈز بہت سستے، لچکدار، چھوٹے کمپیوٹر ہیں۔ یہ ایتھیریم نوڈس چلانے کے لئے اچھے انتخاب ہیں کیونکہ انہیں سستے میں خریدا جا سکتا ہے، اس طرح کنفیگر کیا جا سکتا ہے کہ ان کے تمام وسائل صرف نوڈ پر مرکوز ہوں، جس سے وہ موثر بن جاتے ہیں، وہ کم مقدار میں بجلی استعمال کرتے ہیں اور جسمانی طور پر چھوٹے ہوتے ہیں تاکہ وہ کسی بھی گھر میں غیر محسوس طریقے سے فٹ ہو سکیں۔ نوڈس کو اسپن اپ کرنا بھی بہت آسان ہے کیونکہ Raspberry Pi کے مائیکرو ایس ڈی کو پہلے سے تیار کردہ امیج کے ساتھ آسانی سے فلیش کیا جا سکتا ہے، جس میں کسی سافٹ ویئر کو ڈاؤن لوڈ یا بنانے کی ضرورت نہیں ہوتی۔ + +## یہ کیسے کام کرتا ہے؟ {#how-does-it-work} + +Raspberry Pi کا میموری کارڈ پہلے سے تیار کردہ امیج کے ساتھ فلیش کیا جاتا ہے۔ اس امیج میں ایتھیریم نوڈ چلانے کے لئے درکار ہر چیز موجود ہے۔ فلیش شدہ کارڈ کے ساتھ، صارف کو صرف Raspberry Pi کو پاور آن کرنا ہے۔ نوڈ کو چلانے کے لئے درکار تمام پروسیسز خود بخود شروع ہو جاتے ہیں۔ یہ اس لئے کام کرتا ہے کیونکہ میموری کارڈ میں ایک لینکس پر مبنی آپریٹنگ سسٹم (OS) ہوتا ہے جس کے اوپر سسٹم لیول کے پروسیسز خود بخود چلتے ہیں جو یونٹ کو ایک ایتھیریم نوڈ میں تبدیل کر دیتے ہیں۔ + +ایتھیریم کو مقبول Raspberry Pi لینکس OS "Raspbian" کا استعمال کرکے نہیں چلایا جا سکتا کیونکہ Raspbian اب بھی 32-بٹ آرکیٹیکچر کا استعمال کرتا ہے جس کی وجہ سے ایتھیریم صارفین کو میموری کے مسائل کا سامنا کرنا پڑتا ہے اور کنسنسس کلائنٹس 32-بٹ بائنریز کو سپورٹ نہیں کرتے ہیں۔ اس پر قابو پانے کے لئے، Ethereum on Arm ٹیم "Armbian" نامی ایک مقامی 64-بٹ OS پر منتقل ہو گئی۔ + +**امیجز تمام ضروری مراحل کا خیال رکھتی ہیں**، ماحول کو ترتیب دینے اور SSD ڈسک کو فارمیٹ کرنے سے لے کر ایتھیریم سافٹ ویئر کو انسٹال کرنے اور چلانے کے ساتھ ساتھ بلاکچین سنکرونائزیشن شروع کرنے تک۔ + +## ایگزیکیوشن اور کنسنسس کلائنٹس پر نوٹ {#note-on-execution-and-consensus-clients} + +ARM پر ایتھیریم امیج میں پہلے سے تیار کردہ ایگزیکیوشن اور کنسنسس کلائنٹس بطور سروسز شامل ہیں۔ ایک ایتھیریم نوڈ کو دونوں کلائنٹس کو سنک اور چلانے کی ضرورت ہوتی ہے۔ آپ کو صرف امیج ڈاؤن لوڈ اور فلیش کرنا ہے اور پھر سروسز شروع کرنی ہیں۔ امیج درج ذیل ایگزیکیوشن کلائنٹس کے ساتھ پہلے سے لوڈ شدہ ہے: + +- Geth +- Nethermind +- Besu + +اور درج ذیل کنسنسس کلائنٹس: + +- Lighthouse +- Nimbus +- Prysm +- Teku + +آپ کو چلانے کے لئے ہر ایک میں سے ایک کا انتخاب کرنا چاہئے - تمام ایگزیکیوشن کلائنٹس تمام کنسنسس کلائنٹس کے ساتھ مطابقت رکھتے ہیں۔ اگر آپ واضح طور پر کسی کلائنٹ کا انتخاب نہیں کرتے ہیں، تو نوڈ اپنے ڈیفالٹس - Geth اور Lighthouse - پر واپس آ جائے گا اور بورڈ کے پاور اپ ہونے پر انہیں خود بخود چلا دے گا۔ آپ کو اپنے راؤٹر پر پورٹ 30303 کھولنا ہوگا تاکہ Geth پیئرز کو تلاش اور ان سے منسلک ہو سکے۔ + +## امیج ڈاؤن لوڈ کرنا {#downloading-the-image} + +Raspberry Pi 4 ایتھیریم امیج ایک "پلگ اینڈ پلے" امیج ہے جو خود بخود ایگزیکیوشن اور کنسنسس کلائنٹس دونوں کو انسٹال اور سیٹ اپ کرتا ہے، انہیں ایک دوسرے سے بات کرنے اور ایتھیریم نیٹ ورک سے منسلک ہونے کے لئے کنفیگر کرتا ہے۔ صارف کو صرف ایک سادہ کمانڈ کا استعمال کرکے اپنے پروسیسز شروع کرنے کی ضرورت ہے۔ + +[Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1) سے Raspberry Pi امیج ڈاؤن لوڈ کریں اور SHA256 ہیش کی تصدیق کریں: + +```sh +# ڈاؤن لوڈ کی گئی امیج والی ڈائریکٹری سے +shasum -a 256 ethonarm_22.04.00.img.zip +# ہیش کا آؤٹ پٹ ہونا چاہئے: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f +``` + +نوٹ کریں کہ Rock 5B اور Odroid M1 بورڈز کے لئے امیجز Ethereum-on-Arm [ڈاؤن لوڈز پیج](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html) پر دستیاب ہیں۔ + +## مائیکرو ایس ڈی کو فلیش کرنا {#flashing-the-microsd} + +جو مائیکرو ایس ڈی کارڈ Raspberry Pi کے لئے استعمال کیا جائے گا اسے پہلے ڈیسک ٹاپ یا لیپ ٹاپ میں ڈالا جانا چاہئے تاکہ اسے فلیش کیا جا سکے۔ پھر، درج ذیل ٹرمینل کمانڈز ڈاؤن لوڈ کی گئی امیج کو ایس ڈی کارڈ پر فلیش کریں گے: + +```shell +# مائیکرو ایس ڈی کارڈ کا نام چیک کریں +sudo fdisk -l + +>> sdxxx +``` + +نام کو صحیح طریقے سے حاصل کرنا بہت ضروری ہے کیونکہ اگلی کمانڈ میں `dd` شامل ہے جو کارڈ پر امیج کو پش کرنے سے پہلے اس کے موجودہ مواد کو مکمل طور پر مٹا دیتا ہے۔ جاری رکھنے کے لئے، زپ شدہ امیج والی ڈائریکٹری پر جائیں: + +```shell +# امیج کو ان زپ اور فلیش کریں +unzip ethonarm_22.04.00.img.zip +sudo dd bs=1M if=ethonarm_22.04.00.img of=/dev/ conv=fdatasync status=progress +``` + +کارڈ اب فلیش ہو چکا ہے، لہذا اسے Raspberry Pi میں ڈالا جا سکتا ہے۔ + +## نوڈ شروع کریں {#start-the-node} + +ایس ڈی کارڈ کو Raspberry Pi میں ڈالنے کے بعد، ایتھرنیٹ کیبل اور SSD کو جوڑیں اور پھر پاور آن کریں۔ OS بوٹ اپ ہو گا اور خود بخود پہلے سے کنفیگر شدہ کام انجام دینا شروع کر دے گا جو Raspberry Pi کو ایک ایتھیریم نوڈ میں تبدیل کرتے ہیں، بشمول کلائنٹ سافٹ ویئر کو انسٹال کرنا اور بنانا۔ اس میں شاید 10-15 منٹ لگیں گے۔ + +ایک بار جب سب کچھ انسٹال اور کنفیگر ہو جائے، تو ssh کنکشن کے ذریعے ڈیوائس میں لاگ ان کریں یا اگر بورڈ سے مانیٹر اور کی بورڈ منسلک ہو تو براہ راست ٹرمینل کا استعمال کریں۔ لاگ ان کرنے کے لئے `ethereum` اکاؤنٹ کا استعمال کریں، کیونکہ اس کے پاس نوڈ شروع کرنے کے لئے درکار اجازتیں ہیں۔ + +```shell +صارف: ethereum +پاس ورڈ: ethereum +``` + +ڈیفالٹ ایگزیکیوشن کلائنٹ، Geth، خود بخود شروع ہو جائے گا۔ آپ درج ذیل ٹرمینل کمانڈ کا استعمال کرکے لاگز کو چیک کرکے اس کی تصدیق کر سکتے ہیں: + +```sh +sudo journalctl -u geth -f +``` + +کنسنسس کلائنٹ کو واضح طور پر شروع کرنے کی ضرورت ہے۔ ایسا کرنے کے لئے، پہلے اپنے راؤٹر پر پورٹ 9000 کھولیں تاکہ Lighthouse پیئرز کو تلاش اور ان سے منسلک ہو سکے۔ پھر لائٹ ہاؤس سروس کو فعال اور شروع کریں: + +```sh +sudo systemctl enable lighthouse-beacon +sudo systemctl start lighthouse-beacon +``` + +لاگز کا استعمال کرکے کلائنٹ کو چیک کریں: + +```sh +sudo journalctl -u lighthouse-beacon +``` + +نوٹ کریں کہ کنسنسس کلائنٹ چند منٹوں میں سنک ہو جائے گا کیونکہ یہ چیک پوائنٹ سنک کا استعمال کرتا ہے۔ ایگزیکیوشن کلائنٹ میں زیادہ وقت لگے گا - ممکنہ طور پر کئی گھنٹے، اور یہ تب تک شروع نہیں ہو گا جب تک کہ کنسنسس کلائنٹ پہلے ہی سنکنگ ختم نہ کر لے۔ (اس کی وجہ یہ ہے کہ ایگزیکیوشن کلائنٹ کو سنک کرنے کے لئے ایک ہدف کی ضرورت ہوتی ہے، جو سنک شدہ کنسنسس کلائنٹ فراہم کرتا ہے)۔ + +Geth اور Lighthouse سروسز کے چلنے اور سنک ہونے کے ساتھ، آپ کا Raspberry Pi اب ایک ایتھیریم نوڈ ہے! ایتھیریم نیٹ ورک کے ساتھ تعامل کرنے کا سب سے عام طریقہ Geth کے جاوا اسکرپٹ کنسول کا استعمال کرنا ہے، جسے پورٹ 8545 پر Geth کلائنٹ سے منسلک کیا جا سکتا ہے۔ Curl جیسے ریکوئسٹ ٹول کا استعمال کرکے JSON آبجیکٹس کے طور پر فارمیٹ شدہ کمانڈز کو جمع کرنا بھی ممکن ہے۔ مزید [Geth دستاویزات](https://geth.ethereum.org/) میں دیکھیں۔ + +Geth کو ایک Grafana ڈیش بورڈ پر میٹرکس رپورٹ کرنے کے لئے پہلے سے کنفیگر کیا گیا ہے جسے براؤزر میں دیکھا جا سکتا ہے۔ مزید جدید صارفین اس فیچر کا استعمال `ipaddress:3000` پر جا کر، `user: admin` اور `passwd: ethereum` پاس کرکے اپنے نوڈ کی صحت کی نگرانی کے لئے کرنا چاہ سکتے ہیں۔ + +## ویلیڈیٹرز {#validators} + +کنسنسس کلائنٹ میں اختیاری طور پر ایک ویلیڈیٹر بھی شامل کیا جا سکتا ہے۔ ویلیڈیٹر سافٹ ویئر آپ کے نوڈ کو کنسنسس میں فعال طور پر حصہ لینے کی اجازت دیتا ہے اور نیٹ ورک کو کرپٹو اکنامک سیکیورٹی فراہم کرتا ہے۔ آپ کو اس کام کے لئے ETH میں انعام دیا جاتا ہے۔ ایک ویلیڈیٹر چلانے کے لئے، آپ کے پاس پہلے 32 ETH ہونا چاہئے، جو ڈیپازٹ کنٹریکٹ میں جمع کرانا ضروری ہے۔ ڈیپازٹ [لانچ پیڈ](https://launchpad.ethereum.org/) پر مرحلہ وار گائیڈ پر عمل کرکے کیا جا سکتا ہے۔ یہ ڈیسک ٹاپ/لیپ ٹاپ پر کریں، لیکن کیز (keys) نہ بنائیں — یہ براہ راست Raspberry Pi پر کیا جا سکتا ہے۔ + +Raspberry Pi پر ایک ٹرمینل کھولیں اور ڈیپازٹ کیز بنانے کے لئے درج ذیل کمانڈ چلائیں: + +``` +sudo apt-get update +sudo apt-get install staking-deposit-cli +cd && deposit new-mnemonic --num_validators 1 +``` + +(یا [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) ڈاؤن لوڈ کریں تاکہ اسے ایئر گیپڈ مشین پر چلایا جا سکے، اور `deposit new-mnemnonic` کمانڈ چلائیں) + +نیمونک فریز کو محفوظ رکھیں! مذکورہ بالا کمانڈ نے نوڈ کے کیسٹور میں دو فائلیں بنائیں: ویلیڈیٹر کیز اور ایک ڈیپازٹ ڈیٹا فائل۔ ڈیپازٹ ڈیٹا کو لانچ پیڈ میں اپ لوڈ کرنے کی ضرورت ہے، لہذا اسے Raspberry Pi سے ڈیسک ٹاپ/لیپ ٹاپ پر کاپی کرنا ضروری ہے۔ یہ ssh کنکشن یا کسی دوسرے کاپی/پیسٹ طریقے کا استعمال کرکے کیا جا سکتا ہے۔ + +ایک بار جب ڈیپازٹ ڈیٹا فائل لانچ پیڈ چلانے والے کمپیوٹر پر دستیاب ہو جاتی ہے، تو اسے لانچ پیڈ اسکرین پر `+` پر ڈریگ اور ڈراپ کیا جا سکتا ہے۔ ڈیپازٹ کنٹریکٹ کو ٹرانزیکشن بھیجنے کے لئے اسکرین پر دی گئی ہدایات پر عمل کریں۔ + +واپس Raspberry Pi پر، ایک ویلیڈیٹر شروع کیا جا سکتا ہے۔ اس کے لئے ویلیڈیٹر کیز کو امپورٹ کرنے، انعامات جمع کرنے کے لئے ایڈریس سیٹ کرنے، اور پھر پہلے سے کنفیگر شدہ ویلیڈیٹر پروسیس شروع کرنے کی ضرورت ہوتی ہے۔ نیچے دی گئی مثال Lighthouse کے لئے ہے — دوسرے کنسنسس کلائنٹس کے لئے ہدایات [Ethereum on Arm docs](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) پر دستیاب ہیں: + +```shell +# ویلیڈیٹر کیز امپورٹ کریں +lighthouse account validator import --directory=/home/ethereum/validator_keys + +# انعام کا ایڈریس سیٹ کریں +sudo sed -i 's/' /etc/ethereum/lighthouse-validator.conf + +# ویلیڈیٹر شروع کریں +sudo systemctl start lighthouse-validator +``` + +مبارک ہو، اب آپ کے پاس Raspberry Pi پر ایک مکمل ایتھیریم نوڈ اور ویلیڈیٹر چل رہا ہے! + +## مزید تفصیلات {#more-details} + +اس صفحے نے Raspberry Pi کا استعمال کرکے Geth-Lighthouse نوڈ اور ویلیڈیٹر کو کیسے سیٹ اپ کیا جائے اس کا ایک جائزہ دیا۔ مزید تفصیلی ہدایات [Ethereum-on-Arm ویب سائٹ](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html) پر دستیاب ہیں۔ + +## فیڈ بیک کی تعریف کی جاتی ہے {#feedback-appreciated} + +ہم جانتے ہیں کہ Raspberry Pi کا ایک بہت بڑا صارف بیس ہے جو ایتھیریم نیٹ ورک کی صحت پر بہت مثبت اثر ڈال سکتا ہے۔ +براہ کرم اس ٹیوٹوریل میں تفصیلات کو دیکھیں، ٹیسٹ نیٹس پر چلانے کی کوشش کریں، Ethereum on Arm GitHub کو چیک کریں، فیڈ بیک دیں، مسائل اٹھائیں اور پل ریکوئسٹس کریں اور ٹیکنالوجی اور دستاویزات کو آگے بڑھانے میں مدد کریں! + +## حوالہ جات {#references} + +1. https://ubuntu.com/download/raspberry-pi +2. https://wikipedia.org/wiki/Port_forwarding +3. https://prometheus.io +4. https://grafana.com +5. https://forum.armbian.com/topic/5565-zram-vs-swap/ +6. https://geth.ethereum.org +7. https://nethermind.io +8. https://www.hyperledger.org/projects/besu +9. https://github.com/prysmaticlabs/prysm +10. https://lighthouse.sigmaprime.io +11. https://ethersphere.github.io/swarm-home +12. https://raiden.network +13. https://ipfs.io +14. https://status.im +15. https://vipnode.org diff --git a/public/content/translations/ur/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/ur/developers/tutorials/scam-token-tricks/index.md new file mode 100644 index 00000000000..cd13821ad5b --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/scam-token-tricks/index.md @@ -0,0 +1,470 @@ +--- +title: "اسکیم ٹوکنز کے ذریعہ استعمال ہونے والی کچھ ترکیبیں اور ان کا پتہ لگانے کا طریقہ" +description: "اس ٹیوٹوریل میں ہم ایک اسکیم ٹوکن کا تجزیہ کرتے ہیں تاکہ یہ دیکھ سکیں کہ اسکامرس کونسی ترکیبیں استعمال کرتے ہیں، وہ انہیں کیسے نافذ کرتے ہیں، اور ہم ان کا پتہ کیسے لگا سکتے ہیں۔" +author: Ori Pomerantz +tags: + [ + "اسکیم", + "solidity", + "erc-20", + "javascript", + "typescript" + ] +skill: intermediate +published: 2023-09-15 +lang: ur-in +--- + +اس ٹیوٹوریل میں ہم [ایک اسکیم ٹوکن](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) کا تجزیہ کرتے ہیں تاکہ یہ دیکھ سکیں کہ اسکامرس کونسی ترکیبیں استعمال کرتے ہیں اور وہ انہیں کیسے نافذ کرتے ہیں۔ ٹیوٹوریل کے اختتام تک آپ کو ERC-20 ٹوکن معاہدوں، ان کی صلاحیتوں، اور شکوک و شبہات کی ضرورت کیوں ہے اس کا ایک زیادہ جامع نظریہ حاصل ہو جائے گا۔ پھر ہم اس اسکیم ٹوکن کے ذریعہ جاری کردہ ایونٹس کو دیکھتے ہیں اور دیکھتے ہیں کہ ہم خود بخود اس کی شناخت کیسے کرسکتے ہیں کہ یہ قانونی نہیں ہے۔ + +## اسکیم ٹوکنز - وہ کیا ہیں، لوگ انہیں کیوں کرتے ہیں، اور ان سے کیسے بچا جائے {#scam-tokens} + +ایتھیریم کے سب سے عام استعمالات میں سے ایک یہ ہے کہ ایک گروپ ایک قابل تجارت ٹوکن بنائے، ایک طرح سے ان کی اپنی کرنسی۔ تاہم، جہاں کہیں بھی جائز استعمال کے معاملات ہیں جو قدر لاتے ہیں، وہاں مجرم بھی ہیں جو اس قدر کو اپنے لیے چرانے کی کوشش کرتے ہیں۔ + +آپ اس موضوع کے بارے میں مزید [ethereum.org پر کہیں اور](/guides/how-to-id-scam-tokens/) صارف کے نقطہ نظر سے پڑھ سکتے ہیں۔ یہ ٹیوٹوریل ایک اسکیم ٹوکن کا تجزیہ کرنے پر مرکوز ہے تاکہ یہ دیکھا جا سکے کہ یہ کیسے کیا جاتا ہے اور اس کا پتہ کیسے لگایا جا سکتا ہے۔ + +### مجھے کیسے پتہ چلے گا کہ wARB ایک اسکیم ہے؟ {#warb-scam} + +جس ٹوکن کا ہم تجزیہ کر رہے ہیں وہ [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) ہے، جو کہ قانونی [ARB ٹوکن](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) کے برابر ہونے کا بہانہ کرتا ہے۔ + +یہ جاننے کا سب سے آسان طریقہ کہ کونسا ٹوکن قانونی ہے، اس کی اصلی تنظیم [Arbitrum](https://arbitrum.foundation/) کو دیکھنا ہے۔ جائز پتے [ان کی دستاویزات](https://docs.arbitrum.foundation/deployment-addresses#token) میں بتائے گئے ہیں۔ + +### سورس کوڈ کیوں دستیاب ہے؟ {#why-source} + +عام طور پر ہم توقع کرتے ہیں کہ جو لوگ دوسروں کو اسکیم کرنے کی کوشش کرتے ہیں وہ خفیہ ہوتے ہیں، اور واقعی بہت سے اسکیم ٹوکنز کا کوڈ دستیاب نہیں ہوتا ہے (مثال کے طور پر، [یہ والا](https://optimistic.etherscan.io/token/0x15992f382d8c46d667b10dc8456dc36651af1452#code) اور [یہ والا](https://optimistic.etherscan.io/token/0x026b623eb4aada7de37ef25256854f9235207178#code))۔ + +تاہم، قانونی ٹوکن عام طور پر اپنے سورس کوڈ کو شائع کرتے ہیں، لہذا قانونی نظر آنے کے لیے اسکیم ٹوکنز کے مصنفین کبھی کبھی ایسا ہی کرتے ہیں۔ [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) ان ٹوکنز میں سے ایک ہے جن کا سورس کوڈ دستیاب ہے، جس سے اسے سمجھنا آسان ہو جاتا ہے۔ + +جبکہ کنٹریکٹ ڈیپلائرز یہ انتخاب کر سکتے ہیں کہ سورس کوڈ کو شائع کرنا ہے یا نہیں، وہ _غلط_ سورس کوڈ شائع نہیں کر سکتے۔ بلاک ایکسپلورر فراہم کردہ سورس کوڈ کو آزادانہ طور پر کمپائل کرتا ہے، اور اگر اسے بالکل وہی بائٹ کوڈ نہیں ملتا ہے، تو وہ اس سورس کوڈ کو مسترد کر دیتا ہے۔ [آپ اس بارے میں Etherscan سائٹ پر مزید پڑھ سکتے ہیں](https://etherscan.io/verifyContract)۔ + +## جائز ERC-20 ٹوکنز سے موازنہ {#compare-legit-erc20} + +ہم اس ٹوکن کا موازنہ قانونی ERC-20 ٹوکنز سے کرنے جا رہے ہیں۔ اگر آپ اس بات سے واقف نہیں ہیں کہ قانونی ERC-20 ٹوکن عام طور پر کیسے لکھے جاتے ہیں، [تو یہ ٹیوٹوریل دیکھیں](/developers/tutorials/erc20-annotated-code/)۔ + +### مراعات یافتہ پتوں کے لیے مستقل {#constants-for-privileged-addresses} + +معاہدوں کو کبھی کبھی مراعات یافتہ پتوں کی ضرورت ہوتی ہے۔ طویل مدتی استعمال کے لیے بنائے گئے معاہدے کچھ مراعات یافتہ پتوں کو ان پتوں کو تبدیل کرنے کی اجازت دیتے ہیں، مثال کے طور پر ایک نئے ملٹی سگ معاہدے کے استعمال کو فعال کرنے کے لیے۔ ایسا کرنے کے کئی طریقے ہیں۔ + +[`HOP` ٹوکن کنٹریکٹ](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code) [`Ownable`](https://docs.openzeppelin.com/contracts/2.x/access-control#ownership-and-ownable) پیٹرن کا استعمال کرتا ہے۔ مراعات یافتہ پتہ اسٹوریج میں رکھا جاتا ہے، ایک فیلڈ میں جسے `_owner` کہا جاتا ہے (تیسری فائل، `Ownable.sol` دیکھیں)۔ + +```solidity +abstract contract Ownable is Context { + address private _owner; + . + . + . +} +``` + +[`ARB` ٹوکن کنٹریکٹ](https://etherscan.io/address/0xad0c361ef902a7d9851ca7dcc85535da2d3c6fc7#code) کا براہ راست کوئی مراعات یافتہ پتہ نہیں ہے۔ تاہم، اسے کسی کی ضرورت نہیں ہے۔ یہ [ایڈریس `0xb50721bcf8d664c30412cfbc6cf7a15145234ad1`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1#code) پر [`پراکسی`](https://docs.openzeppelin.com/contracts/5.x/api/proxy) کے پیچھے بیٹھتا ہے۔ اس معاہدے کا ایک مراعات یافتہ پتہ ہے (چوتھی فائل، `ERC1967Upgrade.sol` دیکھیں) جسے اپ گریڈ کے لیے استعمال کیا جا سکتا ہے۔ + +```solidity + /** + * @dev EIP1967 ایڈمن سلاٹ میں ایک نیا پتہ اسٹور کرتا ہے۔ + */ + function _setAdmin(address newAdmin) private { + require(newAdmin != address(0), "ERC1967: new admin is the zero address"); + StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin; + } +``` + +اس کے برعکس، `wARB` کنٹریکٹ میں ایک ہارڈ کوڈڈ `contract_owner` ہے۔ + +```solidity +contract WrappedArbitrum is Context, IERC20 { + . + . + . + address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1; + address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33; + . + . + . +} +``` + +[یہ کنٹریکٹ کا مالک](https://etherscan.io/address/0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33) ایسا کنٹریکٹ نہیں ہے جسے مختلف اوقات میں مختلف اکاؤنٹس کے ذریعے کنٹرول کیا جا سکے، بلکہ ایک [بیرونی ملکیت والا اکاؤنٹ](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) ہے۔ اس کا مطلب یہ ہے کہ یہ شاید کسی فرد کے ذریعہ قلیل مدتی استعمال کے لئے ڈیزائن کیا گیا ہے، بجائے اس کے کہ ایک ERC-20 کو کنٹرول کرنے کے لئے طویل مدتی حل کے طور پر جو قابل قدر رہے گا۔ + +اور واقعی، اگر ہم Etherscan میں دیکھیں تو ہم دیکھتے ہیں کہ اسکیمر نے اس معاہدے کو صرف 12 گھنٹے کے لیے استعمال کیا ([پہلی ٹرانزیکشن](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2) سے [آخری ٹرانزیکشن](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b) تک) 19 مئی 2023 کے دوران۔ + +### جعلی `_transfer` فنکشن {#the-fake-transfer-function} + +یہ معیاری ہے کہ اصل منتقلی [اندرونی `_transfer` فنکشن](/developers/tutorials/erc20-annotated-code/#the-_transfer-function-_transfer) کا استعمال کرتے ہوئے ہوتی ہے۔ + +`wARB` میں یہ فنکشن تقریباً جائز لگتا ہے: + +```solidity + function _transfer(address sender, address recipient, uint256 amount) internal virtual{ + require(sender != address(0), "ERC20: صفر پتے سے منتقلی"); + require(recipient != address(0), "ERC20: صفر پتے پر منتقلی"); + + _beforeTokenTransfer(sender, recipient, amount); + + _balances[sender] = _balances[sender].sub(amount, "ERC20: منتقلی کی رقم بیلنس سے زیادہ ہے"); + _balances[recipient] = _balances[recipient].add(amount); + if (sender == contract_owner){ + sender = deployer; + } + emit Transfer(sender, recipient, amount); + } +``` + +مشکوک حصہ یہ ہے: + +```solidity + if (sender == contract_owner){ + sender = deployer; + } + emit Transfer(sender, recipient, amount); +``` + +اگر کنٹریکٹ کا مالک ٹوکن بھیجتا ہے، تو `Transfer` ایونٹ کیوں دکھاتا ہے کہ وہ `deployer` سے آئے ہیں؟ + +تاہم، ایک اور اہم مسئلہ ہے۔ اس `_transfer` فنکشن کو کون کال کرتا ہے؟ اسے باہر سے کال نہیں کیا جا سکتا، اسے `internal` نشان زد کیا گیا ہے۔ اور ہمارے پاس موجود کوڈ میں `_transfer` کی کوئی کال شامل نہیں ہے۔ ظاہر ہے، یہ یہاں ایک دھوکے کے طور پر ہے۔ + +```solidity + function transfer(address recipient, uint256 amount) public virtual override returns (bool) { + _f_(_msgSender(), recipient, amount); + return true; + } + + function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { + _f_(sender, recipient, amount); + _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: منتقلی کی رقم الاؤنس سے زیادہ ہے")); + return true; + } +``` + +جب ہم ٹوکن منتقل کرنے کے لیے کال کیے جانے والے فنکشنز، `transfer` اور `transferFrom` کو دیکھتے ہیں، تو ہم دیکھتے ہیں کہ وہ ایک بالکل مختلف فنکشن `_f_` کو کال کرتے ہیں۔ + +### اصلی `_f_` فنکشن {#the-real-f-function} + +```solidity + function _f_(address sender, address recipient, uint256 amount) internal _mod_(sender,recipient,amount) virtual { + require(sender != address(0), "ERC20: صفر پتے سے منتقلی"); + require(recipient != address(0), "ERC20: صفر پتے پر منتقلی"); + + _beforeTokenTransfer(sender, recipient, amount); + + _balances[sender] = _balances[sender].sub(amount, "ERC20: منتقلی کی رقم بیلنس سے زیادہ ہے"); + _balances[recipient] = _balances[recipient].add(amount); + if (sender == contract_owner){ + + sender = deployer; + } + emit Transfer(sender, recipient, amount); + } +``` + +اس فنکشن میں دو ممکنہ خطرے کی علامتیں ہیں۔ + +- [فنکشن موڈیفائر](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_` کا استعمال۔ تاہم، جب ہم سورس کوڈ میں دیکھتے ہیں تو ہمیں معلوم ہوتا ہے کہ `_mod_` دراصل بے ضرر ہے۔ + + ```solidity + modifier _mod_(address sender, address recipient, uint256 amount){ + _; + } + ``` + +- وہی مسئلہ جو ہم نے `_transfer` میں دیکھا تھا، جو یہ ہے کہ جب `contract_owner` ٹوکن بھیجتا ہے تو وہ `deployer` سے آتے ہوئے دکھائی دیتے ہیں۔ + +### جعلی ایونٹس کا فنکشن `dropNewTokens` {#the-fake-events-function-dropNewTokens} + +اب ہم ایک ایسی چیز پر آتے ہیں جو ایک حقیقی اسکیم کی طرح نظر آتی ہے۔ میں نے پڑھنے میں آسانی کے لیے فنکشن میں تھوڑی ترمیم کی ہے، لیکن یہ فعال طور پر مساوی ہے۔ + +```solidity +function dropNewTokens(address uPool, + address[] memory eReceiver, + uint256[] memory eAmounts) public auth() +``` + +اس فنکشن میں `auth()` موڈیفائر ہے، جس کا مطلب ہے کہ اسے صرف کنٹریکٹ کا مالک ہی کال کر سکتا ہے۔ + +```solidity +modifier auth() { + require(msg.sender == contract_owner, "تعامل کی اجازت نہیں ہے"); + _; +} +``` + +یہ پابندی بالکل منطقی ہے، کیونکہ ہم نہیں چاہیں گے کہ بے ترتیب اکاؤنٹس ٹوکن تقسیم کریں۔ تاہم، باقی فنکشن مشکوک ہے۔ + +```solidity +{ + for (uint256 i = 0; i < eReceiver.length; i++) { + emit Transfer(uPool, eReceiver[i], eAmounts[i]); + } +} +``` + +ایک پول اکاؤنٹ سے وصول کنندگان کی ایک صف میں رقوم کی ایک صف میں منتقل کرنے کا ایک فنکشن بالکل منطقی ہے۔ بہت سے استعمال کے معاملات ہیں جن میں آپ ایک ہی ذریعہ سے متعدد مقامات پر ٹوکن تقسیم کرنا چاہیں گے، جیسے پے رول، ایئر ڈراپس وغیرہ۔ یہ ایک ہی ٹرانزیکشن میں کرنا (گیس میں) سستا ہے بجائے اس کے کہ متعدد ٹرانزیکشنز جاری کی جائیں، یا یہاں تک کہ ایک ہی ٹرانزیکشن کے حصے کے طور پر ایک مختلف کنٹریکٹ سے ERC-20 کو متعدد بار کال کیا جائے۔ + +`dropNewTokens` ایسا نہیں کرتا ہے۔ یہ [`Transfer` ایونٹس](https://eips.ethereum.org/EIPS/eip-20#transfer-1) خارج کرتا ہے، لیکن اصل میں کوئی ٹوکن منتقل نہیں کرتا ہے۔ آف چین ایپلیکیشنز کو ایک ایسی منتقلی کے بارے میں بتا کر الجھانے کی کوئی جائز وجہ نہیں ہے جو واقعی نہیں ہوئی تھی۔ + +### جلانے والا `Approve` فنکشن {#the-burning-approve-function} + +ERC-20 کنٹریکٹس میں الاؤنس کے لیے [ایک `approve` فنکشن](/developers/tutorials/erc20-annotated-code/#approve) ہونا چاہیے، اور واقعی ہمارے اسکیم ٹوکن میں ایسا فنکشن ہے، اور یہ درست بھی ہے۔ تاہم، چونکہ Solidity C سے ماخوذ ہے، یہ کیس کے لحاظ سے اہم ہے۔ `Approve` اور `approve` مختلف اسٹرنگز ہیں۔ + +نیز، فعالیت کا تعلق `approve` سے نہیں ہے۔ + +```solidity + function Approve( + address[] memory holders) +``` + +اس فنکشن کو ٹوکن کے ہولڈرز کے لیے پتوں کی ایک صف کے ساتھ کال کیا جاتا ہے۔ + +```solidity + public approver() { +``` + +`approver()` موڈیفائر اس بات کو یقینی بناتا ہے کہ صرف `contract_owner` کو اس فنکشن کو کال کرنے کی اجازت ہے (نیچے دیکھیں)۔ + +```solidity + for (uint256 i = 0; i < holders.length; i++) { + uint256 amount = _balances[holders[i]]; + _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount); + _balances[holders[i]] = _balances[holders[i]].sub(amount, + "ERC20: جلانے کی رقم بیلنس سے زیادہ ہے"); + _balances[0x0000000000000000000000000000000000000001] = + _balances[0x0000000000000000000000000000000000000001].add(amount); + } + } + +``` + +ہر ہولڈر ایڈریس کے لیے یہ فنکشن ہولڈر کے پورے بیلنس کو ایڈریس `0x00...01` پر منتقل کرتا ہے، مؤثر طریقے سے اسے جلاتا ہے (معیار میں اصل `burn` کل سپلائی کو بھی تبدیل کرتا ہے، اور ٹوکنز کو `0x00...00` پر منتقل کرتا ہے)۔ اس کا مطلب ہے کہ `contract_owner` کسی بھی صارف کے اثاثے ہٹا سکتا ہے۔ یہ ایک ایسی خصوصیت نہیں لگتی ہے جسے آپ گورننس ٹوکن میں چاہیں گے۔ + +### کوڈ کے معیار کے مسائل {#code-quality-issues} + +یہ کوڈ کے معیار کے مسائل یہ _ثابت_ نہیں کرتے ہیں کہ یہ کوڈ ایک اسکیم ہے، لیکن وہ اسے مشکوک ظاہر کرتے ہیں۔ Arbitrum جیسی منظم کمپنیاں عام طور پر اتنا برا کوڈ جاری نہیں کرتی ہیں۔ + +#### `mount` فنکشن {#the-mount-function} + +جبکہ یہ [معیار](https://eips.ethereum.org/EIPS/eip-20) میں متعین نہیں ہے، عام طور پر نئے ٹوکن بنانے والے فنکشن کو [`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn) کہا جاتا ہے۔ + +اگر ہم `wARB` کنسٹرکٹر میں دیکھیں، تو ہم دیکھتے ہیں کہ ٹائم منٹ فنکشن کا نام کسی وجہ سے `mount` رکھ دیا گیا ہے، اور اسے کارکردگی کے لیے پوری رقم کے لیے ایک بار کے بجائے، ابتدائی سپلائی کے پانچویں حصے کے ساتھ پانچ بار کال کیا جاتا ہے۔ + +```solidity + constructor () public { + + _name = "Wrapped Arbitrum"; + _symbol = "wARB"; + _decimals = 18; + uint256 initialSupply = 1000000000000; + + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + } +``` + +`mount` فنکشن خود بھی مشکوک ہے۔ + +```solidity + function mount(address account, uint256 amount) public { + require(msg.sender == contract_owner, "ERC20: صفر پتے پر منٹ کریں"); +``` + +`require` کو دیکھتے ہوئے، ہم دیکھتے ہیں کہ صرف کنٹریکٹ کے مالک کو منٹ کرنے کی اجازت ہے۔ یہ جائز ہے۔ لیکن غلطی کا پیغام _صرف مالک کو منٹ کرنے کی اجازت ہے_ یا کچھ اسی طرح کا ہونا چاہیے۔ اس کے بجائے، یہ غیر متعلقہ _ERC20: صفر پتے پر منٹ کریں_ ہے۔ صفر پتے پر منٹ کرنے کا صحیح ٹیسٹ `require(account != address(0), "")` ہے، جسے کنٹریکٹ کبھی چیک کرنے کی زحمت نہیں کرتا۔ + +```solidity + _totalSupply = _totalSupply.add(amount); + _balances[contract_owner] = _balances[contract_owner].add(amount); + emit Transfer(address(0), account, amount); + } +``` + +منٹنگ سے براہ راست متعلق دو مزید مشکوک حقائق ہیں: + +- ایک `account` پیرامیٹر ہے، جو ممکنہ طور پر وہ اکاؤنٹ ہے جسے منٹ کی گئی رقم وصول کرنی چاہیے۔ لیکن جو بیلنس بڑھتا ہے وہ دراصل `contract_owner` کا ہے۔ + +- جبکہ بڑھا ہوا بیلنس `contract_owner` کا ہے، خارج ہونے والا ایونٹ `account` میں منتقلی دکھاتا ہے۔ + +### `auth` اور `approver` دونوں کیوں؟ وہ `mod` کیوں جو کچھ نہیں کرتا؟ {#why-both-autho-and-approver-why-the-mod-that-does-nothing} + +اس کنٹریکٹ میں تین موڈیفائرز ہیں: `_mod_`، `auth`، اور `approver`۔ + +```solidity + modifier _mod_(address sender, address recipient, uint256 amount){ + _; + } +``` + +`_mod_` تین پیرامیٹرز لیتا ہے اور ان کے ساتھ کچھ نہیں کرتا ہے۔ یہ کیوں ہے؟ + +```solidity + modifier auth() { + require(msg.sender == contract_owner, "تعامل کی اجازت نہیں ہے"); + _; + } + + modifier approver() { + require(msg.sender == contract_owner, "تعامل کی اجازت نہیں ہے"); + _; + } +``` + +`auth` اور `approver` زیادہ معنی خیز ہیں، کیونکہ وہ چیک کرتے ہیں کہ کنٹریکٹ `contract_owner` کے ذریعہ کال کیا گیا تھا۔ ہم توقع کریں گے کہ کچھ مراعات یافتہ کارروائیاں، جیسے منٹنگ، اس اکاؤنٹ تک محدود ہوں۔ تاہم، دو الگ الگ فنکشنز رکھنے کا کیا فائدہ ہے جو _بالکل ایک ہی کام_ کرتے ہیں؟ + +## ہم خود بخود کیا پتہ لگا سکتے ہیں؟ {#what-can-we-detect-automatically} + +ہم Etherscan کو دیکھ کر دیکھ سکتے ہیں کہ `wARB` ایک اسکیم ٹوکن ہے۔ تاہم، یہ ایک مرکزی حل ہے۔ نظریاتی طور پر، Etherscan کو سبوتاژ یا ہیک کیا جا سکتا ہے۔ یہ بہتر ہے کہ آزادانہ طور پر یہ معلوم کیا جا سکے کہ کوئی ٹوکن جائز ہے یا نہیں۔ + +کچھ ترکیبیں ہیں جن کا استعمال ہم یہ شناخت کرنے کے لیے کر سکتے ہیں کہ ERC-20 ٹوکن مشکوک ہے (یا تو ایک اسکیم یا بہت بری طرح سے لکھا گیا ہے)، ان کے خارج کردہ ایونٹس کو دیکھ کر۔ + +## مشکوک `Approval` ایونٹس {#suspicious-approval-events} + +[`Approval` ایونٹس](https://eips.ethereum.org/EIPS/eip-20#approval) صرف براہ راست درخواست کے ساتھ ہونے چاہئیں ([`Transfer` ایونٹس](https://eips.ethereum.org/EIPS/eip-20#transfer-1) کے برعکس جو الاؤنس کے نتیجے میں ہو سکتے ہیں)۔ [اس مسئلے کی تفصیلی وضاحت کے لیے Solidity دستاویزات دیکھیں](https://docs.soliditylang.org/en/v0.8.20/security-considerations.html#tx-origin) اور یہ کہ درخواستیں براہ راست کیوں ہونی چاہئیں، بجائے اس کے کہ کسی کنٹریکٹ کے ذریعے ثالثی کی جائے۔ + +`Approval` ایونٹس جو [بیرونی ملکیت والے اکاؤنٹ](/developers/docs/accounts/#types-of-account) سے خرچ کرنے کی منظوری دیتے ہیں، ان ٹرانزیکشنز سے آنے چاہئیں جو اس اکاؤنٹ میں شروع ہوتے ہیں، اور جن کی منزل ERC-20 کنٹریکٹ ہے۔ بیرونی ملکیت والے اکاؤنٹ سے کسی بھی دوسری قسم کی منظوری مشکوک ہے۔ + +[یہاں ایک پروگرام ہے جو اس قسم کے ایونٹ کی شناخت کرتا ہے](https://github.com/qbzzt/20230915-scam-token-detection)، [viem](https://viem.sh/) اور [TypeScript](https://www.typescriptlang.org/docs/) کا استعمال کرتے ہوئے، جو کہ ٹائپ سیفٹی کے ساتھ ایک JavaScript ویرینٹ ہے۔ اسے چلانے کے لئے: + +1. `.env.example` کو `.env` میں کاپی کریں۔ +2. ایک Ethereum مین نیٹ نوڈ کا URL فراہم کرنے کے لیے `.env` میں ترمیم کریں۔ +3. ضروری پیکیجز انسٹال کرنے کے لیے `pnpm install` چلائیں۔ +4. مشکوک منظوریوں کو تلاش کرنے کے لیے `pnpm susApproval` چلائیں۔ + +یہاں لائن بہ لائن وضاحت ہے: + +```typescript +import { + Address, + TransactionReceipt, + createPublicClient, + http, + parseAbiItem, +} from "viem" +import { mainnet } from "viem/chains" +``` + +`viem` سے ٹائپ ڈیفینیشنز، فنکشنز، اور چین ڈیفینیشن درآمد کریں۔ + +```typescript +import { config } from "dotenv" +config() +``` + +URL حاصل کرنے کے لیے `.env` پڑھیں۔ + +```typescript +const client = createPublicClient({ + chain: mainnet, + transport: http(process.env.URL), +}) +``` + +ایک Viem کلائنٹ بنائیں۔ ہمیں صرف بلاکچین سے پڑھنے کی ضرورت ہے، لہذا اس کلائنٹ کو پرائیویٹ کلید کی ضرورت نہیں ہے۔ + +```typescript +const testedAddress = "0xb047c8032b99841713b8e3872f06cf32beb27b82" +const fromBlock = 16859812n +const toBlock = 16873372n +``` + +مشکوک ERC-20 کنٹریکٹ کا پتہ، اور وہ بلاکس جن کے اندر ہم ایونٹس تلاش کریں گے۔ نوڈ فراہم کنندگان عام طور پر ایونٹس کو پڑھنے کی ہماری صلاحیت کو محدود کرتے ہیں کیونکہ بینڈوتھ مہنگی ہو سکتی ہے۔ خوش قسمتی سے `wARB` اٹھارہ گھنٹے کی مدت کے لیے استعمال میں نہیں تھا، لہذا ہم تمام ایونٹس کو دیکھ سکتے ہیں (کل صرف 13 تھے)۔ + +```typescript +const approvalEvents = await client.getLogs({ + address: testedAddress, + fromBlock, + toBlock, + event: parseAbiItem( + "event Approval(address indexed _owner, address indexed _spender, uint256 _value)" + ), +}) +``` + +یہ Viem سے ایونٹ کی معلومات مانگنے کا طریقہ ہے۔ جب ہم اسے فیلڈ کے ناموں سمیت، عین ایونٹ کا دستخط فراہم کرتے ہیں، تو یہ ہمارے لیے ایونٹ کو پارس کرتا ہے۔ + +```typescript +const isContract = async (addr: Address): boolean => + await client.getBytecode({ address: addr }) +``` + +ہمارا الگورتھم صرف بیرونی ملکیت والے اکاؤنٹس پر لاگو ہوتا ہے۔ اگر `client.getBytecode` کے ذریعہ کوئی بائٹ کوڈ واپس کیا جاتا ہے تو اس کا مطلب ہے کہ یہ ایک کنٹریکٹ ہے اور ہمیں اسے صرف چھوڑ دینا چاہیے۔ + +اگر آپ نے پہلے TypeScript استعمال نہیں کیا ہے، تو فنکشن کی تعریف تھوڑی عجیب لگ سکتی ہے۔ ہم اسے صرف یہ نہیں بتاتے کہ پہلا (اور واحد) پیرامیٹر `addr` کہلاتا ہے، بلکہ یہ بھی کہ یہ `Address` قسم کا ہے۔ اسی طرح، `: boolean` حصہ TypeScript کو بتاتا ہے کہ فنکشن کی واپسی کی قدر ایک بولین ہے۔ + +```typescript +const getEventTxn = async (ev: Event): TransactionReceipt => + await client.getTransactionReceipt({ hash: ev.transactionHash }) +``` + +یہ فنکشن ایک ایونٹ سے ٹرانزیکشن کی رسید حاصل کرتا ہے۔ ہمیں رسید کی ضرورت ہے تاکہ یہ یقینی بنایا جا سکے کہ ہم جانتے ہیں کہ ٹرانزیکشن کی منزل کیا تھی۔ + +```typescript +const suspiciousApprovalEvent = async (ev : Event) : (Event | null) => { +``` + +یہ سب سے اہم فنکشن ہے، جو اصل میں فیصلہ کرتا ہے کہ کوئی ایونٹ مشکوک ہے یا نہیں۔ واپسی کی قسم، `(Event | null)`، TypeScript کو بتاتی ہے کہ یہ فنکشن یا تو `Event` یا `null` واپس کر سکتا ہے۔ اگر ایونٹ مشکوک نہیں ہے تو ہم `null` واپس کرتے ہیں۔ + +```typescript +const owner = ev.args._owner +``` + +Viem کے پاس فیلڈ کے نام ہیں، لہذا اس نے ہمارے لیے ایونٹ کو پارس کیا۔ `_owner` خرچ کیے جانے والے ٹوکنز کا مالک ہے۔ + +```typescript +// کنٹریکٹس کے ذریعے منظوریاں مشکوک نہیں ہیں +if (await isContract(owner)) return null +``` + +اگر مالک ایک کنٹریکٹ ہے، تو فرض کریں کہ یہ منظوری مشکوک نہیں ہے۔ یہ چیک کرنے کے لیے کہ آیا کسی کنٹریکٹ کی منظوری مشکوک ہے یا نہیں، ہمیں ٹرانزیکشن کے مکمل عمل کو ٹریس کرنے کی ضرورت ہوگی تاکہ یہ دیکھا جا سکے کہ کیا یہ کبھی مالک کنٹریکٹ تک پہنچا، اور کیا اس کنٹریکٹ نے براہ راست ERC-20 کنٹریکٹ کو کال کیا۔ یہ اس سے کہیں زیادہ وسائل خرچ کرنے والا ہے جتنا ہم کرنا چاہیں گے۔ + +```typescript +const txn = await getEventTxn(ev) +``` + +اگر منظوری بیرونی ملکیت والے اکاؤنٹ سے آتی ہے، تو اس ٹرانزیکشن کو حاصل کریں جس کی وجہ سے یہ ہوا۔ + +```typescript +// منظوری مشکوک ہے اگر یہ EOA مالک سے آتی ہے جو ٹرانزیکشن کا `from` نہیں ہے +if (owner.toLowerCase() != txn.from.toLowerCase()) return ev +``` + +ہم صرف اسٹرنگ کی مساوات کی جانچ نہیں کر سکتے کیونکہ پتے ہیکسا ڈیسیمل ہوتے ہیں، لہذا ان میں حروف ہوتے ہیں۔ کبھی کبھی، مثال کے طور پر `txn.from` میں، وہ حروف سب چھوٹے ہوتے ہیں۔ دیگر معاملات میں، جیسے کہ `ev.args._owner`، پتہ [خرابی کی شناخت کے لیے مخلوط کیس](https://eips.ethereum.org/EIPS/eip-55) میں ہوتا ہے۔ + +لیکن اگر ٹرانزیکشن مالک کی طرف سے نہیں ہے، اور وہ مالک بیرونی طور پر ملکیت میں ہے، تو ہمارے پاس ایک مشکوک ٹرانزیکشن ہے۔ + +```typescript +// یہ بھی مشکوک ہے اگر ٹرانزیکشن کی منزل وہ ERC-20 کنٹریکٹ نہیں ہے جس کی ہم +// تحقیقات کر رہے ہیں +if (txn.to.toLowerCase() != testedAddress) return ev +``` + +اسی طرح، اگر ٹرانزیکشن کا `to` پتہ، پہلا کال کیا گیا کنٹریکٹ، زیر تفتیش ERC-20 کنٹریکٹ نہیں ہے تو یہ مشکوک ہے۔ + +```typescript + // اگر مشکوک ہونے کی کوئی وجہ نہیں ہے، تو null واپس کریں۔ + return null +} +``` + +اگر کوئی بھی شرط درست نہیں ہے تو `Approval` ایونٹ مشکوک نہیں ہے۔ + +```typescript +const testPromises = approvalEvents.map((ev) => suspiciousApprovalEvent(ev)) +const testResults = (await Promise.all(testPromises)).filter((x) => x != null) + +console.log(testResults) +``` + +ایک `async` فنکشن ایک `Promise` آبجیکٹ واپس کرتا ہے۔ عام نحو، `await x()` کے ساتھ، ہم پروسیسنگ جاری رکھنے سے پہلے اس `Promise` کے پورا ہونے کا انتظار کرتے ہیں۔ یہ پروگرام کرنے اور پیروی کرنے میں آسان ہے، لیکن یہ غیر موثر بھی ہے۔ جبکہ ہم ایک مخصوص ایونٹ کے لیے `Promise` کے پورا ہونے کا انتظار کر رہے ہیں، ہم پہلے ہی اگلے ایونٹ پر کام شروع کر سکتے ہیں۔ + +یہاں ہم `Promise` آبجیکٹس کی ایک صف بنانے کے لیے [`map`](https://www.w3schools.com/jsref/jsref_map.asp) کا استعمال کرتے ہیں۔ پھر ہم ان تمام وعدوں کے حل ہونے کا انتظار کرنے کے لیے [`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/) کا استعمال کرتے ہیں۔ پھر ہم غیر مشکوک ایونٹس کو ہٹانے کے لیے ان نتائج کو [`filter`](https://www.w3schools.com/jsref/jsref_filter.asp) کرتے ہیں۔ + +### مشکوک `Transfer` ایونٹس {#suspicious-transfer-events} + +اسکیم ٹوکنز کی شناخت کا ایک اور ممکنہ طریقہ یہ دیکھنا ہے کہ آیا ان کے پاس کوئی مشکوک منتقلی ہے۔ مثال کے طور پر، ان اکاؤنٹس سے منتقلی جن کے پاس اتنے زیادہ ٹوکن نہیں ہیں۔ آپ دیکھ سکتے ہیں کہ [اس ٹیسٹ کو کیسے نافذ کیا جائے](https://github.com/qbzzt/20230915-scam-token-detection/blob/main/susTransfer.ts)، لیکن `wARB` میں یہ مسئلہ نہیں ہے۔ + +## نتیجہ {#conclusion} + +ERC-20 اسکیمز کا خودکار پتہ لگانا [غلط منفی](https://en.wikipedia.org/wiki/False_positives_and_false_negatives#False_negative_error) سے دوچار ہے، کیونکہ ایک اسکیم بالکل عام ERC-20 ٹوکن کنٹریکٹ استعمال کر سکتی ہے جو صرف کسی حقیقی چیز کی نمائندگی نہیں کرتا ہے۔ لہذا آپ کو ہمیشہ _ایک قابل اعتماد ذریعہ سے ٹوکن کا پتہ حاصل کرنے_ کی کوشش کرنی چاہیے۔ + +خودکار پتہ لگانا کچھ معاملات میں مدد کر سکتا ہے، جیسے کہ DeFi کے ٹکڑوں میں، جہاں بہت سے ٹوکن ہوتے ہیں اور انہیں خود بخود سنبھالنے کی ضرورت ہوتی ہے۔ لیکن ہمیشہ کی طرح [caveat emptor](https://www.investopedia.com/terms/c/caveatemptor.asp)، اپنی تحقیق خود کریں، اور اپنے صارفین کو بھی ایسا کرنے کی ترغیب دیں۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/secret-state/index.md b/public/content/translations/ur/developers/tutorials/secret-state/index.md new file mode 100644 index 00000000000..7329669741d --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/secret-state/index.md @@ -0,0 +1,741 @@ +--- +title: "خفیہ اسٹیٹ کے لیے زیرو نالج کا استعمال" +description: "آن چین گیمز محدود ہیں کیونکہ وہ کوئی پوشیدہ معلومات نہیں رکھ سکتے۔ اس ٹیوٹوریل کو پڑھنے کے بعد، ایک قاری زیرو نالج پروفز اور سرور کمپونینٹس کو ملا کر ایک خفیہ اسٹیٹ، آف چین، کمپونینٹ کے ساتھ قابل تصدیق گیمز بنا سکے گا۔ اس کو کرنے کی تکنیک کا مظاہرہ ایک مائن سویپر گیم بنا کر کیا جائے گا۔" +author: Ori Pomerantz +tags: + [ + "سرور", + "آف چین", + "مرکزی", + "زیرو-نالج", + "zokrates", + "mud" + ] +skill: advanced +lang: ur-in +published: 2025-03-15 +--- + +_بلاک چین پر کوئی راز نہیں ہوتے_۔ بلاک چین پر جو کچھ بھی پوسٹ کیا جاتا ہے وہ سب کے پڑھنے کے لیے کھلا ہے۔ یہ ضروری ہے، کیونکہ بلاک چین اس پر مبنی ہے کہ کوئی بھی اس کی تصدیق کر سکے۔ تاہم، گیمز اکثر خفیہ اسٹیٹ پر انحصار کرتے ہیں۔ مثال کے طور پر، [مائن سویپر](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) کے گیم کا کوئی مطلب نہیں بنتا اگر آپ صرف ایک بلاک چین ایکسپلورر پر جا کر نقشہ دیکھ سکتے ہیں۔ + +سب سے آسان حل یہ ہے کہ خفیہ اسٹیٹ کو رکھنے کے لیے ایک [سرور کمپونینٹ](/developers/tutorials/server-components/) کا استعمال کیا جائے۔ تاہم، ہم بلاک چین کا استعمال اس لیے کرتے ہیں تاکہ گیم ڈیولپر کی طرف سے دھوکہ دہی کو روکا جا سکے۔ ہمیں سرور کمپونینٹ کی ایمانداری کو یقینی بنانے کی ضرورت ہے۔ سرور اسٹیٹ کا ایک ہیش فراہم کر سکتا ہے، اور [زیرو نالج پروفز](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) کا استعمال کر کے یہ ثابت کر سکتا ہے کہ ایک چال کے نتیجے کا حساب لگانے کے لیے استعمال کیا گیا اسٹیٹ صحیح ہے۔ + +اس مضمون کو پڑھنے کے بعد آپ جان جائیں گے کہ اس قسم کا خفیہ اسٹیٹ رکھنے والا سرور، اسٹیٹ دکھانے کے لیے ایک کلائنٹ، اور دونوں کے درمیان مواصلات کے لیے ایک آن چین کمپونینٹ کیسے بنایا جائے۔ ہم جو اہم ٹولز استعمال کریں گے وہ یہ ہیں: + +| ٹول | مقصد | ورژن پر تصدیق شدہ | +| --------------------------------------------- | ------------------------------------------- | --------------------------------------: | +| [Zokrates](https://zokrates.github.io/) | زیرو نالج پروفز اور ان کی تصدیق | 1.1.9 | +| [Typescript](https://www.typescriptlang.org/) | سرور اور کلائنٹ دونوں کے لیے پروگرامنگ زبان | 5.4.2 | +| [Node](https://nodejs.org/en) | سرور چلانا | 20.18.2 | +| [Viem](https://viem.sh/) | بلاک چین کے ساتھ مواصلات | 2.9.20 | +| [MUD](https://mud.dev/) | آن چین ڈیٹا مینجمنٹ | 2.0.12 | +| [React](https://react.dev/) | کلائنٹ یوزر انٹرفیس | 18.2.0 | +| [Vite](https://vitejs.dev/) | کلائنٹ کوڈ کی سرونگ | 4.2.1 | + +## مائن سویپر کی مثال {#minesweeper} + +[مائن سویپر](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) ایک ایسا گیم ہے جس میں ایک مائن فیلڈ کے ساتھ ایک خفیہ نقشہ شامل ہے۔ کھلاڑی ایک مخصوص مقام پر کھودنے کا انتخاب کرتا ہے۔ اگر اس مقام پر کوئی مائن ہے، تو گیم ختم ہو جاتا ہے۔ ورنہ، کھلاڑی کو اس مقام کے آس پاس کے آٹھ چوکوروں میں مائنز کی تعداد ملتی ہے۔ + +یہ ایپلیکیشن [MUD](https://mud.dev/) کا استعمال کرتے ہوئے لکھی گئی ہے، جو ایک ایسا فریم ورک ہے جو ہمیں [کی-ویلیو ڈیٹا بیس](https://aws.amazon.com/nosql/key-value/) کا استعمال کرتے ہوئے آن چین ڈیٹا اسٹور کرنے اور اس ڈیٹا کو خود بخود آف چین کمپونینٹس کے ساتھ سنکرونائز کرنے کی اجازت دیتا ہے۔ سنکرونائزیشن کے علاوہ، MUD رسائی کنٹرول فراہم کرنا آسان بناتا ہے، اور دوسرے صارفین کے لیے ہماری ایپلیکیشن کو بغیر اجازت کے [توسیع](https://mud.dev/guides/extending-a-world) دینا بھی آسان بناتا ہے۔ + +### مائن سویپر کی مثال چلانا {#running-minesweeper-example} + +مائن سویپر کی مثال چلانے کے لیے: + +1. یقینی بنائیں کہ آپ نے [پیشگی شرائط انسٹال کر لی ہیں](https://mud.dev/quickstart#prerequisites): [Node](https://mud.dev/quickstart#prerequisites), [Foundry](https://book.getfoundry.sh/getting-started/installation), [`git`](https://git-scm.com/downloads), [`pnpm`](https://git-scm.com/downloads), اور [`mprocs`](https://github.com/pvolok/mprocs)۔ + +2. ریپوزٹری کو کلون کریں۔ + + ```sh copy + git clone https://github.com/qbzzt/20240901-secret-state.git + ``` + +3. پیکجز انسٹال کریں۔ + + ```sh copy + cd 20240901-secret-state/ + pnpm install + npm install -g mprocs + ``` + + اگر `pnpm install` کے حصے کے طور پر Foundry انسٹال کیا گیا تھا، تو آپ کو کمانڈ لائن شیل کو دوبارہ شروع کرنے کی ضرورت ہے۔ + +4. کنٹریکٹس کو کمپائل کریں + + ```sh copy + cd packages/contracts + forge build + cd ../.. + ``` + +5. پروگرام شروع کریں (بشمول ایک [anvil](https://book.getfoundry.sh/anvil/) بلاک چین) اور انتظار کریں۔ + + ```sh copy + mprocs + ``` + + نوٹ کریں کہ اسٹارٹ اپ میں کافی وقت لگتا ہے۔ پیشرفت دیکھنے کے لیے، پہلے نیچے کے تیر کا استعمال کرتے ہوئے _کنٹریکٹس_ ٹیب پر اسکرول کریں تاکہ MUD کنٹریکٹس کو ڈیپلائے ہوتے دیکھیں۔ جب آپ کو _فائل کی تبدیلیوں کا انتظار ہے…_ کا پیغام ملے، تو کنٹریکٹس ڈیپلائے ہو چکے ہیں اور مزید پیشرفت _سرور_ ٹیب میں ہوگی۔ وہاں، آپ اس وقت تک انتظار کریں جب تک آپ کو _ویریفائر ایڈریس: 0x...._ کا پیغام نہ مل جائے۔ + + اگر یہ مرحلہ کامیاب ہو جاتا ہے، تو آپ کو `mprocs` اسکرین نظر آئے گی، جس میں بائیں طرف مختلف پروسیسز اور دائیں طرف فی الحال منتخب کردہ پروسیس کے لیے کنسول آؤٹ پٹ ہوگا۔ + + ![mprocs اسکرین](./mprocs.png) + + اگر `mprocs` کے ساتھ کوئی مسئلہ ہے، تو آپ چاروں پروسیسز کو دستی طور پر چلا سکتے ہیں، ہر ایک کو اپنی کمانڈ لائن ونڈو میں: + + - **Anvil** + + ```sh + cd packages/contracts + anvil --base-fee 0 --block-time 2 + ``` + + - **کنٹریکٹس** + + ```sh + cd packages/contracts + pnpm mud dev-contracts --rpc http://127.0.0.1:8545 + ``` + + - **سرور** + + ```sh + cd packages/server + pnpm start + ``` + + - **کلائنٹ** + + ```sh + cd packages/client + pnpm run dev + ``` + +6. اب آپ [کلائنٹ](http://localhost:3000) پر براؤز کر سکتے ہیں، **نیا گیم** پر کلک کریں، اور کھیلنا شروع کر سکتے ہیں۔ + +### ٹیبلز {#tables} + +ہمیں آن چین [کئی ٹیبلز](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts) کی ضرورت ہے۔ + +- `Configuration`: یہ ٹیبل ایک سنگلٹن ہے، اس میں کوئی کلید نہیں ہے اور ایک ہی ریکارڈ ہے۔ اس کا استعمال گیم کی کنفیگریشن کی معلومات کو رکھنے کے لیے کیا جاتا ہے: + - `height`: ایک مائن فیلڈ کی اونچائی + - `width`: ایک مائن فیلڈ کی چوڑائی + - `numberOfBombs`: ہر مائن فیلڈ میں بموں کی تعداد + +- `VerifierAddress`: یہ ٹیبل بھی ایک سنگلٹن ہے۔ اس کا استعمال کنفیگریشن کے ایک حصے کو رکھنے کے لیے کیا جاتا ہے، یعنی ویریفائر کنٹریکٹ (`verifier`) کا ایڈریس۔ ہم اس معلومات کو `Configuration` ٹیبل میں رکھ سکتے تھے، لیکن یہ ایک مختلف کمپونینٹ، یعنی سرور کے ذریعہ سیٹ کیا جاتا ہے، لہذا اسے ایک الگ ٹیبل میں رکھنا آسان ہے۔ + +- `PlayerGame`: کلید کھلاڑی کا ایڈریس ہے۔ ڈیٹا یہ ہے: + + - `gameId`: 32 بائٹ کی ویلیو جو اس نقشے کا ہیش ہے جس پر کھلاڑی کھیل رہا ہے (گیم شناخت کنندہ)۔ + - `win`: ایک بولین جو یہ بتاتا ہے کہ آیا کھلاڑی نے گیم جیت لیا ہے۔ + - `lose`: ایک بولین جو یہ بتاتا ہے کہ آیا کھلاڑی نے گیم ہار دیا ہے۔ + - `digNumber`: گیم میں کامیاب کھدائیوں کی تعداد۔ + +- `GamePlayer`: یہ ٹیبل الٹی میپنگ رکھتا ہے، `gameId` سے کھلاڑی کے ایڈریس تک۔ + +- `Map`: کلید تین ویلیوز کا ایک ٹوپل ہے: + + - `gameId`: 32 بائٹ کی ویلیو جو اس نقشے کا ہیش ہے جس پر کھلاڑی کھیل رہا ہے (گیم شناخت کنندہ)۔ + - `x` کوآرڈینیٹ + - `y` کوآرڈینیٹ + + ویلیو ایک واحد نمبر ہے۔ اگر بم کا پتہ چلا تو یہ 255 ہے۔ ورنہ، یہ اس مقام کے ارد گرد بموں کی تعداد جمع ایک ہے۔ ہم صرف بموں کی تعداد کا استعمال نہیں کر سکتے، کیونکہ ڈیفالٹ طور پر EVM میں تمام اسٹوریج اور MUD میں تمام قطار کی ویلیوز صفر ہوتی ہیں۔ ہمیں "کھلاڑی نے ابھی تک یہاں کھدائی نہیں کی ہے" اور "کھلاڑی نے یہاں کھدائی کی، اور پایا کہ ارد گرد صفر بم ہیں" کے درمیان فرق کرنے کی ضرورت ہے۔ + +اس کے علاوہ، کلائنٹ اور سرور کے درمیان مواصلات آن چین کمپونینٹ کے ذریعے ہوتی ہے۔ یہ بھی ٹیبلز کا استعمال کرتے ہوئے نافذ کیا گیا ہے۔ + +- `PendingGame`: نیا گیم شروع کرنے کے لیے غیر خدمتی درخواستیں۔ +- `PendingDig`: ایک مخصوص گیم میں ایک مخصوص جگہ پر کھودنے کے لیے غیر خدمتی درخواستیں۔ یہ ایک [آف چین ٹیبل](https://mud.dev/store/tables#types-of-tables) ہے، جس کا مطلب ہے کہ یہ EVM اسٹوریج میں نہیں لکھا جاتا، یہ صرف ایونٹس کا استعمال کرتے ہوئے آف چین پڑھا جا سکتا ہے۔ + +### ایگزیکیوشن اور ڈیٹا فلو {#execution-data-flows} + +یہ فلو کلائنٹ، آن چین کمپونینٹ، اور سرور کے درمیان ایگزیکیوشن کو مربوط کرتے ہیں۔ + +#### ابتدا {#initialization-flow} + +جب آپ `mprocs` چلاتے ہیں، تو یہ اقدامات ہوتے ہیں: + +1. [`mprocs`](https://github.com/pvolok/mprocs) چار کمپونینٹس چلاتا ہے: + + - [Anvil](https://book.getfoundry.sh/anvil/)، جو ایک مقامی بلاک چین چلاتا ہے + - [کنٹریکٹس](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/contracts)، جو MUD کے لیے کنٹریکٹس کو کمپائل (اگر ضرورت ہو) اور ڈیپلائے کرتا ہے + - [کلائنٹ](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/client)، جو UI اور کلائنٹ کوڈ کو ویب براؤزرز پر سرو کرنے کے لیے [Vite](https://vitejs.dev/) چلاتا ہے۔ + - [سرور](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/server)، جو سرور کے اعمال انجام دیتا ہے + +2. `contracts` پیکج MUD کنٹریکٹس کو ڈیپلائے کرتا ہے اور پھر [ `PostDeploy.s.sol` اسکرپٹ](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol) چلاتا ہے۔ یہ اسکرپٹ کنفیگریشن سیٹ کرتا ہے۔ گٹ ہب سے کوڈ [ایک 10x5 مائن فیلڈ کی وضاحت کرتا ہے جس میں آٹھ مائنز ہیں](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol#L23)۔ + +3. [سرور](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts) [MUD کو سیٹ اپ کر کے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L6) شروع ہوتا ہے۔ دیگر چیزوں کے علاوہ، یہ ڈیٹا سنکرونائزیشن کو فعال کرتا ہے، تاکہ متعلقہ ٹیبلز کی ایک کاپی سرور کی میموری میں موجود ہو۔ + +4. سرور ایک فنکشن کو سبسکرائب کرتا ہے تاکہ [جب `Configuration` ٹیبل تبدیل ہو](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L23) تو اسے ایگزیکیوٹ کیا جائے۔ [یہ فنکشن](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L24-L168) `PostDeploy.s.sol` کے ایگزیکیوٹ ہونے اور ٹیبل میں ترمیم کرنے کے بعد کال کیا جاتا ہے۔ + +5. جب سرور انیشیئلائزیشن فنکشن کے پاس کنفیگریشن ہوتی ہے، تو [یہ `zkFunctions` کو کال کرتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L34-L35) تاکہ [سرور کے زیرو نالج حصے](#using-zokrates-from-typescript) کو انیشیئلائز کیا جا سکے۔ یہ اس وقت تک نہیں ہو سکتا جب تک کہ ہمیں کنفیگریشن نہ مل جائے کیونکہ زیرو نالج فنکشنز کو مائن فیلڈ کی چوڑائی اور اونچائی کو مستقل کے طور پر رکھنا ہوتا ہے۔ + +6. سرور کا زیرو نالج حصہ انیشیئلائز ہونے کے بعد، اگلا قدم [زیرو نالج ویریفیکیشن کنٹریکٹ کو بلاک چین پر ڈیپلائے کرنا](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L42-L53) اور MUD میں ویریفائی ایڈریس سیٹ کرنا ہے۔ + +7. آخر میں، ہم اپ ڈیٹس کو سبسکرائب کرتے ہیں تاکہ ہم دیکھ سکیں کہ جب کوئی کھلاڑی یا تو [نیا گیم شروع کرنے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71) کی درخواست کرتا ہے یا [موجودہ گیم میں کھدائی کرنے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73-L108) کی درخواست کرتا ہے۔ + +#### نیا گیم {#new-game-flow} + +جب کھلاڑی نیا گیم کی درخواست کرتا ہے تو یہ ہوتا ہے۔ + +1. اگر اس کھلاڑی کے لیے کوئی گیم جاری نہیں ہے، یا ایک ہے لیکن اس کا گیم آئی ڈی صفر ہے، تو کلائنٹ ایک [نیا گیم بٹن](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175) دکھاتا ہے۔ جب صارف اس بٹن کو دباتا ہے، تو [React `newGame` فنکشن](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L96) چلاتا ہے۔ + +2. [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L43-L46) ایک `System` کال ہے۔ MUD میں تمام کالز `World` کنٹریکٹ کے ذریعے روٹ کی جاتی ہیں، اور زیادہ تر معاملات میں آپ `__` کو کال کرتے ہیں۔ اس معاملے میں، کال `app__newGame` پر ہوتی ہے، جسے MUD پھر [`GameSystem` میں `newGame` پر](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L16-L22) روٹ کرتا ہے۔ + +3. آن چین فنکشن چیک کرتا ہے کہ کھلاڑی کا کوئی گیم جاری نہیں ہے، اور اگر نہیں ہے تو [درخواست کو `PendingGame` ٹیبل میں شامل کر دیتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L21)۔ + +4. سرور `PendingGame` میں تبدیلی کا پتہ لگاتا ہے اور [سبسکرائب شدہ فنکشن](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71) چلاتا ہے۔ یہ فنکشن [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L110-L114) کو کال کرتا ہے، جو بدلے میں [`createGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L116-L144) کو کال کرتا ہے۔ + +5. سب سے پہلے `createGame` [مناسب تعداد میں مائنز کے ساتھ ایک بے ترتیب نقشہ بناتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L120-L135)۔ پھر، یہ [`makeMapBorders`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L147-L166) کو خالی بارڈرز کے ساتھ ایک نقشہ بنانے کے لیے کال کرتا ہے، جو Zokrates کے لیے ضروری ہے۔ آخر میں، `createGame` [`calculateMapHash`](#calculateMapHash) کو کال کرتا ہے، تاکہ نقشے کا ہیش حاصل کیا جا سکے، جسے گیم آئی ڈی کے طور پر استعمال کیا جاتا ہے۔ + +6. `newGame` فنکشن نئے گیم کو `gamesInProgress` میں شامل کرتا ہے۔ + +7. سرور جو آخری کام کرتا ہے وہ [`app__newGameResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L38-L43) کو کال کرنا ہے، جو آن چین ہے۔ یہ فنکشن ایک مختلف `System` میں ہے، [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol)، تاکہ رسائی کنٹرول کو فعال کیا جا سکے۔ رسائی کنٹرول [MUD کنفیگریشن فائل](https://mud.dev/config) میں بیان کیا گیا ہے، [`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72)۔ + + رسائی کی فہرست صرف ایک ہی ایڈریس کو `System` کال کرنے کی اجازت دیتی ہے۔ یہ سرور فنکشنز تک رسائی کو ایک ہی ایڈریس تک محدود کرتا ہے، تاکہ کوئی بھی سرور کی نقالی نہ کر سکے۔ + +8. آن چین کمپونینٹ متعلقہ ٹیبلز کو اپ ڈیٹ کرتا ہے: + + - `PlayerGame` میں گیم بنائیں۔ + - `GamePlayer` میں الٹی میپنگ سیٹ کریں۔ + - `PendingGame` سے درخواست کو ہٹا دیں۔ + +9. سرور `PendingGame` میں تبدیلی کی نشاندہی کرتا ہے، لیکن کچھ نہیں کرتا کیونکہ [`wantsGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L58-L60) غلط ہے۔ + +10. کلائنٹ پر [`gameRecord`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L143-L148) کو کھلاڑی کے ایڈریس کے لیے `PlayerGame` انٹری پر سیٹ کیا جاتا ہے۔ جب `PlayerGame` تبدیل ہوتا ہے، تو `gameRecord` بھی تبدیل ہوتا ہے۔ + +11. اگر `gameRecord` میں کوئی ویلیو ہے، اور گیم جیتا یا ہارا نہیں گیا ہے، تو کلائنٹ [نقشہ دکھاتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190)۔ + +#### کھدائی {#dig-flow} + +1. کھلاڑی [نقشے کے سیل کے بٹن پر کلک کرتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L188)، جو [`dig` فنکشن](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L33-L36) کو کال کرتا ہے۔ یہ فنکشن [`dig` کو آن چین](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L24-L32) کال کرتا ہے۔ + +2. آن چین کمپونینٹ [کئی سینیٹی چیکس انجام دیتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L25-L30)، اور اگر کامیاب ہو جاتا ہے تو کھدائی کی درخواست کو [`PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L31) میں شامل کر دیتا ہے۔ + +3. سرور [`PendingDig` میں تبدیلی کا پتہ لگاتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73)۔ [اگر یہ درست ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L75-L84)، تو یہ [زیرو نالج کوڈ کو کال کرتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L86-L95) (نیچے بیان کیا گیا ہے) تاکہ نتیجہ اور اس کے درست ہونے کا ثبوت دونوں پیدا کیا جا سکے۔ + +4. [سرور](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L97-L107) آن چین [`digResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L45-L64) کو کال کرتا ہے۔ + +5. `digResponse` دو کام کرتا ہے۔ سب سے پہلے، یہ [زیرو نالج پروف](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L47-L61) کو چیک کرتا ہے۔ پھر، اگر پروف چیک ہو جاتا ہے، تو یہ [`processDigResult`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L67-L86) کو کال کرتا ہے تاکہ نتیجے کو دراصل پروسیس کیا جا سکے۔ + +6. `processDigResult` چیک کرتا ہے کہ آیا گیم [ہار](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L76-L78) گیا ہے یا [جیت](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L83-L86) لیا گیا ہے، اور [`Map`، یعنی آن چین نقشے کو اپ ڈیٹ کرتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L80)۔ + +7. کلائنٹ خود بخود اپ ڈیٹس اٹھاتا ہے اور [کھلاڑی کو دکھائے گئے نقشے کو اپ ڈیٹ کرتا ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190)، اور اگر قابل اطلاق ہو تو کھلاڑی کو بتاتا ہے کہ یہ جیت ہے یا ہار۔ + +## Zokrates کا استعمال {#using-zokrates} + +اوپر بیان کیے گئے فلو میں ہم نے زیرو نالج حصوں کو نظر انداز کر دیا، انہیں ایک بلیک باکس کے طور پر سمجھا۔ اب آئیے اسے کھول کر دیکھتے ہیں کہ وہ کوڈ کیسے لکھا گیا ہے۔ + +### نقشے کی ہیشنگ {#hashing-map} + +ہم [یہ جاوا اسکرپٹ کوڈ](https://github.com/ZK-Plus/ICBC24_Tutorial_Compute-Offchain-Verify-onchain/tree/solutions/exercise) [Poseidon](https://www.poseidon-hash.info) کو نافذ کرنے کے لیے استعمال کر سکتے ہیں، جو ہمارا استعمال کردہ Zokrates ہیش فنکشن ہے۔ تاہم، جبکہ یہ تیز ہوگا، یہ صرف Zokrates ہیش فنکشن کا استعمال کرنے سے زیادہ پیچیدہ بھی ہوگا۔ یہ ایک ٹیوٹوریل ہے، اور اس لیے کوڈ کو سادگی کے لیے بہتر بنایا گیا ہے، نہ کہ کارکردگی کے لیے۔ لہذا، ہمیں دو مختلف Zokrates پروگراموں کی ضرورت ہے، ایک صرف ایک نقشے (`hash`) کے ہیش کا حساب لگانے کے لیے اور دوسرا نقشے (`dig`) پر کسی مقام پر کھدائی کے نتیجے کا زیرو نالج پروف بنانے کے لیے۔ + +### ہیش فنکشن {#hash-function} + +یہ وہ فنکشن ہے جو ایک نقشے کے ہیش کا حساب لگاتا ہے۔ ہم اس کوڈ کا لائن بہ لائن جائزہ لیں گے۔ + +``` +import "hashes/poseidon/poseidon.zok" as poseidon; +import "utils/pack/bool/pack128.zok" as pack128; +``` + +یہ دو لائنیں [Zokrates اسٹینڈرڈ لائبریری](https://zokrates.github.io/toolbox/stdlib.html) سے دو فنکشن درآمد کرتی ہیں۔ [پہلا فنکشن](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/hashes/poseidon/poseidon.zok) ایک [Poseidon ہیش](https://www.poseidon-hash.info/) ہے۔ یہ [`field` عناصر](https://zokrates.github.io/language/types.html#field) کی ایک صف لیتا ہے اور ایک `field` لوٹاتا ہے۔ + +Zokrates میں فیلڈ عنصر عام طور پر 256 بٹس سے کم لمبا ہوتا ہے، لیکن زیادہ نہیں۔ کوڈ کو آسان بنانے کے لیے، ہم نقشے کو 512 بٹس تک محدود کرتے ہیں، اور چار فیلڈز کی ایک صف کو ہیش کرتے ہیں، اور ہر فیلڈ میں ہم صرف 128 بٹس استعمال کرتے ہیں۔ [ `pack128` فنکشن](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok) اس مقصد کے لیے 128 بٹس کی ایک صف کو `field` میں تبدیل کرتا ہے۔ + +``` + def hashMap(bool[${width+2}][${height+2}] map) -> field { +``` + +یہ لائن ایک فنکشن کی تعریف شروع کرتی ہے۔ `hashMap` کو `map` نامی ایک ہی پیرامیٹر ملتا ہے، جو ایک دو جہتی `bool`(ean) صف ہے۔ نقشے کا سائز `width+2` ضرب `height+2` ہے ان وجوہات کی بنا پر جو [نیچے بیان کی گئی ہیں](#why-map-border)۔ + +ہم `${width+2}` اور `${height+2}` استعمال کر سکتے ہیں کیونکہ Zokrates پروگرام اس ایپلیکیشن میں [ٹیمپلیٹ اسٹرنگز](https://www.w3schools.com/js/js_string_templates.asp) کے طور پر محفوظ ہیں۔ `${` اور `}` کے درمیان کوڈ کا جاوا اسکرپٹ کے ذریعے جائزہ لیا جاتا ہے، اور اس طرح پروگرام کو مختلف نقشے کے سائز کے لیے استعمال کیا جا سکتا ہے۔ نقشہ پیرامیٹر میں اس کے چاروں طرف ایک مقام چوڑا بارڈر ہے جس میں کوئی بم نہیں ہے، یہی وجہ ہے کہ ہمیں چوڑائی اور اونچائی میں دو کا اضافہ کرنے کی ضرورت ہے۔ + +واپسی کی قیمت ایک `field` ہے جس میں ہیش ہوتا ہے۔ + +``` + bool[512] mut map1d = [false; 512]; +``` + +نقشہ دو جہتی ہے۔ تاہم، `pack128` فنکشن دو جہتی صفوں کے ساتھ کام نہیں کرتا ہے۔ لہذا ہم پہلے نقشے کو 512 بائٹ کی صف میں ہموار کرتے ہیں، `map1d` کا استعمال کرتے ہوئے۔ ڈیفالٹ کے طور پر Zokrates متغیرات مستقل ہوتے ہیں، لیکن ہمیں اس صف کو ایک لوپ میں اقدار تفویض کرنے کی ضرورت ہے، لہذا ہم اسے [`mut`](https://zokrates.github.io/language/variables.html#mutability) کے طور پر بیان کرتے ہیں۔ + +ہمیں صف کو شروع کرنے کی ضرورت ہے کیونکہ Zokrates میں `undefined` نہیں ہے۔ تاثر `[false; 512]` کا مطلب ہے [512 `false` اقدار کی ایک صف](https://zokrates.github.io/language/types.html#declaration-and-initialization)۔ + +``` + u32 mut counter = 0; +``` + +ہمیں ان بٹس کے درمیان فرق کرنے کے لیے ایک کاؤنٹر کی بھی ضرورت ہے جو ہم نے `map1d` میں پہلے ہی بھر دیے ہیں اور جو نہیں بھرے۔ + +``` + for u32 x in 0..${width+2} { +``` + +یہ ہے کہ آپ Zokrates میں [`for` لوپ](https://zokrates.github.io/language/control_flow.html#for-loops) کا اعلان کیسے کرتے ہیں۔ ایک Zokrates `for` لوپ کی مقررہ حدود ہونی چاہئیں، کیونکہ جبکہ یہ ایک لوپ کی طرح لگتا ہے، کمپائلر دراصل اسے "کھول" دیتا ہے۔ تاثر `${width+2}` ایک کمپائل ٹائم مستقل ہے کیونکہ `width` ٹائپ اسکرپٹ کوڈ کے ذریعے کمپائلر کو کال کرنے سے پہلے سیٹ کیا جاتا ہے۔ + +``` + for u32 y in 0..${height+2} { + map1d[counter] = map[x][y]; + counter = counter+1; + } + } +``` + +نقشے میں ہر مقام کے لیے، اس قدر کو `map1d` صف میں ڈالیں اور کاؤنٹر میں اضافہ کریں۔ + +``` + field[4] hashMe = [ + pack128(map1d[0..128]), + pack128(map1d[128..256]), + pack128(map1d[256..384]), + pack128(map1d[384..512]) + ]; +``` + +`pack128` `map1d` سے چار `field` اقدار کی ایک صف بنانے کے لیے۔ Zokrates میں `array[a..b]` کا مطلب ہے صف کا وہ ٹکڑا جو `a` سے شروع ہوتا ہے اور `b-1` پر ختم ہوتا ہے۔ + +``` + return poseidon(hashMe); +} +``` + +اس صف کو ہیش میں تبدیل کرنے کے لیے `poseidon` کا استعمال کریں۔ + +### ہیش پروگرام {#hash-program} + +سرور کو گیم شناخت کنندہ بنانے کے لیے براہ راست `hashMap` کو کال کرنے کی ضرورت ہے۔ تاہم، Zokrates صرف `main` فنکشن کو شروع کرنے کے لیے کال کر سکتا ہے، لہذا ہم ایک `main` کے ساتھ ایک پروگرام بناتے ہیں جو ہیش فنکشن کو کال کرتا ہے۔ + +``` +${hashFragment} + +def main(bool[${width+2}][${height+2}] map) -> field { + return hashMap(map); +} +``` + +### کھدائی پروگرام {#dig-program} + +یہ ایپلیکیشن کا زیرو نالج حصہ کا دل ہے، جہاں ہم وہ ثبوت تیار کرتے ہیں جو کھدائی کے نتائج کی تصدیق کے لیے استعمال ہوتے ہیں۔ + +``` +${hashFragment} + +// مقام (x,y) میں مائنز کی تعداد +def map2mineCount(bool[${width+2}][${height+2}] map, u32 x, u32 y) -> u8 { + return if map[x+1][y+1] { 1 } else { 0 }; +} +``` + +#### نقشے کا بارڈر کیوں {#why-map-border} + +زیرو نالج پروف [حسابی سرکٹس](https://medium.com/web3studio/simple-explanations-of-arithmetic-circuits-and-zero-knowledge-proofs-806e59a79785) کا استعمال کرتے ہیں، جن میں `if` اسٹیٹمنٹ کا کوئی آسان مساوی نہیں ہوتا ہے۔ اس کے بجائے، وہ [مشروط آپریٹر](https://en.wikipedia.org/wiki/Ternary_conditional_operator) کے مساوی کا استعمال کرتے ہیں۔ اگر `a` صفر یا ایک ہو سکتا ہے، تو آپ `if a { b } else { c }` کا حساب `ab+(1-a)c` کے طور پر کر سکتے ہیں۔ + +اس کی وجہ سے، ایک Zokrates `if` اسٹیٹمنٹ ہمیشہ دونوں شاخوں کا جائزہ لیتا ہے۔ مثال کے طور پر، اگر آپ کے پاس یہ کوڈ ہے: + +``` +bool[5] arr = [false; 5]; +u32 index=10; +return if index>4 { 0 } else { arr[index] } +``` + +اس میں خرابی ہوگی، کیونکہ اسے `arr[10]` کا حساب لگانے کی ضرورت ہے، چاہے وہ قدر بعد میں صفر سے ضرب دی جائے۔ + +یہی وجہ ہے کہ ہمیں نقشے کے چاروں طرف ایک مقام چوڑا بارڈر کی ضرورت ہے۔ ہمیں کسی مقام کے ارد گرد مائنز کی کل تعداد کا حساب لگانے کی ضرورت ہے، اور اس کا مطلب ہے کہ ہمیں اس مقام سے ایک قطار اوپر اور نیچے، بائیں اور دائیں کو دیکھنے کی ضرورت ہے، جہاں ہم کھدائی کر رہے ہیں۔ جس کا مطلب ہے کہ وہ مقام Zokrates کو فراہم کردہ نقشے کی صف میں موجود ہونا چاہیے۔ + +``` +def main(private bool[${width+2}][${height+2}] map, u32 x, u32 y) -> (field, u8) { +``` + +ڈیفالٹ کے طور پر Zokrates ثبوتوں میں ان کے ان پٹ شامل ہوتے ہیں۔ یہ جاننا کوئی فائدہ مند نہیں ہے کہ کسی جگہ کے ارد گرد پانچ مائنز ہیں جب تک کہ آپ کو حقیقت میں یہ نہ معلوم ہو کہ وہ کون سی جگہ ہے (اور آپ اسے صرف اپنی درخواست سے نہیں ملا سکتے، کیونکہ تب پروور مختلف اقدار کا استعمال کر سکتا ہے اور آپ کو اس کے بارے میں نہیں بتا سکتا)۔ تاہم، ہمیں نقشے کو خفیہ رکھنے کی ضرورت ہے، جبکہ اسے Zokrates کو فراہم کرتے ہوئے۔ حل یہ ہے کہ ایک `private` پیرامیٹر کا استعمال کیا جائے، ایک ایسا جو ثبوت سے _ظاہر_ نہیں ہوتا ہے۔ + +اس سے غلط استعمال کا ایک اور راستہ کھلتا ہے۔ پروور صحیح کوآرڈینیٹس کا استعمال کر سکتا ہے، لیکن مقام کے ارد گرد کسی بھی تعداد میں مائنز کے ساتھ ایک نقشہ بنا سکتا ہے، اور ممکنہ طور پر خود مقام پر بھی۔ اس غلط استعمال کو روکنے کے لیے، ہم زیرو نالج پروف کو نقشے کا ہیش شامل کرتے ہیں، جو گیم شناخت کنندہ ہے۔ + +``` + return (hashMap(map), +``` + +یہاں واپسی کی قیمت ایک ٹوپل ہے جس میں نقشہ ہیش صف اور کھدائی کا نتیجہ شامل ہے۔ + +``` + if map2mineCount(map, x, y) > 0 { 0xFF } else { +``` + +اگر خود مقام پر کوئی بم ہو تو ہم 255 کو ایک خاص قدر کے طور پر استعمال کرتے ہیں۔ + +``` + map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) + + map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) + + map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1) + } + ); +} +``` + +اگر کھلاڑی نے کسی مائن کو نہیں مارا ہے، تو مقام کے ارد گرد کے علاقے کے لیے مائن کاؤنٹ شامل کریں اور اسے واپس کریں۔ + +### TypeScript سے Zokrates کا استعمال {#using-zokrates-from-typescript} + +Zokrates کا ایک کمانڈ لائن انٹرفیس ہے، لیکن اس پروگرام میں ہم اسے [TypeScript کوڈ](https://zokrates.github.io/toolbox/zokrates_js.html) میں استعمال کرتے ہیں۔ + +Zokrates تعریفوں پر مشتمل لائبریری کو [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts) کہا جاتا ہے۔ + +```typescript +import { initialize as zokratesInitialize } from "zokrates-js" +``` + +[Zokrates جاوا اسکرپٹ بائنڈنگز](https://zokrates.github.io/toolbox/zokrates_js.html) کو درآمد کریں۔ ہمیں صرف [`initialize`](https://zokrates.github.io/toolbox/zokrates_js.html#initialize) فنکشن کی ضرورت ہے کیونکہ یہ ایک وعدہ لوٹاتا ہے جو تمام Zokrates تعریفوں کو حل کرتا ہے۔ + +```typescript +export const zkFunctions = async (width: number, height: number) : Promise => { +``` + +Zokrates کی طرح، ہم بھی صرف ایک فنکشن برآمد کرتے ہیں، جو [غیر ہم آہنگ](https://www.w3schools.com/js/js_async.asp) بھی ہے۔ جب یہ بالآخر واپس آتا ہے، تو یہ کئی فنکشن فراہم کرتا ہے جیسا کہ ہم نیچے دیکھیں گے۔ + +```typescript +const zokrates = await zokratesInitialize() +``` + +Zokrates کو شروع کریں، لائبریری سے ہمیں ہر چیز حاصل کریں۔ + +```typescript +const hashFragment = ` + import "utils/pack/bool/pack128.zok" as pack128; + import "hashes/poseidon/poseidon.zok" as poseidon; + . + . + . + } + ` + +const hashProgram = ` + ${hashFragment} + . + . + . + ` + +const digProgram = ` + ${hashFragment} + . + . + . + ` +``` + +اگلا ہمارے پاس ہیش فنکشن اور دو Zokrates پروگرام ہیں جو ہم نے اوپر دیکھے۔ + +```typescript +const digCompiled = zokrates.compile(digProgram) +const hashCompiled = zokrates.compile(hashProgram) +``` + +یہاں ہم ان پروگراموں کو کمپائل کرتے ہیں۔ + +```typescript +// زیرو نالج تصدیق کے لیے کیز بنائیں۔ +// ایک پروڈکشن سسٹم پر آپ ایک سیٹ اپ تقریب کا استعمال کرنا چاہیں گے۔ +// (https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony). +const keySetupResults = zokrates.setup(digCompiled.program, "") +const verifierKey = keySetupResults.vk +const proverKey = keySetupResults.pk +``` + +ایک پروڈکشن سسٹم پر ہم ایک زیادہ پیچیدہ [سیٹ اپ تقریب](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony) کا استعمال کر سکتے ہیں، لیکن یہ ایک مظاہرے کے لیے کافی ہے۔ یہ کوئی مسئلہ نہیں ہے کہ صارفین پروور کی جان سکتے ہیں - وہ پھر بھی اسے چیزوں کو ثابت کرنے کے لیے استعمال نہیں کر سکتے جب تک کہ وہ سچ نہ ہوں۔ کیونکہ ہم اینٹروپی کی وضاحت کرتے ہیں (دوسرا پیرامیٹر، `""`)، نتائج ہمیشہ ایک جیسے ہی ہوں گے۔ + +**نوٹ:** Zokrates پروگراموں کی تالیف اور کلید کی تخلیق سست عمل ہیں۔ انہیں ہر بار دہرانے کی ضرورت نہیں ہے، صرف اس وقت جب نقشے کا سائز تبدیل ہوتا ہے۔ ایک پروڈکشن سسٹم پر آپ انہیں ایک بار کریں گے، اور پھر آؤٹ پٹ کو اسٹور کریں گے۔ میں یہاں صرف سادگی کی خاطر ایسا نہیں کر رہا ہوں۔ + +#### `calculateMapHash` {#calculateMapHash} + +```typescript +const calculateMapHash = function (hashMe: boolean[][]): string { + return ( + "0x" + + BigInt(zokrates.computeWitness(hashCompiled, [hashMe]).output.slice(1, -1)) + .toString(16) + .padStart(64, "0") + ) +} +``` + +[`computeWitness`](https://zokrates.github.io/toolbox/zokrates_js.html#computewitnessartifacts-args-options) فنکشن دراصل Zokrates پروگرام چلاتا ہے۔ یہ دو فیلڈز کے ساتھ ایک ڈھانچہ لوٹاتا ہے: `output`، جو ایک JSON سٹرنگ کے طور پر پروگرام کا آؤٹ پٹ ہے، اور `witness`، جو نتیجے کا زیرو نالج پروف بنانے کے لیے درکار معلومات ہے۔ یہاں ہمیں صرف آؤٹ پٹ کی ضرورت ہے۔ + +آؤٹ پٹ `"31337"` کی شکل میں ایک سٹرنگ ہے، جو کوٹیشن مارکس میں بند ایک اعشاریہ نمبر ہے۔ لیکن `viem` کے لیے ہمیں جو آؤٹ پٹ چاہیے وہ `0x60A7` کی شکل میں ایک ہیکساڈیسیمل نمبر ہے۔ لہذا ہم کوٹیشن مارکس کو ہٹانے کے لیے `.slice(1,-1)` کا استعمال کرتے ہیں اور پھر باقی سٹرنگ کو، جو ایک اعشاریہ نمبر ہے، ایک [`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt) میں تبدیل کرنے کے لیے `BigInt` کا استعمال کرتے ہیں۔ `.toString(16)` اس `BigInt` کو ایک ہیکساڈیسیمل سٹرنگ میں تبدیل کرتا ہے، اور `"0x"+` ہیکساڈیسیمل نمبروں کے لیے مارکر شامل کرتا ہے۔ + +```typescript +// کھودیں اور نتیجے کا زیرو نالج پروف لوٹائیں +// (سرور سائیڈ کوڈ) +``` + +زیرو نالج پروف میں عوامی ان پٹس (`x` اور `y`) اور نتائج (نقشے کا ہیش اور بموں کی تعداد) شامل ہیں۔ + +```typescript + const zkDig = function(map: boolean[][], x: number, y: number) : any { + if (x<0 || x>=width || y<0 || y>=height) + throw new Error("نقشے سے باہر کھدائی کی کوشش کی جا رہی ہے") +``` + +یہ چیک کرنا کہ آیا کوئی انڈیکس Zokrates میں حد سے باہر ہے، ایک مسئلہ ہے، لہذا ہم اسے یہاں کرتے ہیں۔ + +```typescript +const runResults = zokrates.computeWitness(digCompiled, [map, `${x}`, `${y}`]) +``` + +کھدائی پروگرام پر عمل کریں۔ + +```typescript + const proof = zokrates.generateProof( + digCompiled.program, + runResults.witness, + proverKey) + + return proof + } +``` + +[`generateProof`](https://zokrates.github.io/toolbox/zokrates_js.html#generateproofprogram-witness-provingkey-entropy) کا استعمال کریں اور ثبوت واپس کریں۔ + +```typescript +const solidityVerifier = ` + // نقشے کا سائز: ${width} x ${height} + \n${zokrates.exportSolidityVerifier(verifierKey)} + ` +``` + +ایک Solidity ویریفائر، ایک سمارٹ کنٹریکٹ جسے ہم بلاک چین پر تعینات کر سکتے ہیں اور `digCompiled.program` کے ذریعے تیار کردہ ثبوتوں کی تصدیق کے لیے استعمال کر سکتے ہیں۔ + +```typescript + return { + zkDig, + calculateMapHash, + solidityVerifier, + } +} +``` + +آخر میں، ہر وہ چیز واپس کریں جس کی دوسرے کوڈ کو ضرورت ہو سکتی ہے۔ + +## سیکیورٹی ٹیسٹ {#security-tests} + +سیکیورٹی ٹیسٹ اہم ہیں کیونکہ ایک فنکشنلٹی بگ بالآخر خود کو ظاہر کر دے گا۔ لیکن اگر ایپلیکیشن غیر محفوظ ہے، تو یہ ممکنہ طور پر ایک طویل عرصے تک چھپی رہے گی اس سے پہلے کہ یہ کسی کے دھوکہ دہی اور دوسروں سے تعلق رکھنے والے وسائل سے بچ نکلنے سے ظاہر ہو۔ + +### اجازتیں {#permissions} + +اس گیم میں ایک مراعات یافتہ ادارہ ہے، سرور۔ یہ واحد صارف ہے جسے [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol) میں فنکشنز کو کال کرنے کی اجازت ہے۔ ہم [`cast`](https://book.getfoundry.sh/cast/) کا استعمال کر سکتے ہیں تاکہ یہ تصدیق کی جا سکے کہ اجازت یافتہ فنکشنز کی کالز صرف سرور اکاؤنٹ کے طور پر ہی کی جا سکتی ہیں۔ + +[سرور کی نجی کلید `setupNetwork.ts` میں ہے](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/mud/setupNetwork.ts#L52)۔ + +1. `anvil` (بلاک چین) چلانے والے کمپیوٹر پر، یہ ماحولیاتی متغیرات سیٹ کریں۔ + + ```sh copy + WORLD_ADDRESS=0x8d8b6b8414e1e3dcfd4168561b9be6bd3bf6ec4b + UNAUTHORIZED_KEY=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a + AUTHORIZED_KEY=0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d + ``` + +2. `cast` کا استعمال کریں تاکہ تصدیق کنندہ کا پتہ ایک غیر مجاز پتے کے طور پر سیٹ کرنے کی کوشش کی جا سکے۔ + + ```sh copy + cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $UNAUTHORIZED_KEY + ``` + + نہ صرف `cast` ایک ناکامی کی اطلاع دیتا ہے، بلکہ آپ براؤزر پر گیم میں **MUD Dev Tools** کھول سکتے ہیں، **ٹیبلز** پر کلک کر سکتے ہیں، اور **app\_\_VerifierAddress** کو منتخب کر سکتے ہیں۔ دیکھیں کہ پتہ صفر نہیں ہے۔ + +3. ویریفائر ایڈریس کو سرور کے ایڈریس کے طور پر سیٹ کریں۔ + + ```sh copy + cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $AUTHORIZED_KEY + ``` + + **app\_\_VerifiedAddress** میں پتہ اب صفر ہونا چاہیے۔ + +ایک ہی `System` میں تمام MUD فنکشنز ایک ہی ایکسیس کنٹرول سے گزرتے ہیں، لہذا میں اس ٹیسٹ کو کافی سمجھتا ہوں۔ اگر آپ نہیں کرتے ہیں، تو آپ [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol) میں دیگر فنکشنز کو چیک کر سکتے ہیں۔ + +### زیرو نالج کے غلط استعمال {#zero-knowledge-abuses} + +Zokrates کی تصدیق کے لیے ریاضی اس ٹیوٹوریل (اور میری صلاحیتوں) کے دائرہ سے باہر ہے۔ تاہم، ہم زیرو نالج کوڈ پر مختلف چیک چلا سکتے ہیں تاکہ یہ تصدیق کی جا سکے کہ اگر اسے صحیح طریقے سے نہیں کیا گیا تو یہ ناکام ہو جاتا ہے۔ ان تمام ٹیسٹوں کے لیے ہمیں [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts) کو تبدیل کرنے اور پوری ایپلیکیشن کو دوبارہ شروع کرنے کی ضرورت ہوگی۔ سرور پروسیس کو دوبارہ شروع کرنا کافی نہیں ہے، کیونکہ یہ ایپلیکیشن کو ایک ناممکن حالت میں ڈال دیتا ہے (کھلاڑی کا ایک گیم جاری ہے، لیکن گیم اب سرور کے لیے دستیاب نہیں ہے)۔ + +#### غلط جواب {#wrong-answer} + +سب سے آسان امکان زیرو نالج پروف میں غلط جواب فراہم کرنا ہے۔ ایسا کرنے کے لیے، ہم `zkDig` کے اندر جاتے ہیں اور [لائن 91 میں ترمیم کرتے ہیں](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L91): + +```ts +proof.inputs[3] = "0x" + "1".padStart(64, "0") +``` + +اس کا مطلب ہے کہ ہم ہمیشہ دعویٰ کریں گے کہ ایک بم ہے، چاہے صحیح جواب کچھ بھی ہو۔ اس ورژن کے ساتھ کھیلنے کی کوشش کریں، اور آپ `pnpm dev` اسکرین کے **سرور** ٹیب میں یہ خرابی دیکھیں گے: + +``` + cause: { + code: 3, + message: 'execution reverted: revert: Zero knowledge verification fail', + data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000 +00000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6 +e206661696c' + }, +``` + +تو اس قسم کی دھوکہ دہی ناکام ہو جاتی ہے۔ + +#### غلط ثبوت {#wrong-proof} + +کیا ہوتا ہے اگر ہم صحیح معلومات فراہم کریں، لیکن ثبوت کا ڈیٹا غلط ہو؟ اب، لائن 91 کو اس سے بدل دیں: + +```ts +proof.proof = { + a: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + b: [ + ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + ], + c: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], +} +``` + +یہ اب بھی ناکام رہتا ہے، لیکن اب یہ بغیر کسی وجہ کے ناکام ہوجاتا ہے کیونکہ یہ ویریفائر کال کے دوران ہوتا ہے۔ + +### ایک صارف زیرو ٹرسٹ کوڈ کی تصدیق کیسے کر سکتا ہے؟ {#user-verify-zero-trust} + +اسمارٹ معاہدوں کی تصدیق کرنا نسبتاً آسان ہے۔ عام طور پر، ڈیولپر سورس کوڈ کو ایک بلاک ایکسپلورر پر شائع کرتا ہے، اور بلاک ایکسپلورر اس بات کی تصدیق کرتا ہے کہ سورس کوڈ [معاہدے کی تعیناتی کے لین دین](/developers/docs/smart-contracts/deploying/) میں کوڈ کو کمپائل کرتا ہے۔ MUD `System`s کے معاملے میں یہ [تھوڑا زیادہ پیچیدہ](https://mud.dev/cli/verify) ہے، لیکن زیادہ نہیں۔ + +یہ زیرو نالج کے ساتھ زیادہ مشکل ہے۔ ویریفائر میں کچھ مستقل شامل ہوتے ہیں اور ان پر کچھ حسابات چلاتے ہیں۔ یہ آپ کو نہیں بتاتا کہ کیا ثابت کیا جا رہا ہے۔ + +```solidity + function verifyingKey() pure internal returns (VerifyingKey memory vk) { + vk.alpha = Pairing.G1Point(uint256(0x0f43f4fe7b5c2326fed4ac6ed2f4003ab9ab4ea6f667c2bdd77afb068617ee16), uint256(0x25a77832283f9726935219b5f4678842cda465631e72dbb24708a97ba5d0ce6f)); + vk.beta = Pairing.G2Point([uint256(0x2cebd0fbd21aca01910581537b21ae4fed46bc0e524c055059aa164ba0a6b62b), uint256(0x18fd4a7bc386cf03a95af7163d5359165acc4e7961cb46519e6d9ee4a1e2b7e9)], [uint256(0x11449dee0199ef6d8eebfe43b548e875c69e7ce37705ee9a00c81fe52f11a009), uint256(0x066d0c83b32800d3f335bb9e8ed5e2924cf00e77e6ec28178592eac9898e1a00)]); +``` + +حل، کم از کم جب تک بلاک ایکسپلوررز اپنے صارف انٹرفیس میں Zokrates کی تصدیق شامل نہیں کر لیتے، یہ ہے کہ ایپلیکیشن ڈیولپرز Zokrates پروگراموں کو دستیاب کرائیں، اور کم از کم کچھ صارفین انہیں مناسب تصدیقی کلید کے ساتھ خود کمپائل کریں۔ + +ایسا کرنے کے لیے: + +1. [Zokrates انسٹال کریں](https://zokrates.github.io/gettingstarted.html)۔ + +2. ایک فائل بنائیں، `dig.zok`، Zokrates پروگرام کے ساتھ۔ نیچے دیا گیا کوڈ یہ فرض کرتا ہے کہ آپ نے اصل نقشے کا سائز، 10x5، رکھا ہے۔ + + ```zokrates + import "utils/pack/bool/pack128.zok" as pack128; + import "hashes/poseidon/poseidon.zok" as poseidon; + + def hashMap(bool[12][7] map) -> field { + bool[512] mut map1d = [false; 512]; + u32 mut counter = 0; + + for u32 x in 0..12 { + for u32 y in 0..7 { + map1d[counter] = map[x][y]; + counter = counter+1; + } + } + + field[4] hashMe = [ + pack128(map1d[0..128]), + pack128(map1d[128..256]), + pack128(map1d[256..384]), + pack128(map1d[384..512]) + ]; + + return poseidon(hashMe); + } + + + // The number of mines in location (x,y) + def map2mineCount(bool[12][7] map, u32 x, u32 y) -> u8 { + return if map[x+1][y+1] { 1 } else { 0 }; + } + + def main(private bool[12][7] map, u32 x, u32 y) -> (field, u8) { + return (hashMap(map) , + if map2mineCount(map, x, y) > 0 { 0xFF } else { + map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) + + map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) + + map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1) + } + ); + } + ``` + +3. Zokrates کوڈ کو کمپائل کریں اور تصدیقی کلید بنائیں۔ تصدیقی کلید اسی اینٹروپی کے ساتھ بنانی ہوگی جو اصل سرور میں استعمال کی گئی تھی، [اس معاملے میں ایک خالی سٹرنگ](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L67)۔ + + ```sh copy + zokrates compile --input dig.zok + zokrates setup -e "" + ``` + +4. اپنا Solidity ویریفائر خود بنائیں، اور تصدیق کریں کہ یہ بلاک چین پر موجود ویریفائر سے فنکشنل طور پر یکساں ہے (سرور ایک تبصرہ شامل کرتا ہے، لیکن یہ اہم نہیں ہے)۔ + + ```sh copy + zokrates export-verifier + diff verifier.sol ~/20240901-secret-state/packages/contracts/src/verifier.sol + ``` + +## ڈیزائن کے فیصلے {#design} + +کسی بھی کافی پیچیدہ ایپلیکیشن میں مسابقتی ڈیزائن کے اہداف ہوتے ہیں جن کے لیے سمجھوتہ کی ضرورت ہوتی ہے۔ آئیے کچھ سمجھوتوں کو دیکھتے ہیں اور یہ کہ موجودہ حل دوسرے اختیارات سے کیوں بہتر ہے۔ + +### زیرو نالج کیوں {#why-zero-knowledge} + +مائن سویپر کے لیے آپ کو حقیقت میں زیرو نالج کی ضرورت نہیں ہے۔ سرور ہمیشہ نقشہ رکھ سکتا ہے، اور پھر گیم ختم ہونے پر اس سب کو ظاہر کر سکتا ہے۔ پھر، گیم کے اختتام پر، سمارٹ کنٹریکٹ نقشے کے ہیش کا حساب لگا سکتا ہے، تصدیق کر سکتا ہے کہ یہ میل کھاتا ہے، اور اگر ایسا نہیں ہوتا ہے تو سرور کو سزا دے سکتا ہے یا گیم کو مکمل طور پر نظر انداز کر سکتا ہے۔ + +میں نے یہ آسان حل استعمال نہیں کیا کیونکہ یہ صرف اچھی طرح سے متعین اختتامی حالت والے مختصر گیمز کے لیے کام کرتا ہے۔ جب ایک گیم ممکنہ طور پر لامحدود ہو (جیسے کہ [خود مختار دنیاؤں](https://0xparc.org/blog/autonomous-worlds) کے معاملے میں)، آپ کو ایک ایسے حل کی ضرورت ہے جو حالت کو _ظاہر کیے بغیر_ ثابت کرے۔ + +ایک ٹیوٹوریل کے طور پر اس مضمون کو ایک مختصر گیم کی ضرورت تھی جو سمجھنے میں آسان ہو، لیکن یہ تکنیک طویل گیمز کے لیے سب سے زیادہ مفید ہے۔ + +### Zokrates کیوں؟ {#why-zokrates} + +[Zokrates](https://zokrates.github.io/) واحد زیرو نالج لائبریری دستیاب نہیں ہے، لیکن یہ ایک عام، [امپیریٹو](https://en.wikipedia.org/wiki/Imperative_programming) پروگرامنگ زبان کی طرح ہے اور بولین متغیرات کو سپورٹ کرتی ہے۔ + +آپ کی ایپلیکیشن کے لیے، مختلف ضروریات کے ساتھ، آپ [Circum](https://docs.circom.io/getting-started/installation/) یا [Cairo](https://www.cairo-lang.org/tutorials/getting-started-with-cairo/) کا استعمال کرنا پسند کر سکتے ہیں۔ + +### Zokrates کو کب کمپائل کریں {#when-compile-zokrates} + +اس پروگرام میں ہم Zokrates پروگراموں کو [ہر بار سرور شروع ہونے پر](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L60-L61) کمپائل کرتے ہیں۔ یہ واضح طور پر وسائل کا ضیاع ہے، لیکن یہ ایک ٹیوٹوریل ہے، جو سادگی کے لیے بہتر بنایا گیا ہے۔ + +اگر میں پروڈکشن لیول کی ایپلیکیشن لکھ رہا ہوتا، تو میں چیک کرتا کہ آیا میرے پاس اس مائن فیلڈ سائز پر کمپائل شدہ Zokrates پروگراموں کے ساتھ ایک فائل ہے، اور اگر ایسا ہے تو اسے استعمال کرتا۔ یہی بات آن چین پر ویریفائر کنٹریکٹ کی تعیناتی پر بھی لاگو ہوتی ہے۔ + +### ویریفائر اور پروور کیز بنانا {#key-creation} + +[کلید کی تخلیق](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L63-L69) ایک اور خالص حساب ہے جسے ایک دیے گئے مائن فیلڈ سائز کے لیے ایک سے زیادہ بار کرنے کی ضرورت نہیں ہے۔ ایک بار پھر، یہ صرف سادگی کی خاطر ایک بار کیا جاتا ہے۔ + +مزید برآں، ہم [ایک سیٹ اپ تقریب](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony) کا استعمال کر سکتے ہیں۔ ایک سیٹ اپ تقریب کا فائدہ یہ ہے کہ آپ کو زیرو نالج پروف پر دھوکہ دینے کے لیے یا تو اینٹروپی یا ہر شریک سے کچھ درمیانی نتیجہ کی ضرورت ہوتی ہے۔ اگر کم از کم ایک تقریب کا شریک ایماندار ہے اور اس معلومات کو حذف کر دیتا ہے، تو زیرو نالج پروف کچھ حملوں سے محفوظ ہیں۔ تاہم، یہ تصدیق کرنے کا _کوئی میکانزم_ نہیں ہے کہ معلومات کو ہر جگہ سے حذف کر دیا گیا ہے۔ اگر زیرو نالج پروف انتہائی اہم ہیں، تو آپ سیٹ اپ تقریب میں حصہ لینا چاہتے ہیں۔ + +یہاں ہم [پرپیچوئل پاورز آف ٹاؤ](https://github.com/privacy-scaling-explorations/perpetualpowersoftau) پر انحصار کرتے ہیں، جس میں درجنوں شرکاء تھے۔ یہ شاید کافی محفوظ ہے، اور بہت آسان ہے۔ ہم کلید کی تخلیق کے دوران اینٹروپی بھی شامل نہیں کرتے ہیں، جس سے صارفین کے لیے [زیرو نالج کنفیگریشن کی تصدیق کرنا](#user-verify-zero-trust) آسان ہو جاتا ہے۔ + +### کہاں تصدیق کریں {#where-verification} + +ہم زیرو نالج پروف کو یا تو آن چین (جس پر گیس خرچ ہوتی ہے) یا کلائنٹ میں ( [`verify`](https://zokrates.github.io/toolbox/zokrates_js.html#verifyverificationkey-proof) کا استعمال کرتے ہوئے) تصدیق کر سکتے ہیں۔ میں نے پہلا انتخاب کیا، کیونکہ یہ آپ کو [ویریفائر کی تصدیق کرنے](#user-verify-zero-trust) کی اجازت دیتا ہے اور پھر اس بات پر بھروسہ کرتا ہے کہ جب تک اس کے لیے کنٹریکٹ کا پتہ وہی رہتا ہے، اس میں کوئی تبدیلی نہیں آتی ہے۔ اگر کلائنٹ پر تصدیق کی جاتی، تو آپ کو ہر بار کلائنٹ ڈاؤن لوڈ کرنے پر موصول ہونے والے کوڈ کی تصدیق کرنی پڑتی۔ + +نیز، جبکہ یہ گیم سنگل پلیئر ہے، بہت سے بلاک چین گیمز ملٹی پلیئر ہیں۔ آن چین تصدیق کا مطلب ہے کہ آپ صرف ایک بار زیرو نالج پروف کی تصدیق کرتے ہیں۔ اسے کلائنٹ میں کرنے کے لیے ہر کلائنٹ کو آزادانہ طور پر تصدیق کرنے کی ضرورت ہوگی۔ + +### نقشے کو TypeScript یا Zokrates میں فلیٹ کریں؟ {#where-flatten} + +عام طور پر، جب پروسیسنگ یا تو TypeScript یا Zokrates میں کی جا سکتی ہے، تو اسے TypeScript میں کرنا بہتر ہے، جو بہت تیز ہے، اور زیرو نالج پروف کی ضرورت نہیں ہے۔ یہی وجہ ہے، مثال کے طور پر، کہ ہم Zokrates کو ہیش فراہم نہیں کرتے ہیں اور اسے یہ تصدیق کرنے کے لیے کہتے ہیں کہ یہ درست ہے۔ ہیشنگ کو Zokrates کے اندر کرنا پڑتا ہے، لیکن واپس کیے گئے ہیش اور آن چین ہیش کے درمیان مماثلت اس کے باہر ہو سکتی ہے۔ + +تاہم، ہم اب بھی [Zokrates میں نقشے کو فلیٹ کرتے ہیں](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L15-L20)، جبکہ ہم اسے TypeScript میں کر سکتے تھے۔ وجہ یہ ہے کہ دوسرے اختیارات، میری رائے میں، بدتر ہیں۔ + +- Zokrates کوڈ کو بولین کی ایک جہتی صف فراہم کریں، اور دو جہتی نقشہ حاصل کرنے کے لیے `x*(height+2) + +y` جیسے تاثر کا استعمال کریں۔ یہ [کوڈ](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L44-L47) کو قدرے زیادہ پیچیدہ بنا دے گا، لہذا میں نے فیصلہ کیا کہ کارکردگی کا فائدہ ایک ٹیوٹوریل کے لیے اس کے قابل نہیں ہے۔ + +- Zokrates کو ایک جہتی صف اور دو جہتی صف دونوں بھیجیں۔ تاہم، اس حل سے ہمیں کچھ حاصل نہیں ہوتا۔ Zokrates کوڈ کو یہ تصدیق کرنی ہوگی کہ اسے فراہم کردہ ایک جہتی صف واقعی دو جہتی صف کی صحیح نمائندگی ہے۔ تو کارکردگی میں کوئی فائدہ نہیں ہوگا۔ + +- Zokrates میں دو جہتی صف کو فلیٹ کریں۔ یہ سب سے آسان آپشن ہے، لہذا میں نے اسے منتخب کیا۔ + +### نقشوں کو کہاں اسٹور کریں {#where-store-maps} + +اس ایپلیکیشن میں [`gamesInProgress`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L20) صرف میموری میں ایک متغیر ہے۔ اس کا مطلب ہے کہ اگر آپ کا سرور مر جاتا ہے اور اسے دوبارہ شروع کرنے کی ضرورت ہے، تو اس میں محفوظ تمام معلومات ضائع ہو جاتی ہیں۔ نہ صرف کھلاڑی اپنا کھیل جاری رکھنے سے قاصر ہیں، بلکہ وہ نیا کھیل بھی شروع نہیں کر سکتے کیونکہ آن چین جزو سوچتا ہے کہ ان کا ابھی بھی ایک کھیل جاری ہے۔ + +یہ واضح طور پر ایک پروڈکشن سسٹم کے لیے خراب ڈیزائن ہے، جس میں آپ اس معلومات کو ایک ڈیٹا بیس میں محفوظ کریں گے۔ میں نے یہاں ایک متغیر کا استعمال صرف اس لیے کیا کیونکہ یہ ایک ٹیوٹوریل ہے اور سادگی سب سے اہم غور ہے۔ + +## نتیجہ: کن حالات میں یہ مناسب تکنیک ہے؟ {#conclusion} + +تو، اب آپ جانتے ہیں کہ ایک سرور کے ساتھ ایک گیم کیسے لکھنا ہے جو خفیہ حالت کو اسٹور کرتا ہے جو آن چین سے تعلق نہیں رکھتا۔ لیکن کن معاملات میں آپ کو ایسا کرنا چاہیے؟ دو اہم غور ہیں۔ + +- _طویل چلنے والا کھیل_: [جیسا کہ اوپر ذکر کیا گیا ہے](#why-zero-knowledge)، ایک مختصر کھیل میں آپ صرف کھیل ختم ہونے کے بعد حالت کو شائع کر سکتے ہیں اور پھر ہر چیز کی تصدیق کروا سکتے ہیں۔ لیکن یہ ایک آپشن نہیں ہے جب کھیل میں لمبا یا غیر معینہ وقت لگتا ہے، اور حالت کو خفیہ رکھنے کی ضرورت ہے۔ + +- _کچھ مرکزیت قابل قبول_: زیرو نالج پروف سالمیت کی تصدیق کر سکتے ہیں، کہ کوئی ادارہ نتائج کو جعلی نہیں بنا رہا ہے۔ جو وہ نہیں کر سکتے وہ یہ یقینی بنانا ہے کہ ادارہ اب بھی دستیاب ہوگا اور پیغامات کا جواب دے گا۔ ان حالات میں جہاں دستیابی کو بھی غیر مرکزی کرنے کی ضرورت ہے، زیرو نالج پروف ایک کافی حل نہیں ہیں، اور آپ کو [ملٹی پارٹی کمپیوٹیشن](https://en.wikipedia.org/wiki/Secure_multi-party_computation) کی ضرورت ہے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ + +### اعترافات {#acknowledgements} + +- الوارو الونسو نے اس مضمون کا ایک مسودہ پڑھا اور Zokrates کے بارے میں میری کچھ غلط فہمیوں کو دور کیا۔ + +کوئی بھی باقی غلطیاں میری ذمہ داری ہیں۔ diff --git a/public/content/translations/ur/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/ur/developers/tutorials/secure-development-workflow/index.md new file mode 100644 index 00000000000..23660856a59 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/secure-development-workflow/index.md @@ -0,0 +1,52 @@ +--- +title: "اسمارٹ کنٹریکٹ سیکورٹی چیک لسٹ" +description: "محفوظ اسمارٹ کنٹریکٹس لکھنے کے لیے ایک تجویز کردہ ورک فلو" +author: "Trailofbits" +tags: [ "اسمارٹ معاہدات", "سیکورٹی", "solidity" ] +skill: intermediate +lang: ur-in +published: 2020-09-07 +source: Building secure contracts +sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md +--- + +## اسمارٹ کنٹریکٹ ڈیولپمنٹ چیک لسٹ {#smart-contract-development-checklist} + +یہاں ایک اعلیٰ سطحی عمل ہے جس پر عمل کرنے کی ہم تجویز کرتے ہیں جب آپ اپنے اسمارٹ کنٹریکٹس لکھتے ہیں۔ + +معلوم سیکورٹی مسائل کے لیے چیک کریں: + +- [Slither](https://github.com/crytic/slither) کے ساتھ اپنے کنٹریکٹس کا جائزہ لیں۔ اس میں عام کمزوریوں کے لیے 40 سے زیادہ بلٹ ان ڈیٹیکٹرز ہیں۔ اسے نئے کوڈ کے ساتھ ہر چیک ان پر چلائیں اور یقینی بنائیں کہ اسے ایک کلین رپورٹ ملے (یا بعض مسائل کو خاموش کرنے کے لیے ٹرائج موڈ استعمال کریں)۔ +- [Crytic](https://crytic.io/) کے ساتھ اپنے کنٹریکٹس کا جائزہ لیں۔ یہ 50 ایسے مسائل کی جانچ کرتا ہے جو Slither نہیں کرتا۔ Crytic، GitHub پر Pull Requests میں سیکورٹی مسائل کو آسانی سے سامنے لا کر آپ کی ٹیم کو ایک دوسرے کے کام سے باخبر رہنے میں بھی مدد کر سکتا ہے۔ + +اپنے کنٹریکٹ کے خصوصی فیچرز پر غور کریں: + +- کیا آپ کے کنٹریکٹس اپ گریڈ کے قابل ہیں؟ [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) یا [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/) کے ساتھ خامیوں کے لیے اپنے اپ گریڈیبلٹی کوڈ کا جائزہ لیں۔ ہم نے 17 ایسے طریقوں کو دستاویز کیا ہے جن سے اپ گریڈز غلط ہو سکتے ہیں۔ +- کیا آپ کے کنٹریکٹس ERCs کے مطابق ہونے کا دعویٰ کرتے ہیں؟ انھیں [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) سے چیک کریں۔ یہ ٹول چھ عام اسپیکس سے انحراف کو فوری طور پر شناخت کرتا ہے۔ +- کیا آپ تھرڈ پارٹی ٹوکنز کے ساتھ انٹیگریٹ کرتے ہیں؟ بیرونی کنٹریکٹس پر انحصار کرنے سے پہلے ہمارے [ٹوکن انٹیگریشن چیک لسٹ](/developers/tutorials/token-integration-checklist/) کا جائزہ لیں۔ + +اپنے کوڈ کے اہم سیکورٹی فیچرز کا بصری طور پر معائنہ کریں: + +- Slither کے [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) پرنٹر کا جائزہ لیں۔ نادانستہ شیڈونگ اور C3 لینیئرائزیشن کے مسائل سے بچیں۔ +- Slither کے [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) پرنٹر کا جائزہ لیں۔ یہ فنکشن کی ویزیبلٹی اور رسائی کے کنٹرولز کو رپورٹ کرتا ہے۔ +- Slither کے [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) پرنٹر کا جائزہ لیں۔ یہ اسٹیٹ ویری ایبلز پر رسائی کے کنٹرولز کو رپورٹ کرتا ہے۔ + +اہم سیکورٹی پراپرٹیز کو دستاویز کریں اور ان کا جائزہ لینے کے لیے آٹومیٹڈ ٹیسٹ جنریٹرز کا استعمال کریں: + +- [اپنے کوڈ کے لیے سیکورٹی پراپرٹیز کو دستاویز کرنا](/developers/tutorials/guide-to-smart-contract-security-tools/) سیکھیں۔ پہلے تو یہ مشکل ہے، لیکن یہ ایک اچھا نتیجہ حاصل کرنے کے لیے سب سے اہم سرگرمی ہے۔ یہ اس ٹیوٹوریل میں کسی بھی جدید تکنیک کو استعمال کرنے کے لیے ایک پیشگی شرط بھی ہے۔ +- Solidity میں سیکورٹی پراپرٹیز کی وضاحت کریں، [Echidna](https://github.com/crytic/echidna) اور [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html) کے ساتھ استعمال کے لیے۔ اپنی اسٹیٹ مشین، رسائی کے کنٹرولز، حسابی کارروائیوں، بیرونی تعاملات، اور معیارات کی مطابقت پر توجہ دیں۔ +- [Slither's Python API](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) کے ساتھ سیکورٹی پراپرٹیز کی وضاحت کریں۔ انہیریٹنس، ویری ایبل ڈیپنڈنسیس، رسائی کے کنٹرولز، اور دیگر ساختی مسائل پر توجہ دیں۔ +- [Crytic](https://crytic.io) کے ساتھ ہر کمٹ پر اپنے پراپرٹی ٹیسٹ چلائیں۔ Crytic سیکورٹی پراپرٹی ٹیسٹ کو استعمال اور ان کا جائزہ لے سکتا ہے تاکہ آپ کی ٹیم میں ہر کوئی آسانی سے دیکھ سکے کہ وہ GitHub پر پاس ہو گئے ہیں۔ ناکام ٹیسٹ کمٹس کو بلاک کر سکتے ہیں۔ + +آخر میں، ان مسائل سے آگاہ رہیں جنہیں آٹومیٹڈ ٹولز آسانی سے نہیں ڈھونڈ سکتے: + +- پرائیویسی کی کمی: جب آپ کے ٹرانزیکشنز پول میں قطار میں ہوتے ہیں تو ہر کوئی انہیں دیکھ سکتا ہے +- فرنٹ رننگ ٹرانزیکشنز +- کرپٹوگرافک آپریشنز +- بیرونی DeFi کمپونینٹس کے ساتھ پرخطر تعاملات + +## مدد طلب کریں {#ask-for-help} + +[Ethereum آفس آورز](https://calendly.com/dan-trailofbits/office-hours) ہر منگل کی سہ پہر کو ہوتے ہیں۔ یہ 1 گھنٹے کے، 1-آن-1 سیشنز سیکورٹی کے بارے میں آپ کے کسی بھی سوال کو پوچھنے، ہمارے ٹولز کا استعمال کرتے ہوئے ٹربل شوٹ کرنے، اور ماہرین سے اپنے موجودہ نقطہ نظر کے بارے میں فیڈبیک حاصل کرنے کا ایک موقع ہیں۔ ہم اس گائیڈ پر کام کرنے میں آپ کی مدد کریں گے۔ + +ہمارے Slack میں شامل ہوں: [Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw)۔ اگر آپ کے کوئی سوالات ہیں تو ہم #crytic اور #ethereum چینلز میں ہمیشہ دستیاب ہیں۔ diff --git a/public/content/translations/ur/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/ur/developers/tutorials/send-token-ethersjs/index.md new file mode 100644 index 00000000000..6e9e1706ed3 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/send-token-ethersjs/index.md @@ -0,0 +1,210 @@ +--- +title: "ethers.js کا استعمال کرتے ہوئے ٹوکن بھیجنا" +description: "ethers.js کا استعمال کرتے ہوئے ٹوکن بھیجنے کے لیے ابتدائی افراد کے لیے دوستانہ گائیڈ۔" +author: Kim YongJun +tags: [ "ETHERS.JS", "ERC-20", "ٹوکنز" ] +skill: beginner +lang: ur-in +published: 2021-04-06 +--- + +## ethers.js(5.0) کا استعمال کرتے ہوئے ٹوکن بھیجیں {#send-token} + +### اس ٹیوٹوریل میں آپ سیکھیں گے کہ کیسے {#you-learn-about} + +- ethers.js امپورٹ کریں +- ٹوکن منتقل کریں +- نیٹ ورک ٹریفک کی صورتحال کے مطابق گیس کی قیمت مقرر کریں + +### شروع کرنے کے لیے {#to-get-started} + +شروع کرنے کے لیے، ہمیں سب سے پہلے اپنے javascript میں ethers.js لائبریری امپورٹ کرنی ہوگی +ethers.js(5.0) شامل کریں + +### انسٹال کرنا {#install-ethersjs} + +```shell +/home/ricmoo> npm install --save ethers +``` + +براؤزر میں ES6 + +```html + +``` + +براؤزر میں ES3(UMD) + +```html + +``` + +### پیرامیٹرز {#param} + +1. **`contract_address`**: ٹوکن کنٹریکٹ کا پتہ (کنٹریکٹ ایڈریس کی ضرورت اس وقت ہوتی ہے جب آپ جو ٹوکن منتقل کرنا چاہتے ہیں وہ ether نہ ہو) +2. **`send_token_amount`**: وہ رقم جو آپ وصول کنندہ کو بھیجنا چاہتے ہیں +3. **`to_address`**: وصول کنندہ کا پتہ +4. **`send_account`**: بھیجنے والے کا پتہ +5. **`private_key`**: ٹرانزیکشن پر دستخط کرنے اور دراصل ٹوکن منتقل کرنے کے لیے بھیجنے والے کی نجی کلید + +## نوٹس {#notice} + +`signTransaction(tx)` کو ہٹا دیا گیا ہے کیونکہ `sendTransaction()` اسے اندرونی طور پر کرتا ہے۔ + +## بھیجنے کے طریقہ کار {#procedure} + +### 1۔ نیٹ ورک سے جڑیں (ٹیسٹ نیٹ) {#connect-to-network} + +#### پرووائڈر سیٹ کریں (Infura) {#set-provider} + +Ropsten ٹیسٹ نیٹ سے جڑیں + +```javascript +window.ethersProvider = new ethers.providers.InfuraProvider("ropsten") +``` + +### 2۔ والیٹ بنائیں {#create-wallet} + +```javascript +let wallet = new ethers.Wallet(private_key) +``` + +### 3۔ والیٹ کو نیٹ سے جوڑیں {#connect-wallet-to-net} + +```javascript +let walletSigner = wallet.connect(window.ethersProvider) +``` + +### 4. موجودہ گیس کی قیمت حاصل کریں {#get-gas} + +```javascript +window.ethersProvider.getGasPrice() // گیس کی قیمت +``` + +### 5. ٹرانزیکشن کی وضاحت کریں {#define-transaction} + +نیچے بیان کردہ یہ متغیرات `send_token()` پر منحصر ہیں + +### ٹرانزیکشن پیرامیٹرز {#transaction-params} + +1. **`send_account`**: ٹوکن بھیجنے والے کا پتہ +2. **`to_address`**: ٹوکن وصول کرنے والے کا پتہ +3. **`send_token_amount`**: بھیجے جانے والے ٹوکنز کی مقدار +4. **`gas_limit`**: گیس کی حد +5. **`gas_price`**: گیس کی قیمت + +[استعمال کرنے کا طریقہ جاننے کے لیے نیچے دیکھیں](#how-to-use) + +```javascript +const tx = { + from: send_account, + to: to_address, + value: ethers.utils.parseEther(send_token_amount), + nonce: window.ethersProvider.getTransactionCount(send_account, "latest"), + gasLimit: ethers.utils.hexlify(gas_limit), // 100000 + gasPrice: gas_price, +} +``` + +### 6. منتقل کریں {#transfer} + +```javascript +walletSigner.sendTransaction(tx).then((transaction) => { + console.dir(transaction) + alert("بھیجنا مکمل!") +}) +``` + +## اسے کیسے استعمال کریں {#how-to-use} + +```javascript +let private_key = + "41559d28e936dc92104ff30691519693fc753ffbee6251a611b9aa1878f12a4d" +let send_token_amount = "1" +let to_address = "0x4c10D2734Fb76D3236E522509181CC3Ba8DE0e80" +let send_address = "0xda27a282B5B6c5229699891CfA6b900A716539E6" +let gas_limit = "0x100000" +let wallet = new ethers.Wallet(private_key) +let walletSigner = wallet.connect(window.ethersProvider) +let contract_address = "" +window.ethersProvider = new ethers.providers.InfuraProvider("ropsten") + +send_token( + contract_address, + send_token_amount, + to_address, + send_address, + private_key +) +``` + +### کامیاب! {#success} + +![کامیابی سے مکمل ہوئی ٹرانزیکشن کی تصویر](./successful-transaction.png) + +## send_token() {#send-token-method} + +```javascript +function send_token( + contract_address, + send_token_amount, + to_address, + send_account, + private_key +) { + let wallet = new ethers.Wallet(private_key) + let walletSigner = wallet.connect(window.ethersProvider) + + window.ethersProvider.getGasPrice().then((currentGasPrice) => { + let gas_price = ethers.utils.hexlify(parseInt(currentGasPrice)) + console.log(`gas_price: ${gas_price}`) + + if (contract_address) { + // عام ٹوکن بھیجیں + let contract = new ethers.Contract( + contract_address, + send_abi, + walletSigner + ) + + // کتنے ٹوکنز؟ + let numberOfTokens = ethers.utils.parseUnits(send_token_amount, 18) + console.log(`numberOfTokens: ${numberOfTokens}`) + + // ٹوکنز بھیجیں + contract.transfer(to_address, numberOfTokens).then((transferResult) => { + console.dir(transferResult) + alert("ٹوکن بھیج دیا گیا") + }) + } // ether بھیجیں + else { + const tx = { + from: send_account, + to: to_address, + value: ethers.utils.parseEther(send_token_amount), + nonce: window.ethersProvider.getTransactionCount( + send_account, + "latest" + ), + gasLimit: ethers.utils.hexlify(gas_limit), // 100000 + gasPrice: gas_price, + } + console.dir(tx) + try { + walletSigner.sendTransaction(tx).then((transaction) => { + console.dir(transaction) + alert("بھیجنا مکمل!") + }) + } catch (error) { + alert("بھیجنے میں ناکام!!") + } + } + }) +} +``` diff --git a/public/content/translations/ur/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/ur/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md new file mode 100644 index 00000000000..d2cd65b24c3 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md @@ -0,0 +1,208 @@ +--- +title: "Web3 کا استعمال کرتے ہوئے لین دین بھیجنا" +description: "یہ Web3 کا استعمال کرتے ہوئے Ethereum لین دین بھیجنے کے لیے ایک ابتدائی دوستانہ گائیڈ ہے۔ Ethereum بلاک چین پر لین دین بھیجنے کے لیے تین اہم مراحل ہیں: تخلیق کریں، دستخط کریں، اور براڈکاسٹ کریں۔ ہم ان تینوں پر عمل کریں گے۔" +author: "Elan Halpern" +tags: [ "لین دین", "web3.js", "alchemy" ] +skill: beginner +lang: ur-in +published: 2020-11-04 +source: Alchemy docs +sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum +--- + +یہ Web3 کا استعمال کرتے ہوئے Ethereum لین دین بھیجنے کے لیے ایک ابتدائی دوستانہ گائیڈ ہے۔ Ethereum بلاک چین پر لین دین بھیجنے کے لیے تین اہم مراحل ہیں: تخلیق کریں، دستخط کریں، اور براڈکاسٹ کریں۔ ہم ان تینوں پر عمل کریں گے، امید ہے کہ آپ کے تمام سوالوں کے جواب مل جائیں گے! اس ٹیوٹوریل میں، ہم اپنے لین دین کو Ethereum چین پر بھیجنے کے لیے [Alchemy](https://www.alchemy.com/) کا استعمال کریں گے۔ آپ [یہاں ایک مفت Alchemy اکاؤنٹ بنا سکتے ہیں](https://auth.alchemyapi.io/signup)۔ + +**نوٹ:** یہ گائیڈ آپ کی ایپ کے لیے _بیک اینڈ_ پر آپ کے لین دین پر دستخط کرنے کے لیے ہے۔ اگر آپ فرنٹ اینڈ پر اپنے لین دین پر دستخط کو مربوط کرنا چاہتے ہیں، تو [براؤزر فراہم کنندہ کے ساتھ Web3 کو مربوط کرنے](https://docs.alchemy.com/reference/api-overview#with-a-browser-provider) کی جانچ کریں۔ + +## بنیادی باتیں {#the-basics} + +زیادہ تر بلاک چین ڈویلپرز کی طرح جب وہ پہلی بار شروع کرتے ہیں، تو ہو سکتا ہے کہ آپ نے لین دین بھیجنے کے طریقے پر کچھ تحقیق کی ہو (ایسی چیز جو بہت آسان ہونی چاہیے) اور بہت سارے گائیڈز کا سامنا کیا ہو، ہر ایک مختلف باتیں کہہ رہا ہو اور آپ کو تھوڑا مغلوب اور الجھن میں ڈال دیا ہو۔ اگر آپ بھی اسی حال میں ہیں، تو فکر نہ کریں؛ ہم سب کبھی نہ کبھی اس حال میں تھے! تو، شروع کرنے سے پہلے، آئیے کچھ چیزوں کو سیدھا کر لیں: + +### 1. Alchemy آپ کی نجی کلیدوں کو ذخیرہ نہیں کرتا ہے {#alchemy-does-not-store-your-private-keys} + +- اس کا مطلب ہے کہ Alchemy آپ کی طرف سے لین دین پر دستخط اور بھیج نہیں سکتا ہے۔ اس کی وجہ سیکورٹی کے مقاصد ہیں۔ Alchemy کبھی بھی آپ سے اپنی نجی کلید شیئر کرنے کے لیے نہیں کہے گا، اور آپ کو کبھی بھی اپنی نجی کلید کسی میزبان نوڈ (یا اس معاملے میں کسی کے ساتھ) شیئر نہیں کرنی چاہیے۔ +- آپ Alchemy کے کور API کا استعمال کرتے ہوئے بلاک چین سے پڑھ سکتے ہیں، لیکن اس پر لکھنے کے لیے آپ کو Alchemy کے ذریعے بھیجنے سے پہلے اپنے لین دین پر دستخط کرنے کے لیے کچھ اور استعمال کرنے کی ضرورت ہوگی (یہ کسی بھی دوسرے [نوڈ سروس](/developers/docs/nodes-and-clients/nodes-as-a-service/) کے لیے بھی ایسا ہی ہے)۔ + +### 2. ایک “دستخط کنندہ” کیا ہے؟ {#what-is-a-signer} + +- دستخط کنندگان آپ کے لیے آپ کی نجی کلید کا استعمال کرتے ہوئے لین دین پر دستخط کریں گے۔ اس ٹیوٹوریل میں ہم اپنے لین دین پر دستخط کرنے کے لیے [Alchemy web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3) کا استعمال کریں گے، لیکن آپ کوئی دوسری web3 لائبریری بھی استعمال کر سکتے ہیں۔ +- فرنٹ اینڈ پر، دستخط کنندہ کی ایک اچھی مثال [MetaMask](https://metamask.io/) ہوگی، جو آپ کی طرف سے لین دین پر دستخط اور بھیجے گا۔ + +### 3. مجھے اپنے لین دین پر دستخط کرنے کی ضرورت کیوں ہے؟ {#why-do-i-need-to-sign-my-transactions} + +- ہر وہ صارف جو Ethereum نیٹ ورک پر لین دین بھیجنا چاہتا ہے اسے لین دین پر دستخط کرنا ہوگا (اپنی نجی کلید کا استعمال کرتے ہوئے)، تاکہ یہ تصدیق کی جا سکے کہ لین دین کا ماخذ وہی ہے جس کا وہ دعویٰ کرتا ہے۔ +- اس نجی کلید کی حفاظت کرنا بہت ضروری ہے، کیونکہ اس تک رسائی آپ کے Ethereum اکاؤنٹ پر مکمل کنٹرول فراہم کرتی ہے، جس سے آپ (یا رسائی رکھنے والے کسی بھی شخص) کو آپ کی طرف سے لین دین کرنے کی اجازت ملتی ہے۔ + +### 4. میں اپنی نجی کلید کی حفاظت کیسے کروں؟ {#how-do-i-protect-my-private-key} + +- اپنی نجی کلید کی حفاظت کرنے اور اسے لین دین بھیجنے کے لیے استعمال کرنے کے بہت سے طریقے ہیں۔ اس ٹیوٹوریل میں ہم ایک `.env` فائل کا استعمال کریں گے۔ تاہم، آپ ایک علیحدہ فراہم کنندہ بھی استعمال کر سکتے ہیں جو نجی کلیدوں کو ذخیرہ کرتا ہے، ایک کیسٹور فائل، یا دیگر اختیارات استعمال کر سکتے ہیں۔ + +### 5. `eth_sendTransaction` اور `eth_sendRawTransaction` کے درمیان کیا فرق ہے؟ {#difference-between-send-and-send-raw} + +`eth_sendTransaction` اور `eth_sendRawTransaction` دونوں Ethereum API فنکشنز ہیں جو Ethereum نیٹ ورک پر لین دین کو براڈکاسٹ کرتے ہیں تاکہ اسے مستقبل کے بلاک میں شامل کیا جا سکے۔ وہ لین دین پر دستخط کو سنبھالنے کے طریقے میں مختلف ہیں۔ + +- [`eth_sendTransaction`](https://docs.web3js.org/api/web3-eth/function/sendTransaction) کا استعمال _بغیر دستخط شدہ_ لین دین بھیجنے کے لیے کیا جاتا ہے، جس کا مطلب ہے کہ جس نوڈ پر آپ بھیج رہے ہیں اسے آپ کی نجی کلید کا انتظام کرنا چاہیے تاکہ وہ اسے چین پر براڈکاسٹ کرنے سے پہلے لین دین پر دستخط کر سکے۔ چونکہ Alchemy صارف کی نجی کلیدوں کو نہیں رکھتا ہے، اس لیے وہ اس طریقے کی حمایت نہیں کرتے ہیں۔ +- [`eth_sendRawTransaction`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) کا استعمال ان لین دین کو براڈکاسٹ کرنے کے لیے کیا جاتا ہے جن پر پہلے ہی دستخط ہو چکے ہیں۔ اس کا مطلب ہے کہ آپ کو پہلے [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction) کا استعمال کرنا ہوگا، پھر نتیجہ کو `eth_sendRawTransaction` میں پاس کرنا ہوگا۔ + +web3 کا استعمال کرتے وقت، `eth_sendRawTransaction` کو فنکشن [web3.eth.sendSignedTransaction](https://docs.web3js.org/api/web3-eth/function/sendSignedTransaction) کو کال کرکے رسائی حاصل کی جاتی ہے۔ + +اس ٹیوٹوریل میں ہم یہی استعمال کریں گے۔ + +### 6. web3 لائبریری کیا ہے؟ {#what-is-the-web3-library} + +- Web3.js معیاری JSON-RPC کالز کے ارد گرد ایک ریپر لائبریری ہے جو Ethereum کی ڈیولپمنٹ میں استعمال کرنا کافی عام ہے۔ +- مختلف زبانوں کے لیے بہت سی web3 لائبریریاں ہیں۔ اس ٹیوٹوریل میں ہم [Alchemy Web3](https://docs.alchemy.com/reference/api-overview) کا استعمال کریں گے جو JavaScript میں لکھی گئی ہے۔ آپ [یہاں](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries) دیگر اختیارات جیسے [ethers.js](https://docs.ethers.org/v5/) دیکھ سکتے ہیں۔ + +ٹھیک ہے، اب جب کہ ہم نے ان میں سے کچھ سوالات کو راستے سے ہٹا دیا ہے، آئیے ٹیوٹوریل کی طرف بڑھتے ہیں۔ Alchemy [discord](https://discord.gg/gWuC7zB) میں کسی بھی وقت سوالات پوچھنے کے لیے آزاد محسوس کریں! + +### 7. محفوظ، گیس-آپٹمائزڈ، اور نجی لین دین کیسے بھیجیں؟ {#how-to-send-secure-gas-optimized-and-private-transactions} + +- [Alchemy کے پاس Transact APIs کا ایک مجموعہ ہے](https://docs.alchemy.com/reference/transact-api-quickstart)۔ آپ ان کا استعمال مضبوط لین دین بھیجنے، لین دین ہونے سے پہلے ان کی تقلید کرنے، نجی لین دین بھیجنے، اور گیس-آپٹمائزڈ لین دین بھیجنے کے لیے کر سکتے ہیں۔ +- آپ [Notify API](https://docs.alchemy.com/docs/alchemy-notify) کا استعمال بھی کر سکتے ہیں تاکہ آپ کو مطلع کیا جا سکے جب آپ کا لین دین میمپول سے کھینچ کر چین میں شامل کیا جائے۔ + +**نوٹ:** اس گائیڈ کے لیے Alchemy اکاؤنٹ، ایک Ethereum ایڈریس یا MetaMask والیٹ، NodeJs، اور npm انسٹال ہونا ضروری ہے۔ اگر نہیں، تو ان اقدامات پر عمل کریں: + +1. [ایک مفت Alchemy اکاؤنٹ بنائیں](https://auth.alchemyapi.io/signup) +2. [MetaMask اکاؤنٹ بنائیں](https://metamask.io/) (یا ایک Ethereum ایڈریس حاصل کریں) +3. [NodeJs اور NPM انسٹال کرنے کے لیے ان اقدامات پر عمل کریں](https://docs.alchemy.com/alchemy/guides/alchemy-for-macs) + +## اپنا لین دین بھیجنے کے اقدامات {#steps-to-sending-your-transaction} + +### 1. Sepolia ٹیسٹ نیٹ پر ایک Alchemy ایپ بنائیں {#create-an-alchemy-app-on-the-sepolia-testnet} + +اپنے [Alchemy ڈیش بورڈ](https://dashboard.alchemyapi.io/) پر جائیں اور ایک نئی ایپ بنائیں، اپنے نیٹ ورک کے لیے Sepolia (یا کوئی دوسرا ٹیسٹ نیٹ) کا انتخاب کریں۔ + +### 2. Sepolia فاسیٹ سے ETH کی درخواست کریں {#request-eth-from-sepolia-faucet} + +ETH حاصل کرنے کے لیے [Alchemy Sepolia فاسیٹ](https://www.sepoliafaucet.com/) پر دی گئی ہدایات پر عمل کریں۔ یقینی بنائیں کہ آپ اپنا **Sepolia** Ethereum ایڈریس (MetaMask سے) شامل کریں اور کوئی دوسرا نیٹ ورک نہیں۔ ہدایات پر عمل کرنے کے بعد، دوبارہ چیک کریں کہ آپ نے اپنے والیٹ میں ETH وصول کر لیا ہے۔ + +### 3. ایک نئی پراجیکٹ ڈائرکٹری بنائیں اور اس میں `cd` کریں {#create-a-new-project-direction} + +کمانڈ لائن (macs کے لیے ٹرمینل) سے ایک نئی پراجیکٹ ڈائرکٹری بنائیں اور اس میں نیویگیٹ کریں: + +``` +mkdir sendtx-example +cd sendtx-example +``` + +### 4. Alchemy Web3 (یا کوئی بھی web3 لائبریری) انسٹال کریں {#install-alchemy-web3} + +[Alchemy Web3](https://docs.alchemy.com/reference/api-overview) انسٹال کرنے کے لیے اپنی پراجیکٹ ڈائرکٹری میں درج ذیل کمانڈ چلائیں: + +نوٹ، اگر آپ ethers.js لائبریری استعمال کرنا چاہتے ہیں، تو [یہاں دی گئی ہدایات پر عمل کریں](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum)۔ + +``` +npm install @alch/alchemy-web3 +``` + +### 5. dotenv انسٹال کریں {#install-dotenv} + +ہم اپنی API کلید اور نجی کلید کو محفوظ طریقے سے ذخیرہ کرنے کے لیے ایک `.env` فائل استعمال کریں گے۔ + +``` +npm install dotenv --save +``` + +### 6. `.env` فائل بنائیں {#create-the-dotenv-file} + +اپنی پراجیکٹ ڈائرکٹری میں ایک `.env` فائل بنائیں اور درج ذیل شامل کریں (“`your-api-url`" اور "`your-private-key`" کو تبدیل کرتے ہوئے) + +- اپنا Alchemy API URL تلاش کرنے کے لیے، اپنے ڈیش بورڈ پر ابھی بنائی گئی ایپ کے ایپ تفصیلات کے صفحے پر جائیں، اوپر دائیں کونے میں “View Key” پر کلک کریں، اور HTTP URL حاصل کریں۔ +- MetaMask کا استعمال کرتے ہوئے اپنی نجی کلید تلاش کرنے کے لیے، یہ [گائیڈ](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) دیکھیں۔ + +``` +API_URL = "your-api-url" +PRIVATE_KEY = "your-private-key" +``` + + + + +.env کو کمٹ نہ کریں! براہ کرم یقینی بنائیں کہ آپ اپنی .env فائل کسی کے ساتھ شیئر یا ظاہر نہ کریں، کیونکہ ایسا کرنے سے آپ اپنے رازوں پر سمجھوتہ کر رہے ہیں۔ اگر آپ ورژن کنٹرول استعمال کر رہے ہیں، تو اپنی .env کو gitignore فائل میں شامل کریں۔ + + + + +### 7. `sendTx.js` فائل بنائیں {#create-sendtx-js} + +بہت اچھا، اب جب کہ ہمارا حساس ڈیٹا ایک `.env` فائل میں محفوظ ہے، آئیے کوڈنگ شروع کرتے ہیں۔ ہمارے بھیجنے والے لین دین کی مثال کے لیے، ہم ETH کو Sepolia فاسیٹ پر واپس بھیجیں گے۔ + +ایک `sendTx.js` فائل بنائیں، جہاں ہم اپنے مثال کے لین دین کو کنفیگر اور بھیجیں گے، اور اس میں کوڈ کی درج ذیل لائنیں شامل کریں: + +``` +async function main() { + require('dotenv').config(); + const { API_URL, PRIVATE_KEY } = process.env; + const { createAlchemyWeb3 } = require("@alch/alchemy-web3"); + const web3 = createAlchemyWeb3(API_URL); + const myAddress = '0x610Ae88399fc1687FA7530Aac28eC2539c7d6d63' //TODO: اس ایڈریس کو اپنے عوامی ایڈریس سے تبدیل کریں + + const nonce = await web3.eth.getTransactionCount(myAddress, 'latest'); // نونس 0 سے گننا شروع کرتا ہے + + const transaction = { + 'to': '0x31B98D14007bDEe637298086988A0bBd31184523', // eth واپس کرنے کے لیے فاسیٹ ایڈریس + 'value': 1000000000000000000, // 1 ETH + 'gas': 30000, + 'nonce': nonce, + // پیغام بھیجنے یا سمارٹ کنٹریکٹ پر عمل کرنے کے لیے اختیاری ڈیٹا فیلڈ + }; + + const signedTx = await web3.eth.accounts.signTransaction(transaction, PRIVATE_KEY); + + web3.eth.sendSignedTransaction(signedTx.rawTransaction, function(error, hash) { + if (!error) { + console.log("🎉 آپ کے لین دین کا ہیش یہ ہے: ", hash, "\n اپنے لین دین کی حیثیت دیکھنے کے لیے Alchemy's Mempool کو چیک کریں!"); + } else { + console.log("❗آپ کا لین دین جمع کراتے وقت کچھ غلط ہو گیا:", error) + } + }); +} + +main(); +``` + +یقینی بنائیں کہ آپ **لائن 6** پر موجود ایڈریس کو اپنے عوامی ایڈریس سے تبدیل کریں۔ + +اب، اس کوڈ کو چلانے سے پہلے، آئیے یہاں کچھ اجزاء کے بارے میں بات کرتے ہیں۔ + +- `nonce`: نونس کی تفصیلات کا استعمال آپ کے ایڈریس سے بھیجے گئے لین دین کی تعداد پر نظر رکھنے کے لیے کیا جاتا ہے۔ ہمیں اس کی ضرورت سیکورٹی کے مقاصد اور [ری پلے حملوں](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce) کو روکنے کے لیے ہے۔ اپنے ایڈریس سے بھیجے گئے لین دین کی تعداد حاصل کرنے کے لیے ہم [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount) کا استعمال کرتے ہیں۔ +- `transaction`: لین دین کی آبجیکٹ کے کچھ پہلو ہیں جن کی ہمیں وضاحت کرنے کی ضرورت ہے۔ + - `to`: یہ وہ ایڈریس ہے جس پر ہم ETH بھیجنا چاہتے ہیں۔ اس معاملے میں، ہم ETH کو [Sepolia فاسیٹ](https://sepoliafaucet.com/) پر واپس بھیج رہے ہیں جس سے ہم نے ابتدائی طور پر درخواست کی تھی۔ + - `value`: یہ وہ رقم ہے جسے ہم بھیجنا چاہتے ہیں، جو Wei میں بیان کی گئی ہے جہاں 10^18 Wei = 1 ETH + - `gas`: اپنے لین دین میں شامل کرنے کے لیے گیس کی صحیح مقدار کا تعین کرنے کے بہت سے طریقے ہیں۔ Alchemy کے پاس ایک [گیس پرائس ویب ہک](https://docs.alchemyapi.io/guides/alchemy-notify#address-activity-1) بھی ہے جو آپ کو مطلع کرتا ہے جب گیس کی قیمت ایک خاص حد کے اندر آ جاتی ہے۔ Mainnet لین دین کے لیے، گیس کی صحیح مقدار کا تعین کرنے کے لیے [ETH Gas Station](https://ethgasstation.info/) جیسے گیس ایسٹیمیٹر کو چیک کرنا ایک اچھا عمل ہے۔ 21000 گیس کی کم از کم مقدار ہے جو Ethereum پر ایک آپریشن استعمال کرے گا، لہذا اس بات کو یقینی بنانے کے لیے کہ ہمارا لین دین انجام دیا جائے گا ہم یہاں 30000 ڈالتے ہیں۔ + - `nonce`: اوپر نونس کی تعریف دیکھیں۔ نونس صفر سے گننا شروع کرتا ہے۔ + - [اختیاری] ڈیٹا: آپ کی منتقلی کے ساتھ اضافی معلومات بھیجنے، یا اسمارٹ کنٹریکٹ کو کال کرنے کے لیے استعمال کیا جاتا ہے، بیلنس کی منتقلی کے لیے ضروری نہیں، نیچے دیا گیا نوٹ دیکھیں۔ +- `signedTx`: اپنے لین دین کی آبجیکٹ پر دستخط کرنے کے لیے ہم `PRIVATE_KEY` کے ساتھ `signTransaction` طریقہ استعمال کریں گے۔ +- `sendSignedTransaction`: ایک بار جب ہمارے پاس دستخط شدہ لین دین ہو جاتا ہے، تو ہم اسے `sendSignedTransaction` کا استعمال کرتے ہوئے بعد کے بلاک میں شامل کرنے کے لیے بھیج سکتے ہیں۔ + +**ڈیٹا پر ایک نوٹ** +Ethereum میں دو اہم قسم کے لین دین بھیجے جا سکتے ہیں۔ + +- بیلنس کی منتقلی: ایک ایڈریس سے دوسرے ایڈریس پر ETH بھیجیں۔ کوئی ڈیٹا فیلڈ درکار نہیں، تاہم، اگر آپ اپنے لین دین کے ساتھ اضافی معلومات بھیجنا چاہتے ہیں، تو آپ اس فیلڈ میں HEX فارمیٹ میں وہ معلومات شامل کر سکتے ہیں۔ + - مثال کے طور پر، فرض کریں کہ ہم ایک IPFS دستاویز کا ہیش Ethereum چین پر لکھنا چاہتے ہیں تاکہ اسے ایک ناقابل تغیر ٹائم اسٹیمپ دیا جا سکے۔ ہمارا ڈیٹا فیلڈ پھر اس طرح نظر آنا چاہئے: `web3.utils.toHex('IPFS ہیش')`۔ اور اب کوئی بھی چین سے استفسار کر سکتا ہے اور دیکھ سکتا ہے کہ وہ دستاویز کب شامل کی گئی تھی۔ +- اسمارٹ کنٹریکٹ لین دین: چین پر کچھ اسمارٹ کنٹریکٹ کوڈ پر عمل کریں۔ اس معاملے میں، ڈیٹا فیلڈ میں وہ اسمارٹ فنکشن ہونا چاہئے جسے آپ کسی بھی پیرامیٹرز کے ساتھ عمل کرنا چاہتے ہیں۔ + - ایک عملی مثال کے لیے، اس [ہیلو ورلڈ ٹیوٹوریل](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#step-8-create-the-transaction) میں مرحلہ 8 دیکھیں۔ + +### 8. `node sendTx.js` کا استعمال کرتے ہوئے کوڈ چلائیں {#run-the-code-using-node-sendtx-js} + +اپنے ٹرمینل یا کمانڈ لائن پر واپس جائیں اور چلائیں: + +``` +node sendTx.js +``` + +### 9. Mempool میں اپنا لین دین دیکھیں {#see-your-transaction-in-the-mempool} + +اپنے Alchemy ڈیش بورڈ میں [Mempool صفحہ](https://dashboard.alchemyapi.io/mempool) کھولیں اور اپنا لین دین تلاش کرنے کے لیے بنائی گئی ایپ کے ذریعے فلٹر کریں۔ یہ وہ جگہ ہے جہاں ہم اپنے لین دین کی منتقلی کو زیر التواء حالت سے مائنڈ حالت (اگر کامیاب ہو) یا غیر کامیاب ہونے پر ڈراپڈ حالت میں دیکھ سکتے ہیں۔ یقینی بنائیں کہ اسے "All" پر رکھیں تاکہ آپ "mined"، "pending"، اور "dropped" لین دین کو کیپچر کر سکیں۔ آپ ایڈریس `0x31b98d14007bdee637298086988a0bbd31184523` پر بھیجے گئے لین دین کو تلاش کرکے بھی اپنا لین دین تلاش کر سکتے ہیں۔ + +ایک بار جب آپ اسے تلاش کر لیں تو اپنے لین دین کی تفصیلات دیکھنے کے لیے، tx ہیش کو منتخب کریں، جو آپ کو اس طرح کے منظر پر لے جائے گا: + +![Mempool واچر اسکرین شاٹ](./mempool.png) + +وہاں سے آپ سرخ رنگ میں دائرے والے آئیکن پر کلک کرکے Etherscan پر اپنا لین دین دیکھ سکتے ہیں! + +**یپییییی!** آپ نے ابھی Alchemy کا استعمال کرتے ہوئے اپنا پہلا Ethereum لین دین بھیجا ہے 🎉\*\* + +_اس گائیڈ کے بارے میں رائے اور تجاویز کے لیے، براہ کرم Alchemy's [Discord](https://discord.gg/A39JVCM) پر Elan کو پیغام دیں!_ + +_اصل میں [https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy](https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy) پر شائع ہوا_ diff --git a/public/content/translations/ur/developers/tutorials/server-components/index.md b/public/content/translations/ur/developers/tutorials/server-components/index.md new file mode 100644 index 00000000000..a96c5096cd0 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/server-components/index.md @@ -0,0 +1,295 @@ +--- +title: "web3 ایپس کے لیے سرور اجزاء اور ایجنٹس" +description: "اس ٹیوٹوریل کو پڑھنے کے بعد، آپ TypeScript سرورز لکھنے کے قابل ہو جائیں گے جو ایک بلاک چین پر ایونٹس کو سنتے ہیں اور اسی کے مطابق اپنے ٹرانزیکشنز کے ساتھ جواب دیتے ہیں۔ یہ آپ کو مرکزی ایپلی کیشنز (کیونکہ سرور ناکامی کا ایک نقطہ ہے) لکھنے کے قابل بنائے گا، لیکن آپ web3 اداروں کے ساتھ تعامل کر سکتے ہیں۔ یہی تکنیک ایک ایسا ایجنٹ لکھنے کے لیے بھی استعمال کی جا سکتی ہیں جو لوپ میں انسان کے بغیر آن چین ایونٹس کا جواب دیتا ہے۔" + +author: Ori Pomerantz +lang: ur-in +tags: [ "ایجنٹ", "سرور", "آف چین" ] +skill: beginner +published: 2024-07-15 +--- + +## تعارف {#introduction} + +زیادہ تر معاملات میں، ایک غیر مرکزی ایپ سافٹ ویئر تقسیم کرنے کے لیے ایک سرور کا استعمال کرتی ہے، لیکن تمام حقیقی تعامل کلائنٹ (عام طور پر، ویب براؤزر) اور بلاک چین کے درمیان ہوتا ہے۔ + +![ویب سرور، کلائنٹ، اور بلاک چین کے درمیان عام تعامل](./fig-1.svg) + +تاہم، کچھ ایسے معاملات ہیں جہاں ایک ایپلی کیشن کو آزادانہ طور پر چلنے والے سرور جزو سے فائدہ ہوگا۔ ایسا سرور ٹرانزیکشنز جاری کرکے ایونٹس، اور دیگر ذرائع، جیسے API سے آنے والی درخواستوں کا جواب دینے کے قابل ہوگا۔ + +![سرور کے اضافے کے ساتھ تعامل](./fig-2.svg) + +ایسے کئی ممکنہ کام ہیں جو ایسا سرور پورا کر سکتا ہے۔ + +- خفیہ اسٹیٹ کا ہولڈر۔ گیمنگ میں یہ اکثر مفید ہوتا ہے کہ گیم کو معلوم تمام معلومات کھلاڑیوں کو دستیاب نہ ہوں۔ تاہم، _بلاک چین پر کوئی راز نہیں ہیں_، بلاک چین میں موجود کوئی بھی معلومات کسی کے لیے بھی معلوم کرنا آسان ہے۔ لہذا، اگر گیم اسٹیٹ کے کچھ حصے کو خفیہ رکھنا ہے، تو اسے کہیں اور ذخیرہ کرنا ہوگا (اور ممکنہ طور پر اس اسٹیٹ کے اثرات کی تصدیق [zero-knowledge proofs](/zero-knowledge-proofs) کا استعمال کرتے ہوئے کی جائے)۔ + +- مرکزی اوریکل۔ اگر داؤ کافی کم ہے، تو ایک بیرونی سرور جو آن لائن کچھ معلومات پڑھتا ہے اور پھر اسے چین پر پوسٹ کرتا ہے، [oracle](/developers/docs/oracles/) کے طور پر استعمال کرنے کے لیے کافی اچھا ہو سکتا ہے۔ + +- ایجنٹ۔ بلاک چین پر بغیر کسی ٹرانزیکشن کے اسے فعال کرنے کے لیے کچھ نہیں ہوتا ہے۔ ایک سرور صارف کی جانب سے [arbitrage](/developers/docs/mev/#mev-examples-dex-arbitrage) جیسے اعمال انجام دینے کے لیے کام کر سکتا ہے جب موقع ملے۔ + +## نمونہ پروگرام {#sample-program} + +آپ [github](https://github.com/qbzzt/20240715-server-component) پر ایک نمونہ سرور دیکھ سکتے ہیں۔ یہ سرور [اس کنٹریکٹ](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=contract_code) سے آنے والے ایونٹس کو سنتا ہے، جو Hardhat کے Greeter کا ایک ترمیم شدہ ورژن ہے۔ جب گریٹنگ تبدیل کی جاتی ہے، تو یہ اسے واپس تبدیل کر دیتا ہے۔ + +اسے چلانے کے لئے: + +1. ریپوزٹری کو کلون کریں۔ + + ```sh copy + git clone https://github.com/qbzzt/20240715-server-component.git + cd 20240715-server-component + ``` + +2. ضروری پیکجز انسٹال کریں۔ اگر آپ کے پاس یہ پہلے سے نہیں ہے، تو [پہلے Node انسٹال کریں](https://nodejs.org/en/download/package-manager)۔ + + ```sh copy + npm install + ``` + +3. Holesky ٹیسٹ نیٹ پر ETH رکھنے والے اکاؤنٹ کی پرائیویٹ کی کی وضاحت کے لیے `.env` میں ترمیم کریں۔ اگر آپ کے پاس Holesky پر ETH نہیں ہے، تو آپ [یہ faucet استعمال کر سکتے ہیں](https://holesky-faucet.pk910.de/)۔ + + ```sh filename=".env" copy + PRIVATE_KEY=0x <پرائیویٹ کی یہاں ڈالیں> + ``` + +4. سرور شروع کریں۔ + + ```sh copy + npm start + ``` + +5. [بلاک ایکسپلورر](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract) پر جائیں، اور پرائیویٹ کی والے ایڈریس سے مختلف ایڈریس کا استعمال کرتے ہوئے گریٹنگ میں ترمیم کریں۔ دیکھیں کہ گریٹنگ خود بخود واپس تبدیل ہو جاتی ہے۔ + +### یہ کیسے کام کرتا ہے؟ {#how-it-works} + +سرور جزو لکھنے کا طریقہ سمجھنے کا سب سے آسان طریقہ یہ ہے کہ نمونے کو لائن بہ لائن پڑھا جائے۔ + +#### `src/app.ts` {#src-app-ts} + +پروگرام کا بڑا حصہ [`src/app.ts`](https://github.com/qbzzt/20240715-server-component/blob/main/src/app.ts) میں موجود ہے۔ + +##### پیشگی مطلوبہ اشیاء بنانا + +```typescript +import { + createPublicClient, + createWalletClient, + getContract, + http, + Address, +} from "viem" +``` + +یہ وہ [Viem](https://viem.sh/) ادارے ہیں جن کی ہمیں ضرورت ہے، فنکشنز اور [`Address` قسم](https://viem.sh/docs/glossary/types#address)۔ یہ سرور [TypeScript](https://www.typescriptlang.org/) میں لکھا گیا ہے، جو JavaScript کی ایک توسیع ہے جو اسے [مضبوطی سے ٹائپ شدہ](https://en.wikipedia.org/wiki/Strong_and_weak_typing) بناتی ہے۔ + +```typescript +import { privateKeyToAccount } from "viem/accounts" +``` + +[یہ فنکشن](https://viem.sh/docs/accounts/privateKey) ہمیں ایک پرائیویٹ کی کے مطابق والیٹ کی معلومات، بشمول ایڈریس، بنانے دیتا ہے۔ + +```typescript +import { holesky } from "viem/chains" +``` + +Viem میں بلاک چین استعمال کرنے کے لیے آپ کو اس کی تعریف درآمد کرنے کی ضرورت ہے۔ اس معاملے میں، ہم [Holesky](https://github.com/eth-clients/holesky) ٹیسٹ بلاک چین سے جڑنا چاہتے ہیں۔ + +```typescript +// یہ ہے کہ ہم .env میں موجود تعریفوں کو process.env میں کیسے شامل کرتے ہیں۔ +import * as dotenv from "dotenv" +dotenv.config() +``` + +یہ ہے کہ ہم `.env` کو ماحول میں کیسے پڑھتے ہیں۔ ہمیں پرائیویٹ کی کے لیے اس کی ضرورت ہے (بعد میں دیکھیں)۔ + +```typescript +const greeterAddress : Address = "0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6" +const greeterABI = [ + { + "inputs": [ + { + "internalType": "string", + "name": "_greeting", + "type": "string" + } + ], + "stateMutability": "nonpayable", + "type": "constructor" + }, + . + . + . + { + "inputs": [ + { + "internalType": "string", + "name": "_greeting", + "type": "string" + } + ], + "name": "setGreeting", + "outputs": [], + "stateMutability": "nonpayable", + "type": "function" + } +] as const +``` + +کنٹریکٹ استعمال کرنے کے لیے ہمیں اس کے ایڈریس اور اس کے لیے [ABI](/glossary/#abi) کی ضرورت ہے۔ ہم یہاں دونوں فراہم کرتے ہیں۔ + +JavaScript (اور اس لیے TypeScript) میں آپ کسی مستقل کو نئی قدر تفویض نہیں کر سکتے، لیکن آپ اس میں ذخیرہ شدہ آبجیکٹ میں ترمیم _کر سکتے_ ہیں۔ `as const` لاحقہ کا استعمال کرکے ہم TypeScript کو بتا رہے ہیں کہ فہرست خود مستقل ہے اور اسے تبدیل نہیں کیا جا سکتا۔ + +```typescript +const publicClient = createPublicClient({ + chain: holesky, + transport: http(), +}) +``` + +ایک Viem [پبلک کلائنٹ](https://viem.sh/docs/clients/public.html) بنائیں۔ پبلک کلائنٹس کے پاس منسلک پرائیویٹ کی نہیں ہوتی، اور اس لیے وہ ٹرانزیکشنز نہیں بھیج سکتے۔ وہ [`view` فنکشنز](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm) کو کال کر سکتے ہیں، اکاؤنٹ بیلنس پڑھ سکتے ہیں، وغیرہ۔ + +```typescript +const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`) +``` + +ماحولیاتی متغیرات [`process.env`](https://www.totaltypescript.com/how-to-strongly-type-process-env) میں دستیاب ہیں۔ تاہم، TypeScript مضبوطی سے ٹائپ شدہ ہے۔ ایک ماحولیاتی متغیر کوئی بھی سٹرنگ، یا خالی ہو سکتا ہے، لہذا ایک ماحولیاتی متغیر کی قسم `string | undefined` ہے۔ تاہم، Viem میں ایک کی کو `0x${string}` (`0x` کے بعد ایک سٹرنگ) کے طور پر بیان کیا گیا ہے۔ یہاں ہم TypeScript کو بتاتے ہیں کہ `PRIVATE_KEY` ماحولیاتی متغیر اس قسم کا ہوگا۔ اگر ایسا نہیں ہے، تو ہمیں ایک رن ٹائم ایرر ملے گا۔ + +[`privateKeyToAccount`](https://viem.sh/docs/accounts/privateKey) فنکشن پھر اس پرائیویٹ کی کا استعمال کرکے ایک مکمل اکاؤنٹ آبجیکٹ بناتا ہے۔ + +```typescript +const walletClient = createWalletClient({ + account, + chain: holesky, + transport: http(), +}) +``` + +اگلا، ہم اکاؤنٹ آبجیکٹ کا استعمال کرکے ایک [والیٹ کلائنٹ](https://viem.sh/docs/clients/wallet) بناتے ہیں۔ اس کلائنٹ کے پاس ایک پرائیویٹ کی اور ایک ایڈریس ہے، لہذا اسے ٹرانزیکشنز بھیجنے کے لیے استعمال کیا جا سکتا ہے۔ + +```typescript +const greeter = getContract({ + address: greeterAddress, + abi: greeterABI, + client: { public: publicClient, wallet: walletClient }, +}) +``` + +اب جب کہ ہمارے پاس تمام پیشگی شرائط ہیں، ہم آخر کار ایک [کنٹریکٹ انسٹنس](https://viem.sh/docs/contract/getContract) بنا سکتے ہیں۔ ہم اس کنٹریکٹ انسٹنس کا استعمال آن چین کنٹریکٹ کے ساتھ بات چیت کرنے کے لیے کریں گے۔ + +##### بلاک چین سے پڑھنا + +```typescript +console.log(`Current greeting:`, await greeter.read.greet()) +``` + +کنٹریکٹ کے فنکشنز جو صرف پڑھنے کے لیے ہیں ([`view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm) اور [`pure`](https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm)) `read` کے تحت دستیاب ہیں۔ اس معاملے میں، ہم اسے [`greet`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=read_contract#cfae3217) فنکشن تک رسائی حاصل کرنے کے لیے استعمال کرتے ہیں، جو گریٹنگ واپس کرتا ہے۔ + +JavaScript سنگل تھریڈڈ ہے، لہذا جب ہم ایک طویل چلنے والے عمل کو شروع کرتے ہیں تو ہمیں [یہ بتانا ہوگا کہ ہم اسے غیر مطابقت پذیر طریقے سے کرتے ہیں](https://eloquentjavascript.net/11_async.html#h-XvLsfAhtsE)۔ بلاک چین کو کال کرنا، یہاں تک کہ صرف پڑھنے کے آپریشن کے لیے، کمپیوٹر اور بلاک چین نوڈ کے درمیان راؤنڈ ٹرپ کی ضرورت ہوتی ہے۔ یہی وجہ ہے کہ ہم یہاں بتاتے ہیں کہ کوڈ کو نتیجے کے لیے `await` کرنے کی ضرورت ہے۔ + +اگر آپ اس میں دلچسپی رکھتے ہیں کہ یہ کیسے کام کرتا ہے تو آپ [یہاں اس کے بارے میں پڑھ سکتے ہیں](https://www.w3schools.com/js/js_promise.asp)، لیکن عملی طور پر آپ کو صرف یہ جاننے کی ضرورت ہے کہ اگر آپ کوئی ایسا آپریشن شروع کرتے ہیں جس میں زیادہ وقت لگتا ہے تو آپ نتائج کا `await` کریں، اور یہ کہ کوئی بھی فنکشن جو ایسا کرتا ہے اسے `async` کے طور پر اعلان کرنا ہوگا۔ + +##### ٹرانزیکشنز جاری کرنا + +```typescript +const setGreeting = async (greeting: string): Promise => { +``` + +یہ وہ فنکشن ہے جسے آپ گریٹنگ کو تبدیل کرنے والے ٹرانزیکشن کو جاری کرنے کے لیے کال کرتے ہیں۔ چونکہ یہ ایک طویل آپریشن ہے، اس لیے فنکشن کو `async` کے طور پر اعلان کیا گیا ہے۔ اندرونی نفاذ کی وجہ سے، کسی بھی `async` فنکشن کو `Promise` آبجیکٹ واپس کرنے کی ضرورت ہے۔ اس معاملے میں، `Promise` کا مطلب ہے کہ ہم یہ نہیں بتاتے کہ `Promise` میں بالکل کیا واپس کیا جائے گا۔ + +```typescript +const txHash = await greeter.write.setGreeting([greeting]) +``` + +کنٹریکٹ انسٹنس کے `write` فیلڈ میں وہ تمام فنکشنز ہیں جو بلاک چین اسٹیٹ پر لکھتے ہیں (وہ جن کے لیے ٹرانزیکشن بھیجنے کی ضرورت ہوتی ہے)، جیسے کہ [`setGreeting`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract#a4136862)۔ پیرامیٹرز، اگر کوئی ہیں، تو ایک فہرست کے طور پر فراہم کیے جاتے ہیں، اور فنکشن ٹرانزیکشن کا ہیش واپس کرتا ہے۔ + +```typescript + console.log(`Working on a fix, see https://eth-holesky.blockscout.com/tx/${txHash}`) + + return txHash +} +``` + +ٹرانزیکشن کے ہیش کی اطلاع دیں (اسے دیکھنے کے لیے بلاک ایکسپلورر کے یو آر ایل کے حصے کے طور پر) اور اسے واپس کریں۔ + +##### ایونٹس کا جواب دینا + +```typescript +greeter.watchEvent.SetGreeting({ +``` + +[`watchEvent` فنکشن](https://viem.sh/docs/actions/public/watchEvent) آپ کو یہ بتانے دیتا ہے کہ جب کوئی ایونٹ خارج ہوتا ہے تو ایک فنکشن چلنا ہے۔ اگر آپ صرف ایک قسم کے ایونٹ کا خیال رکھتے ہیں (اس معاملے میں، `SetGreeting`)، تو آپ اپنے آپ کو اس ایونٹ کی قسم تک محدود رکھنے کے لیے اس نحو کا استعمال کر سکتے ہیں۔ + +```typescript + onLogs: logs => { +``` + +`onLogs` فنکشن کو اس وقت کال کیا جاتا ہے جب لاگ اندراجات ہوں۔ Ethereum میں "لاگ" اور "ایونٹ" عام طور پر قابل تبادلہ ہیں۔ + +```typescript +console.log( + `Address ${logs[0].args.sender} changed the greeting to ${logs[0].args.greeting}` +) +``` + +متعدد ایونٹس ہو سکتے ہیں، لیکن سادگی کے لیے ہم صرف پہلے والے کا خیال رکھتے ہیں۔ `logs[0].args` ایونٹ کے دلائل ہیں، اس معاملے میں `sender` اور `greeting`۔ + +```typescript + if (logs[0].args.sender != account.address) + setGreeting(`${account.address} insists on it being Hello!`) + } +}) +``` + +اگر بھیجنے والا یہ سرور _نہیں_ ہے، تو گریٹنگ کو تبدیل کرنے کے لیے `setGreeting` کا استعمال کریں۔ + +#### `package.json` {#package-json} + +[یہ فائل](https://github.com/qbzzt/20240715-server-component/blob/main/package.json) [Node.js](https://nodejs.org/en) کنفیگریشن کو کنٹرول کرتی ہے۔ یہ مضمون صرف اہم تعریفوں کی وضاحت کرتا ہے۔ + +```json +{ + "main": "dist/index.js", +``` + +یہ تعریف بتاتی ہے کہ کون سی JavaScript فائل چلانی ہے۔ + +```json + "scripts": { + "start": "tsc && node dist/app.js", + }, +``` + +اسکرپٹس مختلف ایپلی کیشن ایکشنز ہیں۔ اس معاملے میں، ہمارے پاس صرف `start` ہے، جو سرور کو کمپائل کرتا ہے اور پھر چلاتا ہے۔ `tsc` کمانڈ `typescript` پیکیج کا حصہ ہے اور TypeScript کو JavaScript میں کمپائل کرتا ہے۔ اگر آپ اسے دستی طور پر چلانا چاہتے ہیں، تو یہ `node_modules/.bin` میں واقع ہے۔ دوسرا کمانڈ سرور کو چلاتا ہے۔ + +```json + "type": "module", +``` + +JavaScript نوڈ ایپلی کیشنز کی متعدد اقسام ہیں۔ `module` قسم ہمیں ٹاپ لیول کوڈ میں `await` رکھنے دیتی ہے، جو اس وقت اہم ہے جب آپ سست (اور وہاں غیر مطابقت پذیر) آپریشن کرتے ہیں۔ + +```json + "devDependencies": { + "@types/node": "^20.14.2", + "typescript": "^5.4.5" + }, +``` + +یہ وہ پیکیجز ہیں جن کی صرف ڈیولپمنٹ کے لیے ضرورت ہے۔ یہاں ہمیں `typescript` کی ضرورت ہے اور چونکہ ہم اسے Node.js کے ساتھ استعمال کر رہے ہیں، اس لیے ہم نوڈ متغیرات اور آبجیکٹس، جیسے `process` کے لیے بھی اقسام حاصل کر رہے ہیں۔ [`^` نوٹیشن](https://github.com/npm/node-semver?tab=readme-ov-file#caret-ranges-123-025-004) کا مطلب ہے کہ ورژن یا ایک اعلیٰ ورژن جس میں بریکنگ تبدیلیاں نہ ہوں۔ ورژن نمبروں کے معنی کے بارے میں مزید معلومات کے لیے [یہاں](https://semver.org) دیکھیں۔ + +```json + "dependencies": { + "dotenv": "^16.4.5", + "viem": "2.14.1" + } +} +``` + +یہ وہ پیکیجز ہیں جن کی رن ٹائم پر ضرورت ہوتی ہے، جب `dist/app.js` چل رہا ہو۔ + +## نتیجہ {#conclusion} + +مرکزی سرور جو ہم نے یہاں بنایا ہے وہ اپنا کام کرتا ہے، جو ایک صارف کے لیے ایک ایجنٹ کے طور پر کام کرنا ہے۔ کوئی بھی دوسرا شخص جو چاہتا ہے کہ ڈیپ کام کرتا رہے اور گیس خرچ کرنے کو تیار ہے، وہ اپنے ایڈریس کے ساتھ سرور کا ایک نیا انسٹنس چلا سکتا ہے۔ + +تاہم، یہ صرف اس وقت کام کرتا ہے جب مرکزی سرور کے اعمال کی آسانی سے تصدیق کی جا سکے۔ اگر مرکزی سرور کے پاس کوئی خفیہ اسٹیٹ کی معلومات ہے، یا مشکل حسابات چلاتا ہے، تو یہ ایک مرکزی ادارہ ہے جس پر آپ کو ایپلی کیشن استعمال کرنے کے لیے بھروسہ کرنے کی ضرورت ہے، جو بالکل وہی ہے جس سے بلاک چینز بچنے کی کوشش کرتے ہیں۔ مستقبل کے ایک مضمون میں میں یہ دکھانے کا ارادہ رکھتا ہوں کہ اس مسئلے سے نمٹنے کے لیے [zero-knowledge proofs](/zero-knowledge-proofs) کا استعمال کیسے کیا جائے۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ diff --git a/public/content/translations/ur/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/ur/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md new file mode 100644 index 00000000000..55ee0d2e638 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md @@ -0,0 +1,92 @@ +--- +title: "JavaScript میں Ethereum بلاک چین استعمال کرنے کے لئے web3.js سیٹ اپ کریں" +description: "سیکھیں کہ JavaScript ایپلیکیشنز سے Ethereum بلاک چین کے ساتھ تعامل کرنے کے لئے web3.js لائبریری کو کیسے سیٹ اپ اور کنفیگر کیا جائے۔" +author: "jdourlens" +tags: [ "web3.js", "javascript" ] +skill: beginner +lang: ur-in +published: 2020-04-11 +source: EthereumDev +sourceUrl: https://ethereumdev.io/setup-web3js-to-use-the-ethereum-blockchain-in-javascript/ +address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" +--- + +اس ٹیوٹوریل میں، ہم دیکھیں گے کہ Ethereum بلاک چین کے ساتھ تعامل کرنے کے لئے [web3.js](https://web3js.readthedocs.io/) کے ساتھ کیسے شروعات کی جائے۔ Web3.js کو فرنٹ اینڈز اور بیک اینڈز دونوں میں بلاک چین سے ڈیٹا پڑھنے، ٹرانزیکشنز کرنے اور یہاں تک کہ سمارٹ کنٹریکٹس ڈیپلائے کرنے کے لیے استعمال کیا جا سکتا ہے۔ + +پہلا قدم اپنے پروجیکٹ میں web3.js کو شامل کرنا ہے۔ اسے ویب پیج میں استعمال کرنے کے لیے، آپ JSDeliver جیسے CDN کا استعمال کرتے ہوئے لائبریری کو براہ راست امپورٹ کر سکتے ہیں۔ + +```html + +``` + +اگر آپ لائبریری کو اپنے بیک اینڈ یا فرنٹ اینڈ پروجیکٹ میں استعمال کرنے کے لیے انسٹال کرنا چاہتے ہیں جو بلڈ کا استعمال کرتا ہے تو آپ اسے npm کا استعمال کرتے ہوئے انسٹال کر سکتے ہیں: + +```bash +npm install web3 --save +``` + +پھر Web3.js کو Node.js اسکرپٹ یا Browserify فرنٹ اینڈ پروجیکٹ میں امپورٹ کرنے کے لیے، آپ JavaScript کی مندرجہ ذیل لائن استعمال کر سکتے ہیں: + +```js +const Web3 = require("web3") +``` + +اب جب کہ ہم نے پروجیکٹ میں لائبریری کو شامل کر لیا ہے، ہمیں اسے انیشلائز کرنے کی ضرورت ہے۔ آپ کے پروجیکٹ کو بلاک چین کے ساتھ کمیونیکیٹ کرنے کے قابل ہونا چاہیے۔ زیادہ تر Ethereum لائبریریاں RPC کالز کے ذریعے ایک [نوڈ](/developers/docs/nodes-and-clients/) کے ساتھ کمیونیکیٹ کرتی ہیں۔ اپنے Web3 پرووائیڈر کو شروع کرنے کے لیے، ہم پرووائیڈر کے URL کو کنسٹرکٹر کے طور پر پاس کرتے ہوئے ایک Web3 انسٹینس بنائیں گے۔ اگر آپ کے کمپیوٹر پر کوئی نوڈ یا [ganache انسٹینس چل رہا ہے](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/) تو یہ اس طرح نظر آئے گا: + +```js +const web3 = new Web3("http://localhost:8545") +``` + +اگر آپ براہ راست کسی ہوسٹڈ نوڈ تک رسائی حاصل کرنا چاہتے ہیں تو آپ [نوڈز ایز اے سروس](/developers/docs/nodes-and-clients/nodes-as-a-service) پر آپشنز تلاش کر سکتے ہیں۔ + +```js +const web3 = new Web3("https://cloudflare-eth.com") +``` + +یہ جانچنے کے لیے کہ ہم نے اپنے Web3 انسٹینس کو صحیح طریقے سے کنفیگر کیا ہے، ہم `getBlockNumber` فنکشن کا استعمال کرتے ہوئے تازہ ترین بلاک نمبر حاصل کرنے کی کوشش کریں گے۔ یہ فنکشن ایک پیرامیٹر کے طور پر کال بیک کو قبول کرتا ہے اور بلاک نمبر کو ایک انٹیجر کے طور پر واپس کرتا ہے۔ + +```js +var Web3 = require("web3") +const web3 = new Web3("https://cloudflare-eth.com") + +web3.eth.getBlockNumber(function (error, result) { + console.log(result) +}) +``` + +اگر آپ اس پروگرام کو چلاتے ہیں، تو یہ صرف تازہ ترین بلاک نمبر پرنٹ کرے گا: یعنی بلاک چین کا سب سے اوپر والا حصہ۔ آپ اپنے کوڈ میں نیسٹنگ کال بیکس سے بچنے کے لیے `await/async` فنکشن کالز کا بھی استعمال کر سکتے ہیں: + +```js +async function getBlockNumber() { + const latestBlockNumber = await web3.eth.getBlockNumber() + console.log(latestBlockNumber) + return latestBlockNumber +} + +getBlockNumber() +``` + +آپ Web3 انسٹینس پر دستیاب تمام فنکشنز کو [web3.js کی آفیشل ڈاکومنٹیشن](https://docs.web3js.org/) میں دیکھ سکتے ہیں۔ + +زیادہ تر Web3 لائبریریاں ایسنکرونس ہوتی ہیں کیونکہ بیک گراؤنڈ میں لائبریری نوڈ کو JSON-RPC کالز کرتی ہے جو نتیجہ واپس بھیجتا ہے۔ + + + +اگر آپ براؤزر میں کام کر رہے ہیں، تو کچھ والیٹس براہ راست ایک Web3 انسٹینس انجیکٹ کرتے ہیں اور آپ کو جب بھی ممکن ہو اسے استعمال کرنے کی کوشش کرنی چاہیے، خاص طور پر اگر آپ ٹرانزیکشنز کرنے کے لیے صارف کے Ethereum ایڈریس کے ساتھ تعامل کرنے کا ارادہ رکھتے ہیں۔ + +یہاں یہ پتہ لگانے کے لیے سنیپٹ ہے کہ آیا MetaMask والیٹ دستیاب ہے اور اگر ہے تو اسے فعال کرنے کی کوشش کریں۔ یہ بعد میں آپ کو صارف کا بیلنس پڑھنے اور انہیں ان ٹرانزیکشنز کی توثیق کرنے کے قابل بنائے گا جو آپ ان سے Ethereum بلاک چین پر کروانا چاہتے ہیں: + +```js +if (window.ethereum != null) { + state.web3 = new Web3(window.ethereum) + try { + // اگر ضرورت ہو تو اکاؤنٹ تک رسائی کی درخواست کریں + await window.ethereum.enable() + // اکاؤنٹس اب ظاہر ہو گئے ہیں + } catch (error) { + // صارف نے اکاؤنٹ تک رسائی سے انکار کر دیا... + } +} +``` + +web3.js کے متبادل جیسے [Ethers.js](https://docs.ethers.io/) موجود ہیں اور عام طور پر استعمال بھی ہوتے ہیں۔ اگلے ٹیوٹوریل میں ہم دیکھیں گے کہ [بلاک چین پر نئے آنے والے بلاکس کو آسانی سے کیسے سنا جائے اور دیکھیں کہ ان میں کیا ہے](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/)۔ diff --git a/public/content/translations/ur/developers/tutorials/short-abi/index.md b/public/content/translations/ur/developers/tutorials/short-abi/index.md new file mode 100644 index 00000000000..3f37c69fa04 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/short-abi/index.md @@ -0,0 +1,585 @@ +--- +title: "کال ڈیٹا آپٹمائزیشن کے لیے مختصر ABIs" +description: "آپٹیمسٹک رول اپس کے لیے اسمارٹ کنٹریکٹس کو آپٹمائز کرنا" +author: Ori Pomerantz +lang: ur-in +tags: [ "لیئر 2" ] +skill: intermediate +published: 2022-04-01 +--- + +## تعارف {#introduction} + +اس مضمون میں، آپ [optimistic rollups](/developers/docs/scaling/optimistic-rollups)، ان پر ٹرانزیکشنز کی لاگت، اور اس بارے میں جانیں گے کہ کس طرح یہ مختلف لاگت کا ڈھانچہ ہمیں Ethereum Mainnet کے مقابلے میں مختلف چیزوں کے لیے آپٹمائز کرنے کا تقاضا کرتا ہے۔ +آپ یہ بھی سیکھیں گے کہ اس آپٹمائزیشن کو کیسے نافذ کیا جائے۔ + +### مکمل انکشاف {#full-disclosure} + +میں [Optimism](https://www.optimism.io/) کا کل وقتی ملازم ہوں، اس لیے اس مضمون میں مثالیں Optimism پر چلیں گی۔ +تاہم، یہاں بیان کردہ تکنیک دیگر رول اپس کے لیے بھی اتنی ہی اچھی طرح کام کرنی چاہیے۔ + +### اصطلاحات {#terminology} + +رول اپس پر بحث کرتے وقت، 'لیئر 1' (L1) کی اصطلاح Mainnet، یعنی پروڈکشن Ethereum نیٹ ورک کے لیے استعمال ہوتی ہے۔ +'لیئر 2' (L2) کی اصطلاح رول اپ یا کسی دوسرے ایسے سسٹم کے لیے استعمال ہوتی ہے جو سیکیورٹی کے لیے L1 پر انحصار کرتا ہے لیکن اپنی زیادہ تر پروسیسنگ آف چین کرتا ہے۔ + +## ہم L2 ٹرانزیکشنز کی لاگت کو مزید کیسے کم کر سکتے ہیں؟ {#how-can-we-further-reduce-the-cost-of-L2-transactions} + +[آپٹیمسٹک رول اپس](/developers/docs/scaling/optimistic-rollups) کو ہر تاریخی ٹرانزیکشن کا ریکارڈ محفوظ رکھنا ہوتا ہے تاکہ کوئی بھی ان کا جائزہ لے سکے اور اس بات کی تصدیق کر سکے کہ موجودہ اسٹیٹ درست ہے۔ +Ethereum Mainnet میں ڈیٹا داخل کرنے کا سب سے سستا طریقہ اسے کال ڈیٹا کے طور پر لکھنا ہے۔ +یہ حل [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) اور [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups) دونوں نے منتخب کیا تھا۔ + +### L2 ٹرانزیکشنز کی لاگت {#cost-of-l2-transactions} + +L2 ٹرانزیکشنز کی لاگت دو اجزاء پر مشتمل ہے: + +1. L2 پروسیسنگ، جو عام طور پر انتہائی سستی ہوتی ہے +2. L1 اسٹوریج، جو Mainnet گیس کی لاگت سے منسلک ہے + +جب میں یہ لکھ رہا ہوں، Optimism پر L2 گیس کی لاگت 0.001 [Gwei](/developers/docs/gas/#pre-london) ہے۔ +دوسری طرف، L1 گیس کی لاگت تقریباً 40 gwei ہے۔ +[آپ موجودہ قیمتیں یہاں دیکھ سکتے ہیں](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m)۔ + +کال ڈیٹا کے ایک بائٹ کی لاگت یا تو 4 گیس ہے (اگر یہ صفر ہے) یا 16 گیس ہے (اگر یہ کوئی اور قدر ہے)۔ +EVM پر سب سے مہنگے آپریشنز میں سے ایک اسٹوریج میں لکھنا ہے۔ +L2 پر اسٹوریج میں 32 بائٹ کا ورڈ لکھنے کی زیادہ سے زیادہ لاگت 22100 گیس ہے۔ فی الحال، یہ 22.1 gwei ہے۔ +لہذا اگر ہم کال ڈیٹا کا ایک صفر بائٹ بچا سکتے ہیں، تو ہم اسٹوریج میں تقریباً 200 بائٹ لکھ سکیں گے اور پھر بھی فائدے میں رہیں گے۔ + +### ABI {#the-abi} + +ٹرانزیکشنز کی بڑی اکثریت ایک بیرونی ملکیت والے اکاؤنٹ سے ایک کنٹریکٹ تک رسائی حاصل کرتی ہے۔ +زیادہ تر کنٹریکٹس Solidity میں لکھے جاتے ہیں اور اپنے ڈیٹا فیلڈ کی تشریح [ایپلیکیشن بائنری انٹرفیس (ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding) کے مطابق کرتے ہیں۔ + +تاہم، ABI کو L1 کے لیے ڈیزائن کیا گیا تھا، جہاں کال ڈیٹا کے ایک بائٹ کی لاگت تقریباً چار ریاضیاتی آپریشنز کے برابر ہے، نہ کہ L2 کے لیے جہاں کال ڈیٹا کے ایک بائٹ کی لاگت ایک ہزار سے زیادہ ریاضیاتی آپریشنز کے برابر ہے۔ +کال ڈیٹا کو اس طرح تقسیم کیا گیا ہے: + +| سیکشن | لمبائی | بائٹس | ضائع شدہ بائٹس | ضائع شدہ گیس | ضروری بائٹس | ضروری گیس | +| ------------ | -----: | ----: | -------------: | -----------: | ----------: | --------: | +| فنکشن سلیکٹر | 4 | 0-3 | 3 | 48 | 1 | 16 | +| صفر | 12 | 4-15 | 12 | 48 | 0 | 0 | +| منزل کا پتہ | 20 | 16-35 | 0 | 0 | 20 | 320 | +| رقم | 32 | 36-67 | 17 | 64 | 15 | 240 | +| کل | 68 | | | 160 | | 576 | + +وضاحت: + +- **فنکشن سلیکٹر**: کنٹریکٹ میں 256 سے کم فنکشنز ہیں، اس لیے ہم ایک بائٹ سے ان میں فرق کر سکتے ہیں۔ + یہ بائٹس عام طور پر غیر صفر ہوتے ہیں اور اس لیے ان کی [لاگت سولہ گیس](https://eips.ethereum.org/EIPS/eip-2028) ہوتی ہے۔ +- **صفر**: یہ بائٹس ہمیشہ صفر ہوتے ہیں کیونکہ بیس بائٹ کے پتے کو رکھنے کے لیے بتیس بائٹ کے ورڈ کی ضرورت نہیں ہوتی۔ + صفر رکھنے والے بائٹس کی لاگت چار گیس ہوتی ہے ([یلو پیپر دیکھیں](https://ethereum.github.io/yellowpaper/paper.pdf)، ضمیمہ G، + صفحہ 27، `G``txdatazero` کی قدر)۔ +- **رقم**: اگر ہم فرض کریں کہ اس کنٹریکٹ میں `decimals` اٹھارہ (عام قدر) ہے اور ٹوکنز کی زیادہ سے زیادہ رقم جو ہم منتقل کریں گے 1018 ہوگی، تو ہمیں 1036 کی زیادہ سے زیادہ رقم ملتی ہے۔ + 25615 > 1036، اس لیے پندرہ بائٹس کافی ہیں۔ + +L1 پر 160 گیس کا ضیاع عام طور پر نہ ہونے کے برابر ہے۔ ایک ٹرانزیکشن کی لاگت کم از کم [21,000 گیس](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed) ہوتی ہے، اس لیے اضافی 0.8% سے کوئی فرق نہیں پڑتا۔ +تاہم، L2 پر، چیزیں مختلف ہیں۔ ٹرانزیکشن کی تقریباً پوری لاگت اسے L1 پر لکھنا ہے۔ +ٹرانزیکشن کال ڈیٹا کے علاوہ، ٹرانزیکشن ہیڈر کے 109 بائٹس ہوتے ہیں (منزل کا پتہ، دستخط، وغیرہ)۔ +اس لیے کل لاگت `109*16+576+160=2480` ہے، اور ہم اس کا تقریباً 6.5% ضائع کر رہے ہیں۔ + +## لاگت کم کرنا جب آپ منزل کو کنٹرول نہیں کرتے {#reducing-costs-when-you-dont-control-the-destination} + +یہ فرض کرتے ہوئے کہ آپ کا منزل کے کنٹریکٹ پر کوئی کنٹرول نہیں ہے، آپ پھر بھی [اس والے](https://github.com/qbzzt/ethereum.org-20220330-shortABI) جیسا حل استعمال کر سکتے ہیں۔ +آئیے متعلقہ فائلوں کا جائزہ لیں۔ + +### Token.sol {#token-sol} + +[یہ منزل کا کنٹریکٹ ہے](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol)۔ +یہ ایک معیاری ERC-20 کنٹریکٹ ہے، جس میں ایک اضافی خصوصیت ہے۔ +یہ `faucet` فنکشن کسی بھی صارف کو استعمال کرنے کے لیے کچھ ٹوکن حاصل کرنے دیتا ہے۔ +یہ ایک پروڈکشن ERC-20 کنٹریکٹ کو بیکار بنا دے گا، لیکن یہ زندگی کو آسان بنا دیتا ہے جب ایک ERC-20 صرف ٹیسٹنگ کی سہولت کے لیے موجود ہو۔ + +```solidity + /** + * @dev کالر کو کھیلنے کے لیے 1000 ٹوکن دیتا ہے + */ + function faucet() external { + _mint(msg.sender, 1000); + } // فنکشن faucet +``` + +### CalldataInterpreter.sol {#calldatainterpreter-sol} + +[یہ وہ کنٹریکٹ ہے جسے ٹرانزیکشنز کو مختصر کال ڈیٹا کے ساتھ کال کرنا چاہیے](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol)۔ +آئیے اس کا لائن بہ لائن جائزہ لیں۔ + +```solidity +//SPDX-License-Identifier: Unlicense +pragma solidity ^0.8.0; + + +import { OrisUselessToken } from "./Token.sol"; +``` + +ہمیں ٹوکن فنکشن کی ضرورت ہے تاکہ یہ جان سکیں کہ اسے کیسے کال کرنا ہے۔ + +```solidity +contract CalldataInterpreter { + + OrisUselessToken public immutable token; +``` + +اس ٹوکن کا پتہ جس کے لیے ہم پراکسی ہیں۔ + +```solidity + + /** + * @dev ٹوکن کا پتہ متعین کریں + * @param tokenAddr_ ERC-20 کنٹریکٹ کا پتہ + */ + constructor( + address tokenAddr_ + ) { + token = OrisUselessToken(tokenAddr_); + } // constructor +``` + +ٹوکن کا پتہ ہی واحد پیرامیٹر ہے جسے ہمیں متعین کرنے کی ضرورت ہے۔ + +```solidity + function calldataVal(uint startByte, uint length) + private pure returns (uint) { +``` + +کال ڈیٹا سے ایک قدر پڑھیں۔ + +```solidity + uint _retVal; + + require(length < 0x21, + "calldataVal لمبائی کی حد 32 بائٹس ہے"); + + require(length + startByte <= msg.data.length, + "calldataVal کال ڈیٹا سائز سے آگے پڑھنے کی کوشش کر رہا ہے"); +``` + +ہم میموری میں ایک 32-بائٹ (256-بٹ) ورڈ لوڈ کرنے جا رہے ہیں اور ان بائٹس کو ہٹانے جا رہے ہیں جو اس فیلڈ کا حصہ نہیں ہیں جسے ہم چاہتے ہیں۔ +یہ الگورتھم 32 بائٹس سے لمبی قدروں کے لیے کام نہیں کرتا، اور یقیناً ہم کال ڈیٹا کے آخر سے آگے نہیں پڑھ سکتے۔ +L1 پر گیس بچانے کے لیے ان ٹیسٹوں کو چھوڑنا ضروری ہو سکتا ہے، لیکن L2 پر گیس انتہائی سستی ہے، جو ہمارے ذہن میں آنے والے کسی بھی قسم کے سیفٹی چیکس کو ممکن بناتی ہے۔ + +```solidity + assembly { + _retVal := calldataload(startByte) + } +``` + +ہم `fallback()` (نیچے دیکھیں) کی کال سے ڈیٹا کاپی کر سکتے تھے، لیکن [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html) کا استعمال کرنا آسان ہے، جو EVM کی اسمبلی لینگویج ہے۔ + +یہاں ہم [CALLDATALOAD opcode](https://www.evm.codes/#35) کا استعمال کرتے ہیں تاکہ بائٹس `startByte` سے `startByte+31` کو اسٹیک میں پڑھ سکیں۔ +عام طور پر، Yul میں ایک opcode کا نحو یہ ہے `(,...)` + +```solidity + + _retVal = _retVal >> (256-length*8); +``` + +صرف سب سے اہم `length` بائٹس فیلڈ کا حصہ ہیں، اس لیے ہم دوسری قدروں سے چھٹکارا پانے کے لیے [رائٹ-شفٹ](https://en.wikipedia.org/wiki/Logical_shift) کرتے ہیں۔ +اس کا اضافی فائدہ یہ ہے کہ یہ قدر کو فیلڈ کے دائیں طرف منتقل کر دیتا ہے، لہذا یہ خود قدر ہے بجائے اس کے کہ قدر کو 256کچھ سے ضرب دیا جائے۔ + +```solidity + + return _retVal; + } + + + fallback() external { +``` + +جب ایک Solidity کنٹریکٹ کو کی گئی کال کسی بھی فنکشن کے دستخط سے مماثل نہیں ہوتی ہے، تو یہ [the `fallback()` function](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) کو کال کرتی ہے (یہ فرض کرتے ہوئے کہ کوئی موجود ہے)۔ +`CalldataInterpreter` کے معاملے میں، _کوئی بھی_ کال یہاں پہنچتی ہے کیونکہ کوئی دوسرا `external` یا `public` فنکشن نہیں ہے۔ + +```solidity + uint _func; + + _func = calldataVal(0, 1); +``` + +کال ڈیٹا کا پہلا بائٹ پڑھیں، جو ہمیں فنکشن بتاتا ہے۔ +دو وجوہات ہیں کہ کوئی فنکشن یہاں دستیاب کیوں نہیں ہوگا: + +1. جو فنکشنز `pure` یا `view` ہیں وہ اسٹیٹ کو تبدیل نہیں کرتے اور گیس کی لاگت نہیں اٹھاتے (جب آف چین کال کیا جاتا ہے)۔ + ان کی گیس کی لاگت کو کم کرنے کی کوشش کرنا کوئی معنی نہیں رکھتا۔ +2. وہ فنکشنز جو [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties) پر انحصار کرتے ہیں۔ + `msg.sender` کی قدر `CalldataInterpreter` کا پتہ ہوگی، کالر کا نہیں۔ + +بدقسمتی سے، [looking at the ERC-20 specifications](https://eips.ethereum.org/EIPS/eip-20) کو دیکھنے پر، یہ صرف ایک فنکشن، `transfer` چھوڑتا ہے۔ +یہ ہمارے پاس صرف دو فنکشنز چھوڑتا ہے: `transfer` (کیونکہ ہم `transferFrom` کو کال کر سکتے ہیں) اور `faucet` (کیونکہ ہم ٹوکنز کو واپس اسی کو منتقل کر سکتے ہیں جس نے ہمیں کال کیا)۔ + +```solidity + + // کال ڈیٹا سے معلومات کا استعمال کرتے ہوئے ٹوکن کے + // اسٹیٹ کو تبدیل کرنے والے طریقوں کو کال کریں + + // faucet + if (_func == 1) { +``` + +`faucet()` کو ایک کال، جس میں پیرامیٹرز نہیں ہوتے۔ + +```solidity + token.faucet(); + token.transfer(msg.sender, + token.balanceOf(address(this))); + } +``` + +جب ہم `token.faucet()` کو کال کرتے ہیں تو ہمیں ٹوکن ملتے ہیں۔ تاہم، پراکسی کنٹریکٹ کے طور پر، ہمیں ٹوکنز کی **ضرورت** نہیں ہے۔ +EOA (بیرونی ملکیت والا اکاؤنٹ) یا وہ کنٹریکٹ جس نے ہمیں کال کیا تھا اسے ضرورت ہے۔ +لہذا ہم اپنے تمام ٹوکنز اس کو منتقل کر دیتے ہیں جس نے ہمیں کال کیا تھا۔ + +```solidity + // منتقلی (فرض کریں کہ ہمارے پاس اس کے لیے الاؤنس ہے) + if (_func == 2) { +``` + +ٹوکنز کی منتقلی کے لیے دو پیرامیٹرز کی ضرورت ہوتی ہے: منزل کا پتہ اور رقم۔ + +```solidity + token.transferFrom( + msg.sender, +``` + +ہم صرف کال کرنے والوں کو اپنے ملکیت والے ٹوکن منتقل کرنے کی اجازت دیتے ہیں + +```solidity + address(uint160(calldataVal(1, 20))), +``` + +منزل کا پتہ بائٹ #1 سے شروع ہوتا ہے (بائٹ #0 فنکشن ہے)۔ +ایک پتے کے طور پر، یہ 20-بائٹس لمبا ہے۔ + +```solidity + calldataVal(21, 2) +``` + +اس خاص کنٹریکٹ کے لیے ہم فرض کرتے ہیں کہ کوئی بھی شخص جو زیادہ سے زیادہ ٹوکن منتقل کرنا چاہے گا وہ دو بائٹس (65536 سے کم) میں فٹ ہو جائے گا۔ + +```solidity + ); + } +``` + +مجموعی طور پر، ایک منتقلی میں کال ڈیٹا کے 35 بائٹس لگتے ہیں: + +| سیکشن | لمبائی | بائٹس | +| ------------ | -----: | ----: | +| فنکشن سلیکٹر | 1 | 0 | +| منزل کا پتہ | 32 | 1-32 | +| رقم | 2 | 33-34 | + +```solidity + } // fallback + +} // contract CalldataInterpreter +``` + +### test.js {#test-js} + +[یہ JavaScript یونٹ ٹیسٹ](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) ہمیں دکھاتا ہے کہ اس میکانزم کا استعمال کیسے کریں (اور اس کی تصدیق کیسے کریں کہ یہ صحیح طریقے سے کام کرتا ہے)۔ +میں یہ فرض کر رہا ہوں کہ آپ [chai](https://www.chaijs.com/) اور [ethers](https://docs.ethers.io/v5/) کو سمجھتے ہیں اور صرف ان حصوں کی وضاحت کروں گا جو خاص طور پر کنٹریکٹ پر لاگو ہوتے ہیں۔ + +```js +const { expect } = require("chai"); + +describe("CalldataInterpreter", function () { + it("Should let us use tokens", async function () { + const Token = await ethers.getContractFactory("OrisUselessToken") + const token = await Token.deploy() + await token.deployed() + console.log("Token addr:", token.address) + + const Cdi = await ethers.getContractFactory("CalldataInterpreter") + const cdi = await Cdi.deploy(token.address) + await cdi.deployed() + console.log("CalldataInterpreter addr:", cdi.address) + + const signer = await ethers.getSigner() +``` + +ہم دونوں کنٹریکٹس کو تعینات کرکے شروع کرتے ہیں۔ + +```javascript + // کھیلنے کے لیے ٹوکن حاصل کریں + const faucetTx = { +``` + +ہم ٹرانزیکشنز بنانے کے لیے عام طور پر استعمال ہونے والے اعلیٰ سطحی فنکشنز (جیسے `token.faucet()`) کا استعمال نہیں کر سکتے، کیونکہ ہم ABI کی پیروی نہیں کرتے۔ +اس کے بجائے، ہمیں خود ٹرانزیکشن بنانا ہوگا اور پھر اسے بھیجنا ہوگا۔ + +```javascript + to: cdi.address, + data: "0x01" +``` + +ٹرانزیکشن کے لیے ہمیں دو پیرامیٹرز فراہم کرنے کی ضرورت ہے: + +1. `to`، منزل کا پتہ۔ + یہ کال ڈیٹا انٹرپریٹر کنٹریکٹ ہے۔ +2. `data`، بھیجنے کے لیے کال ڈیٹا۔ + faucet کال کی صورت میں، ڈیٹا ایک بائٹ، `0x01` ہے۔ + +```javascript + + } + await (await signer.sendTransaction(faucetTx)).wait() +``` + +ہم [the signer's `sendTransaction` method](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction) کو کال کرتے ہیں کیونکہ ہم نے پہلے ہی منزل (`faucetTx.to`) کی وضاحت کر دی ہے اور ہمیں ٹرانزیکشن پر دستخط کرنے کی ضرورت ہے۔ + +```javascript +// چیک کریں کہ faucet ٹوکنز کو صحیح طریقے سے فراہم کرتا ہے +expect(await token.balanceOf(signer.address)).to.equal(1000) +``` + +یہاں ہم بیلنس کی تصدیق کرتے ہیں۔ +`view` فنکشنز پر گیس بچانے کی ضرورت نہیں ہے، لہذا ہم انہیں عام طور پر چلاتے ہیں۔ + +```javascript +// CDI کو ایک الاؤنس دیں (منظوریوں کو پراکسی نہیں کیا جا سکتا) +const approveTX = await token.approve(cdi.address, 10000) +await approveTX.wait() +expect(await token.allowance(signer.address, cdi.address)).to.equal(10000) +``` + +منتقلی کرنے کے قابل ہونے کے لیے کال ڈیٹا انٹرپریٹر کو ایک الاؤنس دیں۔ + +```javascript +// ٹوکن منتقل کریں +const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d" +const transferTx = { + to: cdi.address, + data: "0x02" + destAddr.slice(2, 42) + "0100", +} +``` + +ایک منتقلی کا ٹرانزیکشن بنائیں۔ پہلا بائٹ "0x02" ہے، اس کے بعد منزل کا پتہ، اور آخر میں رقم (0x0100، جو ڈیسیمل میں 256 ہے)۔ + +```javascript + await (await signer.sendTransaction(transferTx)).wait() + + // چیک کریں کہ ہمارے پاس 256 ٹوکن کم ہیں + expect (await token.balanceOf(signer.address)).to.equal(1000-256) + + // اور یہ کہ ہماری منزل کو وہ مل گئے ہیں + expect (await token.balanceOf(destAddr)).to.equal(256) + }) // it +}) // describe +``` + +## لاگت کو کم کرنا جب آپ منزل کے کنٹریکٹ کو کنٹرول کرتے ہیں {#reducing-the-cost-when-you-do-control-the-destination-contract} + +اگر آپ کا منزل کے کنٹریکٹ پر کنٹرول ہے تو آپ ایسے فنکشنز بنا سکتے ہیں جو `msg.sender` چیکس کو بائی پاس کرتے ہیں کیونکہ وہ کال ڈیٹا انٹرپریٹر پر بھروسہ کرتے ہیں۔ +[آپ یہاں اس کی ایک مثال دیکھ سکتے ہیں کہ یہ کیسے کام کرتا ہے، `control-contract` برانچ میں](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract)۔ + +اگر کنٹریکٹ صرف بیرونی ٹرانزیکشنز کا جواب دے رہا ہوتا، تو ہم صرف ایک کنٹریکٹ کے ساتھ کام چلا سکتے تھے۔ +تاہم، اس سے [composability](/developers/docs/smart-contracts/composability/) ٹوٹ جائے گی۔ +ایک ایسا کنٹریکٹ رکھنا بہت بہتر ہے جو عام ERC-20 کالز کا جواب دے، اور دوسرا کنٹریکٹ جو مختصر کال ڈیٹا والے ٹرانزیکشنز کا جواب دے۔ + +### Token.sol {#token-sol-2} + +اس مثال میں ہم `Token.sol` میں ترمیم کر سکتے ہیں۔ +یہ ہمیں کئی ایسے فنکشنز رکھنے کی اجازت دیتا ہے جنہیں صرف پراکسی ہی کال کر سکتا ہے۔ +یہاں نئے حصے ہیں: + +```solidity + // CalldataInterpreter ایڈریس کی وضاحت کرنے کی اجازت والا واحد ایڈریس + address owner; + + // CalldataInterpreter ایڈریس + address proxy = address(0); +``` + +ERC-20 کنٹریکٹ کو مجاز پراکسی کی شناخت جاننے کی ضرورت ہے۔ +تاہم، ہم اس متغیر کو کنسٹرکٹر میں سیٹ نہیں کر سکتے، کیونکہ ہمیں ابھی تک قدر کا علم نہیں ہے۔ +یہ کنٹریکٹ پہلے انسٹینٹی ایٹ کیا جاتا ہے کیونکہ پراکسی اپنے کنسٹرکٹر میں ٹوکن کے پتے کی توقع کرتا ہے۔ + +```solidity + /** + * @dev ERC20 کنسٹرکٹر کو کال کرتا ہے۔ + */ + constructor( + ) ERC20("Oris useless token-2", "OUT-2") { + owner = msg.sender; + } +``` + +تخلیق کار کا پتہ (جسے `owner` کہا جاتا ہے) یہاں ذخیرہ کیا جاتا ہے کیونکہ یہ واحد پتہ ہے جسے پراکسی سیٹ کرنے کی اجازت ہے۔ + +```solidity + /** + * @dev پراکسی (CalldataInterpreter) کے لیے پتہ سیٹ کریں۔ + * مالک کے ذریعہ صرف ایک بار کال کیا جاسکتا ہے + */ + function setProxy(address _proxy) external { + require(msg.sender == owner, "صرف مالک کے ذریعہ کال کیا جاسکتا ہے"); + require(proxy == address(0), "پراکسی پہلے ہی سیٹ ہے"); + + proxy = _proxy; + } // فنکشن setProxy +``` + +پراکسی کو مراعات یافتہ رسائی حاصل ہے، کیونکہ یہ سیکیورٹی چیک کو بائی پاس کر سکتا ہے۔ +یہ یقینی بنانے کے لیے کہ ہم پراکسی پر بھروسہ کر سکتے ہیں، ہم صرف `owner` کو اس فنکشن کو کال کرنے دیتے ہیں، اور صرف ایک بار۔ +ایک بار جب `proxy` کی کوئی حقیقی قدر (صفر نہیں) ہو جاتی ہے، تو وہ قدر تبدیل نہیں ہو سکتی، لہذا یہاں تک کہ اگر مالک بدمعاش بننے کا فیصلہ کرتا ہے، یا اس کے لیے میمونک ظاہر ہو جاتا ہے، ہم پھر بھی محفوظ ہیں۔ + +```solidity + /** + * @dev کچھ فنکشنز صرف پراکسی کے ذریعے ہی کال کیے جا سکتے ہیں۔ + */ + modifier onlyProxy { +``` + +یہ ایک [`modifier` function](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) ہے، یہ دوسرے فنکشنز کے کام کرنے کے طریقے میں ترمیم کرتا ہے۔ + +```solidity + require(msg.sender == proxy); +``` + +سب سے پہلے، تصدیق کریں کہ ہمیں پراکسی نے کال کیا ہے اور کسی اور نے نہیں۔ +اگر نہیں، تو `revert` کریں۔ + +```solidity + _; + } +``` + +اگر ایسا ہے تو، اس فنکشن کو چلائیں جس میں ہم ترمیم کرتے ہیں۔ + +```solidity + /* وہ فنکشنز جو پراکسی کو اکاؤنٹس کے لیے پراکسی کرنے کی اجازت دیتے ہیں */ + + function transferProxy(address from, address to, uint256 amount) + public virtual onlyProxy() returns (bool) + { + _transfer(from, to, amount); + return true; + } + + function approveProxy(address from, address spender, uint256 amount) + public virtual onlyProxy() returns (bool) + { + _approve(from, spender, amount); + return true; + } + + function transferFromProxy( + address spender, + address from, + address to, + uint256 amount + ) public virtual onlyProxy() returns (bool) + { + _spendAllowance(from, spender, amount); + _transfer(from, to, amount); + return true; + } +``` + +یہ تین آپریشنز ہیں جن کے لیے عام طور پر پیغام کو براہ راست ٹوکن منتقل کرنے یا الاؤنس منظور کرنے والی ہستی سے آنے کی ضرورت ہوتی ہے۔ +یہاں ہمارے پاس ان آپریشنز کا ایک پراکسی ورژن ہے جو: + +1. `onlyProxy()` کے ذریعے ترمیم کیا گیا ہے تاکہ کسی اور کو انہیں کنٹرول کرنے کی اجازت نہ ہو۔ +2. وہ پتہ حاصل کرتا ہے جو عام طور پر `msg.sender` ہوگا ایک اضافی پیرامیٹر کے طور پر۔ + +### CalldataInterpreter.sol {#calldatainterpreter-sol-2} + +کال ڈیٹا انٹرپریٹر اوپر والے سے تقریباً مماثل ہے، سوائے اس کے کہ پراکسیڈ فنکشنز کو `msg.sender` پیرامیٹر ملتا ہے اور `transfer` کے لیے الاؤنس کی کوئی ضرورت نہیں ہے۔ + +```solidity + // منتقلی (الاؤنس کی ضرورت نہیں) + if (_func == 2) { + token.transferProxy( + msg.sender, + address(uint160(calldataVal(1, 20))), + calldataVal(21, 2) + ); + } + + // منظوری + if (_func == 3) { + token.approveProxy( + msg.sender, + address(uint160(calldataVal(1, 20))), + calldataVal(21, 2) + ); + } + + // transferFrom + if (_func == 4) { + token.transferFromProxy( + msg.sender, + address(uint160(calldataVal( 1, 20))), + address(uint160(calldataVal(21, 20))), + calldataVal(41, 2) + ); + } +``` + +### Test.js {#test-js-2} + +پچھلے ٹیسٹنگ کوڈ اور اس کے درمیان کچھ تبدیلیاں ہیں۔ + +```js +const Cdi = await ethers.getContractFactory("CalldataInterpreter") +const cdi = await Cdi.deploy(token.address) +await cdi.deployed() +await token.setProxy(cdi.address) +``` + +ہمیں ERC-20 کنٹریکٹ کو یہ بتانے کی ضرورت ہے کہ کس پراکسی پر بھروسہ کرنا ہے + +```js +console.log("CalldataInterpreter addr:", cdi.address) + +// الاؤنس کی تصدیق کے لیے دو دستخط کنندگان کی ضرورت ہے +const signers = await ethers.getSigners() +const signer = signers[0] +const poorSigner = signers[1] +``` + +`approve()` اور `transferFrom()` کو چیک کرنے کے لیے ہمیں دوسرے دستخط کنندہ کی ضرورت ہے۔ +ہم اسے `poorSigner` کہتے ہیں کیونکہ اسے ہمارے کوئی ٹوکن نہیں ملتے (اس کے پاس ETH ہونا ضروری ہے، یقیناً)۔ + +```js +// ٹوکن منتقل کریں +const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d" +const transferTx = { + to: cdi.address, + data: "0x02" + destAddr.slice(2, 42) + "0100", +} +await (await signer.sendTransaction(transferTx)).wait() +``` + +کیونکہ ERC-20 کنٹریکٹ پراکسی (`cdi`) پر بھروسہ کرتا ہے، ہمیں منتقلیوں کو ریلے کرنے کے لیے الاؤنس کی ضرورت نہیں ہے۔ + +```js +// منظوری اور transferFrom +const approveTx = { + to: cdi.address, + data: "0x03" + poorSigner.address.slice(2, 42) + "00FF", +} +await (await signer.sendTransaction(approveTx)).wait() + +const destAddr2 = "0xE1165C689C0c3e9642cA7606F5287e708d846206" + +const transferFromTx = { + to: cdi.address, + data: "0x04" + signer.address.slice(2, 42) + destAddr2.slice(2, 42) + "00FF", +} +await (await poorSigner.sendTransaction(transferFromTx)).wait() + +// چیک کریں کہ منظوری / transferFrom کا امتزاج صحیح طریقے سے کیا گیا تھا +expect(await token.balanceOf(destAddr2)).to.equal(255) +``` + +دو نئے فنکشنز کی جانچ کریں۔ +نوٹ کریں کہ `transferFromTx` کو دو ایڈریس پیرامیٹرز کی ضرورت ہے: الاؤنس دینے والا اور وصول کنندہ۔ + +## نتیجہ {#conclusion} + +دونوں [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) اور [Arbitrum](https://developer.offchainlabs.com/docs/special_features) L1 پر لکھے گئے کال ڈیٹا کے سائز کو کم کرنے اور اس وجہ سے ٹرانزیکشنز کی لاگت کو کم کرنے کے طریقے تلاش کر رہے ہیں۔ +تاہم، عام حل تلاش کرنے والے بنیادی ڈھانچے فراہم کرنے والوں کے طور پر، ہماری صلاحیتیں محدود ہیں۔ +ڈ ایپ ڈیولپر کے طور پر، آپ کے پاس ایپلیکیشن کے لیے مخصوص علم ہے، جو آپ کو اپنے کال ڈیٹا کو ہم سے کہیں بہتر طور پر آپٹمائز کرنے دیتا ہے جتنا کہ ہم ایک عام حل میں کر سکتے ہیں۔ +امید ہے کہ یہ مضمون آپ کو اپنی ضروریات کے لیے مثالی حل تلاش کرنے میں مدد کرے گا۔ + +[میرے مزید کام کے لیے یہاں دیکھیں](https://cryptodocguy.pro/)۔ + diff --git a/public/content/translations/ur/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/ur/developers/tutorials/smart-contract-security-guidelines/index.md new file mode 100644 index 00000000000..82035f97ad6 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/smart-contract-security-guidelines/index.md @@ -0,0 +1,91 @@ +--- +title: "اسمارٹ کنٹریکٹ سیکیورٹی گائیڈ لائنز" +description: "اپنا ڈیپ بناتے وقت غور کرنے کے لیے سیکیورٹی گائیڈ لائنز کی ایک چیک لسٹ" +author: "Trailofbits" +tags: [ "solidity", "اسمارٹ معاہدات", "سیکورٹی" ] +skill: intermediate +lang: ur-in +published: 2020-09-06 +source: Building secure contracts +sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md +--- + +مزید محفوظ اسمارٹ کنٹریکٹس بنانے کے لیے ان اعلیٰ سطحی سفارشات پر عمل کریں۔ + +## ڈیزائن کے رہنما اصول {#design-guidelines} + +کنٹریکٹ کے ڈیزائن پر پہلے سے، کوڈ کی کوئی بھی لائن لکھنے سے پہلے بات چیت کی جانی چاہیے۔ + +### دستاویزات اور وضاحتیں {#documentation-and-specifications} + +دستاویزات مختلف سطحوں پر لکھی جا سکتی ہیں، اور کنٹریکٹس کو نافذ کرتے وقت اسے اپ ڈیٹ کیا جانا چاہیے: + +- **سسٹم کی سادہ انگریزی میں تفصیل**، یہ بیان کرتے ہوئے کہ کنٹریکٹس کیا کرتے ہیں اور کوڈبیس پر کوئی بھی مفروضہ۔ +- **اسکیما اور آرکیٹیکچرل ڈایاگرام**، بشمول کنٹریکٹ کے تعاملات اور سسٹم کی اسٹیٹ مشین۔ [Slither پرنٹرز](https://github.com/crytic/slither/wiki/Printer-documentation) ان اسکیماز کو بنانے میں مدد کر سکتے ہیں۔ +- **مکمل کوڈ دستاویزات**، [Natspec فارمیٹ](https://docs.soliditylang.org/en/develop/natspec-format.html) Solidity کے لیے استعمال کیا جا سکتا ہے۔ + +### آن چین بمقابلہ آف چین کمپیوٹیشن {#onchain-vs-offchain-computation} + +- **جتنا ہو سکے کوڈ کو آف چین رکھیں۔** آن چین لیئر کو چھوٹا رکھیں۔ آف چین کوڈ کے ساتھ ڈیٹا کو اس طرح پہلے سے پروسیس کریں کہ آن چین تصدیق آسان ہو۔ کیا آپ کو ایک ترتیب شدہ فہرست کی ضرورت ہے؟ فہرست کو آف چین ترتیب دیں، پھر اس کی ترتیب کو صرف آن چین چیک کریں۔ + +### اپ گریڈ ایبلٹی {#upgradeability} + +ہم نے [ہمارے بلاگ پوسٹ](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) میں مختلف اپ گریڈ ایبلٹی حل پر تبادلہ خیال کیا ہے۔ کوئی بھی کوڈ لکھنے سے پہلے اپ گریڈ ایبلٹی کو سپورٹ کرنے یا نہ کرنے کا دانستہ انتخاب کریں۔ یہ فیصلہ اس بات پر اثرانداز ہوگا کہ آپ اپنے کوڈ کی ساخت کیسے بناتے ہیں۔ عام طور پر، ہم تجویز کرتے ہیں: + +- **اپ گریڈ ایبلٹی پر [کنٹریکٹ مائیگریشن](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) کو ترجیح دینا۔** مائیگریشن سسٹم میں اپ گریڈ ایبل سسٹم جیسے بہت سے فوائد ہوتے ہیں، بغیر ان کی خامیوں کے۔ +- **delegatecallproxy کے بجائے ڈیٹا سیپریشن پیٹرن کا استعمال۔** اگر آپ کے پروجیکٹ میں واضح تجریدی علیحدگی ہے، تو ڈیٹا سیپریشن کا استعمال کرتے ہوئے اپ گریڈ ایبلٹی کے لیے صرف چند ایڈجسٹمنٹ کی ضرورت ہوگی۔ delegatecallproxy کے لیے EVM کی مہارت درکار ہے اور یہ بہت زیادہ غلطی کا شکار ہے۔ +- **تعیناتی سے پہلے مائیگریشن/اپ گریڈ کے طریقہ کار کو دستاویز کریں۔** اگر آپ کو بغیر کسی رہنما اصول کے دباؤ میں رد عمل ظاہر کرنا پڑا تو آپ غلطیاں کریں گے۔ پیروی کرنے کے لیے طریقہ کار پہلے سے لکھیں۔ اس میں شامل ہونا چاہیے: + - وہ کالز جو نئے کنٹریکٹس شروع کرتی ہیں + - چابیاں کہاں محفوظ ہیں اور ان تک کیسے رسائی حاصل کی جائے + - تعیناتی کو کیسے چیک کریں! ایک پوسٹ-ڈیپلائمنٹ اسکرپٹ تیار اور ٹیسٹ کریں۔ + +## نفاذ کے رہنما اصول {#implementation-guidelines} + +**سادگی کے لیے کوشش کریں۔** ہمیشہ سب سے آسان حل استعمال کریں جو آپ کے مقصد کے مطابق ہو۔ آپ کی ٹیم کا کوئی بھی رکن آپ کے حل کو سمجھنے کے قابل ہونا چاہیے۔ + +### فنکشن کمپوزیشن {#function-composition} + +آپ کے کوڈبیس کا فن تعمیر آپ کے کوڈ کا جائزہ لینا آسان بنانا چاہیے۔ ایسے آرکیٹیکچرل انتخاب سے گریز کریں جو اس کی درستگی کے بارے میں استدلال کرنے کی صلاحیت کو کم کرتے ہیں۔ + +- **اپنے سسٹم کی منطق کو تقسیم کریں**، یا تو متعدد کنٹریکٹس کے ذریعے یا اسی طرح کے فنکشنز کو ایک ساتھ گروپ کرکے (مثال کے طور پر، توثیق، ریاضی، ...)۔ +- **چھوٹے فنکشنز لکھیں، ایک واضح مقصد کے ساتھ۔** یہ آسان جائزہ لینے میں سہولت فراہم کرے گا اور انفرادی اجزاء کی جانچ کی اجازت دے گا۔ + +### وراثت {#inheritance} + +- **وراثت کو قابل انتظام رکھیں۔** وراثت کو منطق کو تقسیم کرنے کے لیے استعمال کیا جانا چاہیے، تاہم، آپ کے پروجیکٹ کا مقصد وراثت کے درخت کی گہرائی اور چوڑائی کو کم کرنا ہونا چاہیے۔ +- **کنٹریکٹس کے درجہ بندی کو چیک کرنے کے لیے Slither کے [وراثت پرنٹر](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) کا استعمال کریں۔** وراثت پرنٹر آپ کو درجہ بندی کے سائز کا جائزہ لینے میں مدد کرے گا۔ + +### ایونٹس {#events} + +- **تمام اہم کارروائیوں کو لاگ کریں۔** ایونٹس ڈیولپمنٹ کے دوران کنٹریکٹ کو ڈیبگ کرنے، اور تعیناتی کے بعد اس کی نگرانی کرنے میں مدد کریں گے۔ + +### معروف نقصانات سے بچیں {#avoid-known-pitfalls} + +- **سب سے عام سیکیورٹی مسائل سے آگاہ رہیں۔** عام مسائل کے بارے میں جاننے کے لیے بہت سے آن لائن وسائل موجود ہیں، جیسے کہ [Ethernaut CTF](https://ethernaut.openzeppelin.com/)، [Capture the Ether](https://capturetheether.com/)، یا [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/)۔ +- **[Solidity دستاویزات](https://docs.soliditylang.org/en/latest/) میں وارننگ سیکشنز سے آگاہ رہیں۔** وارننگ سیکشنز آپ کو زبان کے غیر واضح رویے کے بارے میں آگاہ کریں گے۔ + +### انحصار {#dependencies} + +- **اچھی طرح سے ٹیسٹ شدہ لائبریریوں کا استعمال کریں۔** اچھی طرح سے ٹیسٹ شدہ لائبریریوں سے کوڈ درآمد کرنا اس امکان کو کم کر دے گا کہ آپ بگ والا کوڈ لکھیں۔ اگر آپ ERC20 کنٹریکٹ لکھنا چاہتے ہیں، تو [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20) استعمال کریں۔ +- **ایک ڈیپنڈنسی مینیجر کا استعمال کریں؛ کوڈ کو کاپی پیسٹ کرنے سے گریز کریں۔** اگر آپ کسی بیرونی ماخذ پر انحصار کرتے ہیں، تو آپ کو اسے اصل ماخذ کے ساتھ اپ ٹو ڈیٹ رکھنا چاہیے۔ + +### جانچ اور تصدیق {#testing-and-verification} + +- **مکمل یونٹ ٹیسٹ لکھیں۔** اعلیٰ معیار کا سافٹ ویئر بنانے کے لیے ایک وسیع ٹیسٹ سویٹ بہت ضروری ہے۔ +- **[Slither](https://github.com/crytic/slither)، [Echidna](https://github.com/crytic/echidna) اور [Manticore](https://github.com/trailofbits/manticore) کسٹم چیکس اور پراپرٹیز لکھیں۔** خودکار ٹولز آپ کے کنٹریکٹ کو محفوظ بنانے میں مدد کریں گے۔ موثر چیکس اور پراپرٹیز لکھنے کا طریقہ جاننے کے لیے اس گائیڈ کے باقی حصے کا جائزہ لیں۔ +- **[crytic.io](https://crytic.io/) کا استعمال کریں۔** Crytic GitHub کے ساتھ مربوط ہوتا ہے، نجی Slither ڈیٹیکٹرز تک رسائی فراہم کرتا ہے، اور Echidna سے کسٹم پراپرٹی چیکس چلاتا ہے۔ + +### Solidity {#solidity} + +- **0.4 اور 0.6 پر Solidity 0.5 کو ترجیح دیں۔** ہماری رائے میں، Solidity 0.5 زیادہ محفوظ ہے اور 0.4 کے مقابلے میں بہتر بلٹ ان پریکٹسز رکھتا ہے۔ Solidity 0.6 پروڈکشن کے لیے بہت غیر مستحکم ثابت ہوا ہے اور اسے پختہ ہونے کے لیے وقت درکار ہے۔ +- **کمپائل کرنے کے لیے ایک مستحکم ریلیز کا استعمال کریں؛ وارننگز چیک کرنے کے لیے تازہ ترین ریلیز کا استعمال کریں۔** چیک کریں کہ آپ کے کوڈ میں تازہ ترین کمپائلر ورژن کے ساتھ کوئی رپورٹ شدہ مسئلہ نہیں ہے۔ تاہم، Solidity کا ایک تیز ریلیز سائیکل ہے اور اس میں کمپائلر بگز کی تاریخ ہے، اس لیے ہم تعیناتی کے لیے تازہ ترین ورژن کی سفارش نہیں کرتے ہیں (Slither کی [solc ورژن کی سفارش](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) دیکھیں)۔ +- **ان لائن اسمبلی کا استعمال نہ کریں۔** اسمبلی کے لیے EVM کی مہارت درکار ہے۔ EVM کوڈ نہ لکھیں اگر آپ نے یلو پیپر میں _مہارت_ حاصل نہیں کی ہے۔ + +## تعیناتی کے رہنما اصول {#deployment-guidelines} + +ایک بار جب کنٹریکٹ تیار اور تعینات ہو جائے: + +- **اپنے کنٹریکٹس کی نگرانی کریں۔** لاگز دیکھیں، اور کنٹریکٹ یا والیٹ کے سمجھوتے کی صورت میں رد عمل ظاہر کرنے کے لیے تیار رہیں۔ +- **اپنی رابطہ کی معلومات [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts) میں شامل کریں۔** یہ فہرست تیسرے فریق کو آپ سے رابطہ کرنے میں مدد کرتی ہے اگر کوئی سیکیورٹی خامی دریافت ہوتی ہے۔ +- **مراعات یافتہ صارفین کے والیٹس کو محفوظ بنائیں۔** اگر آپ ہارڈ ویئر والیٹس میں چابیاں محفوظ کرتے ہیں تو ہماری [بہترین طریقوں](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) پر عمل کریں۔ +- **واقعہ کے جواب کا منصوبہ بنائیں۔** غور کریں کہ آپ کے اسمارٹ کنٹریکٹس سے سمجھوتہ کیا جا سکتا ہے۔ یہاں تک کہ اگر آپ کے کنٹریکٹس بگ سے پاک ہیں، ایک حملہ آور کنٹریکٹ کے مالک کی چابیوں پر کنٹرول حاصل کر سکتا ہے۔ diff --git a/public/content/translations/ur/developers/tutorials/stealth-addr/index.md b/public/content/translations/ur/developers/tutorials/stealth-addr/index.md new file mode 100644 index 00000000000..5703588ab12 --- /dev/null +++ b/public/content/translations/ur/developers/tutorials/stealth-addr/index.md @@ -0,0 +1,436 @@ +--- +title: "خفیہ پتوں کا استعمال" +description: "خفیہ پتے صارفین کو گمنام طور پر اثاثوں کی منتقلی کی اجازت دیتے ہیں۔ اس مضمون کو پڑھنے کے بعد، آپ اس قابل ہو جائیں گے: یہ بتانے کے کہ خفیہ پتے کیا ہیں اور وہ کیسے کام کرتے ہیں، خفیہ پتوں کو اس طرح استعمال کرنے کا طریقہ سمجھنے کے جو گمنامی کو برقرار رکھتا ہے، اور ایک ویب پر مبنی ایپلیکیشن لکھنے کے جو خفیہ پتوں کا استعمال کرتی ہے۔" +author: Ori Pomerantz +tags: [ "خفیہ پتہ", "رازداری", "کریپٹوگرافی", "rust", "wasm" ] +skill: intermediate +published: 2025-11-30 +lang: ur-in +sidebarDepth: 3 +--- + +آپ بل ہیں۔ ان وجوہات کی بنا پر جن میں ہم نہیں جائیں گے، آپ "دنیا کی ملکہ کے لیے ایلس" مہم کو عطیہ دینا چاہتے ہیں اور ایلس کو یہ معلوم کرانا چاہتے ہیں کہ آپ نے عطیہ دیا ہے تاکہ اگر وہ جیت جائے تو وہ آپ کو انعام دے۔ بدقسمتی سے، اس کی جیت کی ضمانت نہیں ہے۔ ایک مسابقتی مہم ہے، "کیرول نظام شمسی کی مہارانی کے لیے"۔ اگر کیرول جیت جاتی ہے، اور اسے پتہ چل جاتا ہے کہ آپ نے ایلس کو عطیہ دیا ہے، تو آپ مشکل میں پڑ جائیں گے۔ لہذا آپ صرف اپنے اکاؤنٹ سے ایلس کے اکاؤنٹ میں 200 ETH منتقل نہیں کر سکتے۔ + +[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) کے پاس اس کا حل ہے۔ یہ ERC گمنام منتقلی کے لیے [خفیہ پتوں](https://nerolation.github.io/stealth-utils) کا استعمال کرنے کا طریقہ بتاتا ہے۔ + +**انتباہ**: خفیہ پتوں کے پیچھے کی کریپٹوگرافی، جہاں تک ہم جانتے ہیں، درست ہے۔ تاہم، ممکنہ سائیڈ چینل حملے ہو سکتے ہیں۔ [نیچے](#go-wrong)، آپ دیکھیں گے کہ آپ اس خطرے کو کم کرنے کے لیے کیا کر سکتے ہیں۔ + +## خفیہ پتے کیسے کام کرتے ہیں {#how} + +یہ مضمون دو طریقوں سے خفیہ پتوں کی وضاحت کرنے کی کوشش کرے گا۔ پہلا یہ ہے کہ [ان کا استعمال کیسے کریں](#how-use)۔ یہ حصہ مضمون کے باقی حصے کو سمجھنے کے لیے کافی ہے۔ پھر، [اس کے پیچھے ریاضی کی وضاحت](#how-math) ہے۔ اگر آپ کریپٹوگرافی میں دلچسپی رکھتے ہیں، تو یہ حصہ بھی پڑھیں۔ + +### سادہ ورژن (خفیہ پتوں کا استعمال کیسے کریں) {#how-use} + +ایلس دو پرائیویٹ کیز بناتی ہے اور متعلقہ پبلک کیز شائع کرتی ہے (جنہیں ایک ہی ڈبل لینتھ میٹا ایڈریس میں ملایا جا سکتا ہے)۔ بل بھی ایک پرائیویٹ کی بناتا ہے اور متعلقہ پبلک کی شائع کرتا ہے۔ + +ایک پارٹی کی پبلک کی اور دوسری کی پرائیویٹ کی کا استعمال کرتے ہوئے، آپ ایک مشترکہ راز حاصل کر سکتے ہیں جو صرف ایلس اور بل کو معلوم ہے (اسے صرف پبلک کیز سے حاصل نہیں کیا جا سکتا)۔ اس مشترکہ راز کا استعمال کرتے ہوئے، بل خفیہ پتہ حاصل کرتا ہے اور اس پر اثاثے بھیج سکتا ہے۔ + +ایلس کو بھی مشترکہ راز سے پتہ ملتا ہے، لیکن چونکہ وہ اپنی شائع کردہ پبلک کیز کی پرائیویٹ کیز جانتی ہے، اس لیے وہ وہ پرائیویٹ کی بھی حاصل کر سکتی ہے جو اسے اس پتے سے رقم نکالنے دیتی ہے۔ + +### ریاضی (خفیہ پتے اس طرح کیوں کام کرتے ہیں) {#how-math} + +معیاری خفیہ پتے کم کی بٹس کے ساتھ بہتر کارکردگی حاصل کرنے کے لیے [الیپٹک کرو کریپٹوگرافی (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor) کا استعمال کرتے ہیں، جبکہ سیکیورٹی کی سطح وہی رہتی ہے۔ لیکن زیادہ تر ہم اسے نظر انداز کر سکتے ہیں اور یہ دکھاوا کر سکتے ہیں کہ ہم باقاعدہ ریاضی کا استعمال کر رہے ہیں۔ + +ایک نمبر ہے جسے ہر کوئی جانتا ہے، _G_۔ آپ _G_ سے ضرب دے سکتے ہیں۔ لیکن ECC کی نوعیت کی وجہ سے، _G_ سے تقسیم کرنا عملی طور پر ناممکن ہے۔ Ethereum میں پبلک کی کریپٹوگرافی عام طور پر جس طرح کام کرتی ہے وہ یہ ہے کہ آپ ایک پرائیویٹ کی، _Ppriv_، کا استعمال لین دین پر دستخط کرنے کے لیے کر سکتے ہیں جن کی تصدیق پھر ایک پبلک کی، _Ppub = GPpriv_ سے ہوتی ہے۔ + +ایلس دو پرائیویٹ کیز بناتی ہے، _Kpriv_ اور _Vpriv_۔ _Kpriv_ کا استعمال خفیہ پتے سے رقم خرچ کرنے کے لیے کیا جائے گا، اور _Vpriv_ کا استعمال ایلس سے تعلق رکھنے والے پتوں کو دیکھنے کے لیے کیا جائے گا۔ ایلس پھر پبلک کیز شائع کرتی ہے: _Kpub = GKpriv_ اور _Vpub = GVpriv_ + +بل ایک تیسری پرائیویٹ کی، _Rpriv_ بناتا ہے، اور _Rpub = GRpriv_ کو ایک مرکزی رجسٹری میں شائع کرتا ہے (بل اسے ایلس کو بھی بھیج سکتا تھا، لیکن ہم فرض کرتے ہیں کہ کیرول سن رہی ہے)۔ + +بل _RprivVpub = GRprivVpriv_ کا حساب لگاتا ہے، جس کی وہ توقع کرتا ہے کہ ایلس بھی جانتی ہے (نیچے وضاحت کی گئی ہے)۔ اس قدر کو _S_، یعنی مشترکہ راز کہا جاتا ہے۔ یہ بل کو ایک پبلک کی دیتا ہے، _Ppub = Kpub+G\*hash(S)_۔ اس پبلک کی سے، وہ ایک پتہ کا حساب لگا سکتا ہے اور جو بھی وسائل وہ چاہے اسے بھیج سکتا ہے۔ مستقبل میں، اگر ایلس جیت جاتی ہے، تو بل اسے _Rpriv_ بتا سکتا ہے تاکہ یہ ثابت ہو سکے کہ وسائل اسی کی طرف سے آئے ہیں۔ + +ایلس _RpubVpriv = GRprivVpriv_ کا حساب لگاتی ہے۔ یہ اسے وہی مشترکہ راز، _S_ دیتا ہے۔ چونکہ وہ پرائیویٹ کی، _Kpriv_ جانتی ہے، وہ _Ppriv = Kpriv+hash(S)_ کا حساب لگا سکتی ہے۔ یہ کی اسے اس پتے میں موجود اثاثوں تک رسائی دیتی ہے جو _Ppub = GPpriv = GKpriv+G\*hash(S) = Kpub+G\*hash(S)_ سے حاصل ہوتا ہے۔ + +ہمارے پاس ایک علیحدہ ویونگ کی ہے تاکہ ایلس ڈیو کی ورلڈ ڈومینیشن کمپین سروسز کو سب کنٹریکٹ دے سکے۔ ایلس ڈیو کو عوامی پتے بتانے اور جب مزید رقم دستیاب ہو تو اسے مطلع کرنے کے لیے تیار ہے، لیکن وہ نہیں چاہتی کہ وہ اس کی مہم کی رقم خرچ کرے۔ + +چونکہ دیکھنے اور خرچ کرنے کے لیے علیحدہ کیز کا استعمال ہوتا ہے، ایلس ڈیو کو _Vpriv_ دے سکتی ہے۔ پھر ڈیو _S = RpubVpriv = GRprivVpriv_ کا حساب لگا سکتا ہے اور اس طرح پبلک کیز (_Ppub = Kpub+G\*hash(S)_) حاصل کر سکتا ہے۔ لیکن _Kpriv_ کے بغیر ڈیو پرائیویٹ کی حاصل نہیں کر سکتا۔ + +خلاصہ یہ کہ، یہ وہ اقدار ہیں جو مختلف شرکاء کو معلوم ہیں۔ + +| ایلس | شائع شدہ | بل | ڈیو | | +| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------- | +| G | G | G | G | | +| _Kpriv_ | ۔ | ۔ | ۔ | | +| _Vpriv_ | ۔ | ۔ | _Vpriv_ | | +| _Kpub = GKpriv_ | _Kpub_ | _Kpub_ | _Kpub_ | | +| _Vpub = GVpriv_ | _Vpub_ | _Vpub_ | _Vpub_ | | +| ۔ | ۔ | _Rpriv_ | ۔ | | +| _Rpub_ | _Rpub_ | _Rpub = GRpriv_ | _Rpub_ | | +| _S = RpubVpriv = GRprivVpriv_ | ۔ | _S = RprivVpub = GRprivVpriv_ | _S = _RpubVpriv_ = GRprivVpriv_ | | +| _Ppub = Kpub+G\*hash(S)_ | ۔ | _Ppub = Kpub+G\*hash(S)_ | _Ppub = Kpub+G\*hash(S)_ | | +| _پتہ=f(Ppub)_ | ۔ | _پتہ=f(Ppub)_ | _پتہ=f(Ppub)_ | _پتہ=f(Ppub)_ | +| _Ppriv = Kpriv+hash(S)_ | ۔ | ۔ | ۔ | | + +## جب خفیہ پتے غلط ہو جاتے ہیں {#go-wrong} + +_بلاک چین پر کوئی راز نہیں ہوتے_۔ جبکہ خفیہ پتے آپ کو رازداری فراہم کر سکتے ہیں، لیکن وہ رازداری ٹریفک کے تجزیے کے لیے حساس ہے۔ ایک معمولی مثال کے طور پر، تصور کریں کہ بل ایک پتے کو فنڈ کرتا ہے اور فوری طور پر _Rpub_ قدر شائع کرنے کے لیے ایک لین دین بھیجتا ہے۔ ایلس کی _Vpriv_ کے بغیر، ہم یقینی طور پر نہیں کہہ سکتے کہ یہ ایک خفیہ پتہ ہے، لیکن شرط لگانے کا یہی طریقہ ہے۔ پھر، ہم ایک اور لین دین دیکھتے ہیں جو اس پتے سے تمام ETH کو ایلس کے مہم کے فنڈ کے پتے پر منتقل کرتا ہے۔ ہم شاید اسے ثابت نہ کر سکیں، لیکن امکان ہے کہ بل نے ابھی ایلس کی مہم کو عطیہ دیا ہے۔ کیرول یقینی طور پر ایسا ہی سوچے گی۔ + +بل کے لیے _Rpub_ کی اشاعت کو خفیہ پتے کی فنڈنگ سے الگ کرنا آسان ہے (انہیں مختلف اوقات میں، مختلف پتوں سے کریں)۔ تاہم، یہ ناکافی ہے۔ کیرول جس پیٹرن کو تلاش کرتی ہے وہ یہ ہے کہ بل ایک پتے کو فنڈ کرتا ہے، اور پھر ایلس کا مہم فنڈ اس سے رقم نکالتا ہے۔ + +ایک حل یہ ہے کہ ایلس کی مہم براہ راست رقم نہ نکالے، بلکہ اسے کسی تیسرے فریق کو ادائیگی کے لیے استعمال کرے۔ اگر ایلس کی مہم ڈیو کی ورلڈ ڈومینیشن کمپین سروسز کو 10 ETH بھیجتی ہے، تو کیرول کو صرف یہ معلوم ہوتا ہے کہ بل نے ڈیو کے صارفین میں سے کسی ایک کو عطیہ دیا ہے۔ اگر ڈیو کے پاس کافی گاہک ہیں، تو کیرول یہ نہیں جان پائے گی کہ بل نے ایلس کو عطیہ دیا جو اس سے مقابلہ کرتی ہے، یا ایڈم، البرٹ، یا ابیگیل کو جن کی کیرول کو پرواہ نہیں ہے۔ ایلس ادائیگی کے ساتھ ایک ہیش شدہ قدر شامل کر سکتی ہے، اور پھر ڈیو کو پری امیج فراہم کر سکتی ہے، تاکہ یہ ثابت ہو سکے کہ یہ اس کا عطیہ تھا۔ متبادل کے طور پر، جیسا کہ اوپر بتایا گیا ہے، اگر ایلس ڈیو کو اپنی _Vpriv_ دیتی ہے، تو وہ پہلے ہی جانتا ہے کہ ادائیگی کس کی طرف سے آئی ہے۔ + +اس حل کے ساتھ بنیادی مسئلہ یہ ہے کہ اس میں ایلس کو رازداری کا خیال رکھنے کی ضرورت ہوتی ہے جبکہ اس رازداری سے بل کو فائدہ ہوتا ہے۔ ایلس اپنی ساکھ برقرار رکھنا چاہ سکتی ہے تاکہ بل کا دوست باب بھی اسے عطیہ دے۔ لیکن یہ بھی ممکن ہے کہ اسے بل کو بے نقاب کرنے میں کوئی اعتراض نہ ہو، کیونکہ پھر اسے ڈر ہوگا کہ اگر کیرول جیت گئی تو کیا ہوگا۔ بل شاید ایلس کو اور بھی زیادہ مدد فراہم کرے۔ + +### متعدد خفیہ پرتوں کا استعمال {#multi-layer} + +بل کی رازداری کو برقرار رکھنے کے لیے ایلس پر انحصار کرنے کے بجائے، بل خود یہ کر سکتا ہے۔ وہ فرضی لوگوں، باب اور بیلا کے لیے متعدد میٹا پتے بنا سکتا ہے۔ بل پھر باب کو ETH بھیجتا ہے، اور "باب" (جو دراصل بل ہے) اسے بیلا کو بھیجتا ہے۔ "بیلا" (جو بھی بل ہے) اسے ایلس کو بھیجتی ہے۔ + +کیرول اب بھی ٹریفک کا تجزیہ کر سکتی ہے اور بل-ٹو-باب-ٹو-بیلا-ٹو-ایلس پائپ لائن دیکھ سکتی ہے۔ تاہم، اگر "باب" اور "بیلا" بھی دیگر مقاصد کے لیے ETH کا استعمال کرتے ہیں، تو یہ ظاہر نہیں ہوگا کہ بل نے ایلس کو کچھ بھی منتقل کیا ہے، چاہے ایلس فوری طور پر خفیہ پتے سے اپنے معلوم مہم کے پتے پر رقم نکال لے۔ + +## خفیہ پتے والی ایپلیکیشن لکھنا {#write-app} + +یہ مضمون GitHub پر دستیاب ایک [خفیہ پتے والی ایپلیکیشن](https://github.com/qbzzt/251022-stealth-addresses.git) کی وضاحت کرتا ہے۔ + +### ٹولز {#tools} + +ایک [ٹائپ اسکرپٹ خفیہ پتہ لائبریری](https://github.com/ScopeLift/stealth-address-sdk) ہے جسے ہم استعمال کر سکتے ہیں۔ تاہم، کریپٹوگرافک آپریشنز CPU-انٹینسیو ہو سکتے ہیں۔ میں انہیں ایک کمپائلڈ زبان، جیسے [Rust](https://rust-lang.org/) میں نافذ کرنے کو ترجیح دیتا ہوں، اور براؤزر میں کوڈ چلانے کے لیے [WASM](https://webassembly.org/) کا استعمال کرتا ہوں۔ + +ہم [Vite](https://vite.dev/) اور [React](https://react.dev/) کا استعمال کرنے جا رہے ہیں۔ یہ انڈسٹری کے معیاری ٹولز ہیں؛ اگر آپ ان سے واقف نہیں ہیں، تو آپ [یہ ٹیوٹوریل](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) استعمال کر سکتے ہیں۔ Vite استعمال کرنے کے لیے، ہمیں Node کی ضرورت ہے۔ + +### خفیہ پتوں کو عمل میں دیکھیں {#in-action} + +1. ضروری ٹولز انسٹال کریں: [Rust](https://rust-lang.org/tools/install/) اور [Node](https://nodejs.org/en/download)۔ + +2. GitHub ریپوزٹری کو کلون کریں۔ + + ```sh + git clone https://github.com/qbzzt/251022-stealth-addresses.git + cd 251022-stealth-addresses + ``` + +3. پیشگی شرائط انسٹال کریں اور Rust کوڈ کو کمپائل کریں۔ + + ```sh + cd src/rust-wasm + rustup target add wasm32-unknown-unknown + cargo install wasm-pack + wasm-pack build --target web + ``` + +4. ویب سرور شروع کریں۔ + + ```sh + cd ../.. + npm install + npm run dev + ``` + +5. [ایپلیکیشن](http://localhost:5173/) پر براؤز کریں۔ اس ایپلیکیشن پیج میں دو فریم ہیں: ایک ایلس کے یوزر انٹرفیس کے لیے اور دوسرا بل کے لیے۔ دونوں فریم آپس میں بات چیت نہیں کرتے؛ وہ صرف سہولت کے لیے ایک ہی صفحے پر ہیں۔ + +6. ایلس کے طور پر، **ایک خفیہ میٹا ایڈریس بنائیں** پر کلک کریں۔ یہ نیا خفیہ پتہ اور متعلقہ پرائیویٹ کیز دکھائے گا۔ خفیہ میٹا ایڈریس کو کلپ بورڈ پر کاپی کریں۔ + +7. بل کے طور پر، نیا خفیہ میٹا ایڈریس پیسٹ کریں اور **ایک پتہ بنائیں** پر کلک کریں۔ یہ آپ کو ایلس کے لیے فنڈ کرنے کا پتہ دیتا ہے۔ + +8. پتہ اور بل کی پبلک کی کاپی کریں اور انہیں ایلس کے یوزر انٹرفیس کے "بل کے ذریعے بنائے گئے پتے کے لیے پرائیویٹ کی" والے حصے میں پیسٹ کریں۔ ایک بار جب وہ فیلڈز بھر جائیں گے، تو آپ اس پتے پر اثاثوں تک رسائی کے لیے پرائیویٹ کی دیکھیں گے۔ + +9. آپ [ایک آن لائن کیلکولیٹر](https://iancoleman.net/ethereum-private-key-to-address/) کا استعمال کر سکتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ پرائیویٹ کی پتے سے مطابقت رکھتی ہے۔ + +### پروگرام کیسے کام کرتا ہے {#how-the-program-works} + +#### WASM جزو {#wasm} + +وہ سورس کوڈ جو WASM میں کمپائل ہوتا ہے [Rust](https://rust-lang.org/) میں لکھا گیا ہے۔ آپ اسے [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs) میں دیکھ سکتے ہیں۔ یہ کوڈ بنیادی طور پر جاوا اسکرپٹ کوڈ اور [`eth-stealth-addresses` لائبریری](https://github.com/kassandraoftroy/eth-stealth-addresses) کے درمیان ایک انٹرفیس ہے۔ + +**`Cargo.toml`** + +Rust میں [`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) جاوا اسکرپٹ میں [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) کے مترادف ہے۔ اس میں پیکیج کی معلومات، انحصاری اعلانات وغیرہ شامل ہیں۔ + +```toml +[package] +name = "rust-wasm" +version = "0.1.0" +edition = "2024" + +[dependencies] +eth-stealth-addresses = "0.1.0" +hex = "0.4.3" +wasm-bindgen = "0.2.104" +getrandom = { version = "0.2", features = ["js"] } +``` + +[`getrandom`](https://docs.rs/getrandom/latest/getrandom/) پیکیج کو بے ترتیب اقدار پیدا کرنے کی ضرورت ہے۔ یہ خالص الگورتھمک طریقوں سے نہیں کیا جا سکتا؛ اسے اینٹروپی کے منبع کے طور پر ایک طبعی عمل تک رسائی کی ضرورت ہوتی ہے۔ یہ تعریف بتاتی ہے کہ ہم اس اینٹروپی کو اس براؤزر سے پوچھ کر حاصل کریں گے جس میں ہم چل رہے ہیں۔ + +```toml +console_error_panic_hook = "0.1.7" +``` + +[یہ لائبریری](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) ہمیں مزید معنی خیز غلطی کے پیغامات دیتی ہے جب WASM کوڈ پینک کرتا ہے اور جاری نہیں رہ سکتا۔ + +```toml +[lib] +crate-type = ["cdylib", "rlib"] +``` + +WASM کوڈ تیار کرنے کے لیے درکار آؤٹ پٹ قسم۔ + +**`lib.rs`** + +یہ اصل Rust کوڈ ہے۔ + +```rust +use wasm_bindgen::prelude::*; +``` + +Rust سے WASM پیکیج بنانے کی تعریفیں۔ وہ [یہاں](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html) دستاویزی ہیں۔ + +```rust +use eth_stealth_addresses::{ + generate_stealth_meta_address, + generate_stealth_address, + compute_stealth_key +}; +``` + +وہ فنکشنز جن کی ہمیں [`eth-stealth-addresses` لائبریری](https://github.com/kassandraoftroy/eth-stealth-addresses) سے ضرورت ہے۔ + +```rust +use hex::{decode,encode}; +``` + +Rust عام طور پر اقدار کے لیے بائٹ [ایریز](https://doc.rust-lang.org/std/primitive.array.html) (`[u8; ]`) کا استعمال کرتا ہے۔ لیکن جاوا اسکرپٹ میں، ہم عام طور پر ہیکسا ڈیسیمل اسٹرنگز کا استعمال کرتے ہیں۔ [`ہیکس` لائبریری](https://docs.rs/hex/latest/hex/) ہمارے لیے ایک نمائندگی سے دوسری میں ترجمہ کرتی ہے۔ + +```rust +#[wasm_bindgen] +``` + +جاوا اسکرپٹ سے اس فنکشن کو کال کرنے کے قابل ہونے کے لیے WASM بائنڈنگز بنائیں۔ + +```rust +pub fn wasm_generate_stealth_meta_address() -> String { +``` + +متعدد فیلڈز والے آبجیکٹ کو واپس کرنے کا سب سے آسان طریقہ JSON اسٹرنگ واپس کرنا ہے۔ + +```rust + let (address, spend_private_key, view_private_key) = + generate_stealth_meta_address(); +``` + +[`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) تین فیلڈز واپس کرتا ہے: + +- میٹا ایڈریس (_Kpub_ اور _Vpub_) +- ویونگ پرائیویٹ کی (_Vpriv_) +- اسپینڈنگ پرائیویٹ کی (_Kpriv_) + +[ٹیوپل](https://doc.rust-lang.org/std/primitive.tuple.html) سنٹیکس ہمیں ان اقدار کو دوبارہ الگ کرنے دیتا ہے۔ + +```rust + format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}", + encode(address), + encode(view_private_key), + encode(spend_private_key) + ) +} +``` + +JSON-انکوڈڈ اسٹرنگ بنانے کے لیے [`format!`](https://doc.rust-lang.org/std/fmt/index.html) میکرو کا استعمال کریں۔ ایریز کو ہیکس اسٹرنگز میں تبدیل کرنے کے لیے [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html) کا استعمال کریں۔ + +```rust +fn str_to_array(s: &str) -> Option<[u8; N]> { +``` + +یہ فنکشن ایک ہیکس اسٹرنگ (جو جاوا اسکرپٹ کے ذریعے فراہم کی گئی ہے) کو بائٹ ایرے میں بدل دیتا ہے۔ ہم اسے جاوا اسکرپٹ کوڈ کے ذریعے فراہم کردہ اقدار کو پارس کرنے کے لیے استعمال کرتے ہیں۔ یہ فنکشن اس لیے پیچیدہ ہے کہ Rust ایریز اور ویکٹرز کو کیسے ہینڈل کرتا ہے۔ + +`` ایکسپریشن کو [جینرک](https://doc.rust-lang.org/book/ch10-01-syntax.html) کہا جاتا ہے۔ `N` ایک پیرامیٹر ہے جو واپس آنے والی ایرے کی لمبائی کو کنٹرول کرتا ہے۔ فنکشن کو دراصل `str_to_array::` کہا جاتا ہے، جہاں `n` ایرے کی لمبائی ہے۔ + +واپسی کی قدر `Option<[u8; N]>` ہے، جس کا مطلب ہے کہ واپس آنے والی ایرے [اختیاری](https://doc.rust-lang.org/std/option/) ہے۔ یہ Rust میں ان فنکشنز کے لیے ایک عام پیٹرن ہے جو ناکام ہو سکتے ہیں۔ + +مثال کے طور پر، اگر ہم `str_to_array::10("bad060a7")` کو کال کرتے ہیں، تو فنکشن کو دس-ویلیو ایرے واپس کرنا چاہیے، لیکن ان پٹ صرف چار بائٹس ہے۔ فنکشن کو ناکام ہونے کی ضرورت ہے، اور یہ `None` واپس کرکے ایسا کرتا ہے۔ `str_to_array::4("bad060a7")` کے لیے واپسی کی قدر `Some<[0xba, 0xd0, 0x60, 0xa7]>` ہوگی۔ + +```rust + // decode returns Result, _> + let vec = decode(s).ok()?; +``` + +[`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) فنکشن `Result, FromHexError>` واپس کرتا ہے۔ [`Result`](https://doc.rust-lang.org/std/result/) قسم میں یا تو ایک کامیاب نتیجہ (`Ok(value)`) یا ایک خرابی (`Err(error)`) ہو سکتی ہے۔ + +.ok()`طریقہ`Result`کو ایک`Option`میں بدل دیتا ہے، جس کی قدر یا تو کامیاب ہونے پر`Ok()`کی قدر ہوتی ہے یا`None`اگر نہیں۔ آخر میں، [سوالیہ نشان آپریٹر](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) موجودہ فنکشنز کو ختم کر دیتا ہے اور اگر`Option`خالی ہو تو`None`واپس کرتا ہے۔ بصورت دیگر، یہ قدر کو ان ریپ کرتا ہے اور اسے واپس کرتا ہے (اس صورت میں،`vec` کو ایک قدر تفویض کرنے کے لیے)۔ + +یہ غلطیوں کو سنبھالنے کا ایک عجیب و غریب طریقہ لگتا ہے، لیکن `Result` اور `Option` اس بات کو یقینی بناتے ہیں کہ تمام غلطیوں کو کسی نہ کسی طریقے سے سنبھالا جائے۔ + +```rust + if vec.len() != N { return None; } +``` + +اگر بائٹس کی تعداد غلط ہے، تو یہ ایک ناکامی ہے، اور ہم `None` واپس کرتے ہیں۔ + +```rust + // try_into consumes vec and attempts to make [u8; N] + let array: [u8; N] = vec.try_into().ok()?; +``` + +Rust میں دو ایرے کی قسمیں ہیں۔ [ایریز](https://doc.rust-lang.org/std/primitive.array.html) کا ایک مقررہ سائز ہوتا ہے۔ [ویکٹرز](https://doc.rust-lang.org/std/vec/index.html) بڑھ اور سکڑ سکتے ہیں۔ `hex::decode` ایک ویکٹر واپس کرتا ہے، لیکن `eth_stealth_addresses` لائبریری ایریز وصول کرنا چاہتی ہے۔ [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) ایک قدر کو دوسری قسم میں تبدیل کرتا ہے، مثال کے طور پر، ایک ویکٹر کو ایک ایرے میں۔ + +```rust + Some(array) +} +``` + +Rust کو فنکشن کے آخر میں قدر واپس کرتے وقت [`return`](https://doc.rust-lang.org/std/keyword.return.html) کلیدی لفظ استعمال کرنے کی ضرورت نہیں ہوتی۔ + +```rust +#[wasm_bindgen] +pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option { +``` + +یہ فنکشن ایک پبلک میٹا ایڈریس وصول کرتا ہے، جس میں _Vpub_ اور _Kpub_ دونوں شامل ہیں۔ یہ خفیہ پتہ، شائع کرنے کے لیے پبلک کی (_Rpub_)، اور ایک بائٹ کی اسکین ویلیو واپس کرتا ہے جو اس شناخت کو تیز کرتی ہے کہ کون سے شائع شدہ پتے ایلس سے تعلق رکھتے ہیں۔ + +اسکین ویلیو مشترکہ راز (_S = GRprivVpriv_) کا حصہ ہے۔ یہ قدر ایلس کو دستیاب ہے، اور اسے چیک کرنا اس بات کی جانچ سے بہت تیز ہے کہ آیا _f(Kpub+G\*hash(S))_ شائع شدہ پتے کے برابر ہے۔ + +```rust + let (address, r_pub, scan) = + generate_stealth_address(&str_to_array::<66>(stealth_address)?); +``` + +ہم لائبریری کے [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html) کا استعمال کرتے ہیں۔ + +```rust + format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}", + encode(address), + encode(r_pub), + encode(&[scan]) + ).into() +} +``` + +JSON-انکوڈڈ آؤٹ پٹ اسٹرنگ تیار کریں۔ + +```rust +#[wasm_bindgen] +pub fn wasm_compute_stealth_key( + address: &str, + bill_pub_key: &str, + view_private_key: &str, + spend_private_key: &str +) -> Option { + . + . + . +} +``` + +یہ فنکشن لائبریری کے [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) کا استعمال کرتا ہے تاکہ پتے (_Rpriv_) سے رقم نکالنے کے لیے پرائیویٹ کی کا حساب لگایا جا سکے۔ اس حساب کے لیے ان اقدار کی ضرورت ہے: + +- پتہ (_Address=f(Ppub)_) +- بل کے ذریعے بنائی گئی پبلک کی (_Rpub_) +- ویو پرائیویٹ کی (_Vpriv_) +- اسپینڈ پرائیویٹ کی (_Kpriv_) + +```rust +#[wasm_bindgen(start)] +``` + +[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) بتاتا ہے کہ فنکشن اس وقت عمل میں لایا جاتا ہے جب WASM کوڈ شروع ہوتا ہے۔ + +```rust +pub fn main() { + console_error_panic_hook::set_once(); +} +``` + +یہ کوڈ بتاتا ہے کہ پینک آؤٹ پٹ کو جاوا اسکرپٹ کنسول پر بھیجا جائے۔ اسے عمل میں دیکھنے کے لیے، ایپلیکیشن کا استعمال کریں اور بل کو ایک غلط میٹا ایڈریس دیں (صرف ایک ہیکسا ڈیسیمل ہندسہ تبدیل کریں)۔ آپ کو جاوا اسکرپٹ کنسول میں یہ خرابی نظر آئے گی: + +``` +rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9: +assertion `left == right` failed + left: 0 + right: 1 +``` + +اس کے بعد ایک اسٹیک ٹریس ہوتا ہے۔ پھر بل کو درست میٹا ایڈریس دیں، اور ایلس کو یا تو غلط پتہ یا غلط پبلک کی دیں۔ آپ کو یہ خرابی نظر آئے گی: + +``` +rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9: +keys do not generate stealth address +``` + +دوبارہ، اس کے بعد ایک اسٹیک ٹریس ہوتا ہے۔ + +#### یوزر انٹرفیس {#ui} + +یوزر انٹرفیس [React](https://react.dev/) کا استعمال کرتے ہوئے لکھا گیا ہے اور [Vite](https://vite.dev/) کے ذریعے پیش کیا جاتا ہے۔ آپ [اس ٹیوٹوریل](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) کا استعمال کرتے ہوئے ان کے بارے میں جان سکتے ہیں۔ یہاں [WAGMI](https://wagmi.sh/) کی کوئی ضرورت نہیں ہے کیونکہ ہم براہ راست بلاک چین یا والیٹ کے ساتھ تعامل نہیں کرتے ہیں۔ + +یوزر انٹرفیس کا واحد غیر واضح حصہ WASM کنیکٹیویٹی ہے۔ یہ اس طرح کام کرتا ہے۔ + +**`vite.config.js`** + +اس فائل میں [Vite کنفیگریشن](https://vite.dev/config/) شامل ہے۔ + +```js +import { defineConfig } from 'vite' +import react from '@vitejs/plugin-react' +import wasm from "vite-plugin-wasm"; + +// https://vite.dev/config/ +export default defineConfig({ + plugins: [react(), wasm()], +}) +``` + +ہمیں دو Vite پلگ انز کی ضرورت ہے: [react](https://www.npmjs.com/package/@vitejs/plugin-react) اور [wasm](https://github.com/Menci/vite-plugin-wasm#readme)۔ + +**`App.jsx`** + +یہ فائل ایپلیکیشن کا مرکزی جزو ہے۔ یہ ایک کنٹینر ہے جس میں دو اجزاء شامل ہیں: `Alice` اور `Bill`، ان صارفین کے لیے یوزر انٹرفیس۔ WASM کے لیے متعلقہ حصہ انیشیلائزیشن کوڈ ہے۔ + +```jsx +import init from './rust-wasm/pkg/rust_wasm.js' +``` + +جب ہم [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/) استعمال کرتے ہیں، تو یہ دو فائلیں بناتا ہے جنہیں ہم یہاں استعمال کرتے ہیں: اصل کوڈ کے ساتھ ایک wasm فائل (یہاں، `src/rust-wasm/pkg/rust_wasm_bg.wasm`) اور اسے استعمال کرنے کی تعریفوں کے ساتھ ایک جاوا اسکرپٹ فائل (یہاں، `src/rust_wasm/pkg/rust_wasm.js`)۔ اس جاوا اسکرپٹ فائل کا ڈیفالٹ ایکسپورٹ وہ کوڈ ہے جسے WASM شروع کرنے کے لیے چلانے کی ضرورت ہے۔ + +```jsx +function App() { + . + . + . + useEffect(() => { + const loadWasm = async () => { + try { + await init(); + setWasmReady(true) + } catch (err) { + console.error('Wasm لوڈ کرنے میں خرابی:', err) + alert("Wasm خرابی: " + err) + } + } + + loadWasm() + }, [] + ) +``` + +[`useEffect` ہک](https://react.dev/reference/react/useEffect) آپ کو ایک فنکشن کی وضاحت کرنے دیتا ہے جو اس وقت عمل میں لایا جاتا ہے جب اسٹیٹ متغیرات تبدیل ہوتے ہیں۔ یہاں، اسٹیٹ متغیرات کی فہرست خالی ہے (`[]`)، لہذا یہ فنکشن صرف ایک بار عمل میں لایا جاتا ہے جب صفحہ لوڈ ہوتا ہے۔ + +اثر فنکشن کو فوری طور پر واپس آنا ہوتا ہے۔ غیر مطابقت پذیر کوڈ، جیسے WASM `init` (جسے `.wasm` فائل لوڈ کرنا پڑتا ہے اور اس لیے وقت لگتا ہے) استعمال کرنے کے لیے ہم ایک اندرونی [`async`](https://en.wikipedia.org/wiki/Async/await) فنکشن کی وضاحت کرتے ہیں اور اسے `await` کے بغیر چلاتے ہیں۔ + +**`Bill.jsx`** + +یہ بل کے لیے یوزر انٹرفیس ہے۔ اس کا ایک ہی عمل ہے، ایلس کے ذریعے فراہم کردہ خفیہ میٹا ایڈریس کی بنیاد پر ایک پتہ بنانا۔ + +```jsx +import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js' +``` + +ڈیفالٹ ایکسپورٹ کے علاوہ، `wasm-pack` کے ذریعے تیار کردہ جاوا اسکرپٹ کوڈ WASM کوڈ میں ہر فنکشن کے لیے ایک فنکشن ایکسپورٹ کرتا ہے۔ + +```jsx +