---
title: "سمارٹ کنٹریکٹس کی تصدیق"
description: "ایتھیریم سمارٹ کنٹریکٹس کے لیے سورس کوڈ کی تصدیق کا جائزہ"
lang: ur
---

[سمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) کو "بلا اعتماد" (trustless) ہونے کے لیے ڈیزائن کیا گیا ہے، جس کا مطلب ہے کہ صارفین کو کسی کنٹریکٹ کے ساتھ تعامل کرنے سے پہلے تیسرے فریق (جیسے ڈیولپرز اور کمپنیوں) پر اعتماد کرنے کی ضرورت نہیں ہونی چاہیے۔ اعتماد سے آزادی کے تقاضے کے طور پر، صارفین اور دیگر ڈیولپرز کو سمارٹ کنٹریکٹ کے سورس کوڈ کی تصدیق کرنے کے قابل ہونا چاہیے۔ سورس کوڈ کی تصدیق صارفین اور ڈیولپرز کو یقین دلاتی ہے کہ شائع شدہ کنٹریکٹ کوڈ وہی کوڈ ہے جو ایتھیریم بلاک چین پر کنٹریکٹ کے پتہ پر چل رہا ہے۔

"سورس کوڈ کی تصدیق" اور "[رسمی تصدیق](/developers/docs/smart-contracts/formal-verification/)" کے درمیان فرق کرنا اہم ہے۔ سورس کوڈ کی تصدیق، جس کی تفصیل ذیل میں دی جائے گی، سے مراد یہ تصدیق کرنا ہے کہ کسی اعلیٰ سطحی زبان (جیسے <span dir="ltr">Solidity</span>) میں سمارٹ کنٹریکٹ کا دیا گیا سورس کوڈ اسی بائٹ کوڈ میں کمپائل ہوتا ہے جسے کنٹریکٹ کے پتہ پر عمل میں لایا جانا ہے۔ تاہم، رسمی تصدیق سمارٹ کنٹریکٹ کی درستگی کی تصدیق کو بیان کرتی ہے، جس کا مطلب ہے کہ کنٹریکٹ توقع کے مطابق برتاؤ کرتا ہے۔ اگرچہ یہ سیاق و سباق پر منحصر ہے، کنٹریکٹ کی تصدیق سے عام طور پر سورس کوڈ کی تصدیق مراد ہوتی ہے۔

## سورس کوڈ کی تصدیق کیا ہے؟ {#what-is-source-code-verification}

[ایتھیریم ورچوئل مشین (EVM)](/developers/docs/evm/) میں سمارٹ کنٹریکٹ کی تعیناتی سے پہلے، ڈیولپرز کنٹریکٹ کے سورس کوڈ—یعنی [<span dir="ltr">Solidity</span> میں لکھی گئی](/developers/docs/smart-contracts/languages/) یا کسی اور اعلیٰ سطحی پروگرامنگ زبان کی ہدایات—کو بائٹ کوڈ میں [کمپائل](/developers/docs/smart-contracts/compiling/) کرتے ہیں۔ چونکہ <span dir="ltr">EVM</span> اعلیٰ سطحی ہدایات کو نہیں سمجھ سکتی، اس لیے <span dir="ltr">EVM</span> میں کنٹریکٹ کی منطق کو چلانے کے لیے سورس کوڈ کو بائٹ کوڈ (یعنی نچلی سطح کی، مشینی ہدایات) میں کمپائل کرنا ضروری ہے۔

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

سمارٹ کنٹریکٹ کی تصدیق اس بات کی تفتیش کو ممکن بناتی ہے کہ کنٹریکٹ اس اعلیٰ سطحی زبان کے ذریعے کیا کرتا ہے جس میں اسے لکھا گیا ہے، بغیر مشین کوڈ پڑھے۔ فنکشنز، ویلیوز، اور عام طور پر متغیر (variable) کے نام اور تبصرے (comments) اصل سورس کوڈ کے ساتھ یکساں رہتے ہیں جسے کمپائل اور تعینات کیا جاتا ہے۔ اس سے کوڈ کو پڑھنا بہت آسان ہو جاتا ہے۔ سورس کی تصدیق کوڈ کی دستاویزات (documentation) کا بھی بندوبست کرتی ہے، تاکہ آخری صارفین (end-users) جان سکیں کہ سمارٹ کنٹریکٹ کو کیا کرنے کے لیے ڈیزائن کیا گیا ہے۔

### مکمل تصدیق کیا ہے؟ {#full-verification}

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

بائٹ کوڈ میں اضافی ڈیٹا شامل کر کے اس سے بچنا ممکن ہے جو سورس کوڈ کی درستگی کے لیے ایک _کرپٹوگرافک ضمانت_، اور کمپائلیشن کی معلومات کے _فنگر پرنٹ_ کے طور پر کام کرے۔ ضروری معلومات [<span dir="ltr">Solidity</span> کے کنٹریکٹ میٹا ڈیٹا](https://docs.soliditylang.org/en/v0.8.15/metadata.html) میں پائی جاتی ہے، اور اس فائل کا ہیش کنٹریکٹ کے بائٹ کوڈ کے ساتھ منسلک کیا جاتا ہے۔ آپ اسے [میٹا ڈیٹا پلے گراؤنڈ](https://playground.sourcify.dev) میں عملی طور پر دیکھ سکتے ہیں۔

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

اس قسم کی تصدیق جو میٹا ڈیٹا ہیش کا فائدہ اٹھاتی ہے اسے **"[مکمل تصدیق](https://docs.sourcify.dev/docs/full-vs-partial-match/)"** (یا "کامل تصدیق") کہا جاتا ہے۔ اگر میٹا ڈیٹا ہیشز میل نہیں کھاتے یا تصدیق میں ان پر غور نہیں کیا جاتا تو یہ ایک "جزوی میچ" (partial match) ہوگا، جو فی الحال کنٹریکٹس کی تصدیق کرنے کا زیادہ عام طریقہ ہے۔ یہ ممکن ہے کہ [بدنیتی پر مبنی کوڈ داخل کیا جائے](https://samczsun.com/hiding-in-plain-sight/) جو مکمل تصدیق کے بغیر تصدیق شدہ سورس کوڈ میں ظاہر نہیں ہوگا۔ زیادہ تر ڈیولپرز مکمل تصدیق سے واقف نہیں ہیں اور اپنی کمپائلیشن کی میٹا ڈیٹا فائل نہیں رکھتے، اس لیے اب تک کنٹریکٹس کی تصدیق کے لیے جزوی تصدیق ہی عملی طریقہ رہا ہے۔

## سورس کوڈ کی تصدیق کیوں اہم ہے؟ {#importance-of-source-code-verification}

### اعتماد سے آزادی {#trustlessness}

اعتماد سے آزادی بلاشبہ سمارٹ کنٹریکٹس اور [غیر مرکزی ایپلی کیشنز (dapps)](/developers/docs/dapps/) کے لیے سب سے بڑی بنیاد ہے۔ سمارٹ کنٹریکٹس "ناقابلِ تبدیلی" ہوتے ہیں اور انہیں تبدیل نہیں کیا جا سکتا؛ ایک کنٹریکٹ صرف اسی کاروباری منطق پر عمل کرے گا جو تعیناتی کے وقت کوڈ میں بیان کی گئی تھی۔ اس کا مطلب ہے کہ ڈیولپرز اور انٹرپرائزز ایتھیریم پر تعیناتی کے بعد کنٹریکٹ کے کوڈ میں چھیڑ چھاڑ نہیں کر سکتے۔

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

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

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

### صارف کی حفاظت {#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/) کے لیے ایک خاص پتہ پر ڈیٹا پے لوڈ (کمپائل شدہ بائٹ کوڈ) کے ساتھ ایک ٹرانزیکشن بھیجنے کی ضرورت ہوتی ہے۔ ڈیٹا پے لوڈ سورس کوڈ کو کمپائل کر کے تیار کیا جاتا ہے، اس کے علاوہ ٹرانزیکشن میں ڈیٹا پے لوڈ کے ساتھ منسلک کنٹریکٹ کی مثال کے [کنسٹرکٹر دلائل (arguments)](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) شامل ہوتے ہیں۔ کمپائلیشن حتمی (deterministic) ہوتی ہے، جس کا مطلب ہے کہ اگر وہی سورس فائلز، اور کمپائلیشن سیٹنگز (جیسے کمپائلر ورژن، آپٹیمائزر) استعمال کی جائیں تو یہ ہمیشہ ایک ہی آؤٹ پٹ (یعنی کنٹریکٹ بائٹ کوڈ) پیدا کرتی ہے۔

![A diagram showing showing smart contract source code verification](./source-code-verification.png)

سمارٹ کنٹریکٹ کی تصدیق میں بنیادی طور پر درج ذیل اقدامات شامل ہیں:

1. سورس فائلز اور کمپائلیشن سیٹنگز کو کمپائلر میں ان پٹ کریں۔

2. کمپائلر کنٹریکٹ کا بائٹ کوڈ آؤٹ پٹ کرتا ہے۔

3. دیے گئے پتہ پر تعینات کنٹریکٹ کا بائٹ کوڈ حاصل کریں۔

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

5. مزید برآں، اگر بائٹ کوڈ کے آخر میں میٹا ڈیٹا ہیشز میل کھاتے ہیں، تو یہ ایک مکمل میچ ہوگا۔

نوٹ کریں کہ یہ تصدیق کی ایک سادہ سی وضاحت ہے اور اس میں بہت سی مستثنیات ہیں جو اس کے ساتھ کام نہیں کریں گی جیسے کہ [ناقابلِ تبدیلی متغیرات](https://docs.sourcify.dev/docs/immutables/) کا ہونا۔

## سورس کوڈ کی تصدیق کے ٹولز {#source-code-verification-tools}

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

### Etherscan {#etherscan}

اگرچہ زیادہ تر ایک [ایتھیریم بلاک ایکسپلورر](/developers/docs/data-and-analytics/block-explorers/) کے طور پر جانا جاتا ہے، <span dir="ltr">Etherscan</span> سمارٹ کنٹریکٹ ڈیولپرز اور صارفین کے لیے [سورس کوڈ کی تصدیق کی سروس](https://etherscan.io/verifyContract) بھی پیش کرتا ہے۔

<span dir="ltr">Etherscan</span> آپ کو اصل ڈیٹا پے لوڈ (سورس کوڈ، لائبریری کا پتہ، کمپائلر سیٹنگز، کنٹریکٹ کا پتہ، وغیرہ) سے کنٹریکٹ بائٹ کوڈ کو دوبارہ کمپائل کرنے کی اجازت دیتا ہے۔ اگر دوبارہ کمپائل کیا گیا بائٹ کوڈ آن چین کنٹریکٹ کے بائٹ کوڈ (اور کنسٹرکٹر پیرامیٹرز) سے وابستہ ہے، تو [کنٹریکٹ کی تصدیق ہو جاتی ہے](https://info.etherscan.com/types-of-contract-verification/)۔

ایک بار تصدیق ہو جانے کے بعد، آپ کے کنٹریکٹ کے سورس کوڈ کو "Verified" کا لیبل ملتا ہے اور اسے دوسروں کے آڈٹ کے لیے <span dir="ltr">Etherscan</span> پر شائع کیا جاتا ہے۔ اسے [Verified Contracts](https://etherscan.io/contractsVerified/) سیکشن میں بھی شامل کیا جاتا ہے—جو تصدیق شدہ سورس کوڈز والے سمارٹ کنٹریکٹس کی ایک ریپوزٹری ہے۔

کنٹریکٹس کی تصدیق کے لیے <span dir="ltr">Etherscan</span> سب سے زیادہ استعمال ہونے والا ٹول ہے۔ تاہم، <span dir="ltr">Etherscan</span> کی کنٹریکٹ کی تصدیق میں ایک خامی ہے: یہ آن چین بائٹ کوڈ اور دوبارہ کمپائل کیے گئے بائٹ کوڈ کے **میٹا ڈیٹا ہیش** کا موازنہ کرنے میں ناکام رہتا ہے۔ اس لیے <span dir="ltr">Etherscan</span> میں میچز جزوی میچز ہوتے ہیں۔

[<span dir="ltr">Etherscan</span> پر کنٹریکٹس کی تصدیق کے بارے میں مزید](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327)۔

### Blockscout {#blockscout}

[<span dir="ltr">Blockscout</span>](https://blockscout.com/) ایک اوپن سورس بلاک ایکسپلورر ہے جو سمارٹ کنٹریکٹ ڈیولپرز اور صارفین کے لیے [کنٹریکٹ کی تصدیق کی سروس](https://eth.blockscout.com/contract-verification) بھی فراہم کرتا ہے۔ ایک اوپن سورس متبادل کے طور پر، <span dir="ltr">Blockscout</span> اس بات میں شفافیت پیش کرتا ہے کہ تصدیق کیسے کی جاتی ہے اور تصدیق کے عمل کو بہتر بنانے کے لیے کمیونٹی کے تعاون کو فعال کرتا ہے۔

دیگر تصدیقی خدمات کی طرح، <span dir="ltr">Blockscout</span> آپ کو بائٹ کوڈ کو دوبارہ کمپائل کر کے اور تعینات شدہ کنٹریکٹ کے ساتھ اس کا موازنہ کر کے اپنے کنٹریکٹ کے سورس کوڈ کی تصدیق کرنے کی اجازت دیتا ہے۔ ایک بار تصدیق ہو جانے کے بعد، آپ کے کنٹریکٹ کو تصدیق کا درجہ مل جاتا ہے اور سورس کوڈ آڈیٹنگ اور تعامل کے لیے عوامی طور پر دستیاب ہو جاتا ہے۔ تصدیق شدہ کنٹریکٹس کو آسانی سے براؤزنگ اور دریافت کے لیے <span dir="ltr">Blockscout</span> کی [تصدیق شدہ کنٹریکٹس کی ریپوزٹری](https://eth.blockscout.com/verified-contracts) میں بھی درج کیا جاتا ہے۔

### Sourcify {#sourcify}

[<span dir="ltr">Sourcify</span>](https://sourcify.dev/#/verifier) کنٹریکٹس کی تصدیق کے لیے ایک اور ٹول ہے جو اوپن سورس اور لامركزی ہے۔ یہ کوئی بلاک ایکسپلورر نہیں ہے اور صرف [مختلف <span dir="ltr">EVM</span> پر مبنی نیٹ ورکس](https://docs.sourcify.dev/docs/chains) پر کنٹریکٹس کی تصدیق کرتا ہے۔ یہ دوسرے ٹولز کے لیے اس پر تعمیر کرنے کے لیے ایک عوامی بنیادی ڈھانچے کے طور پر کام کرتا ہے، اور اس کا مقصد میٹا ڈیٹا فائل میں پائے جانے والے [<span dir="ltr">ABI</span>](/developers/docs/smart-contracts/compiling/#web-applications) اور [<span dir="ltr">NatSpec</span>](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) تبصروں کا استعمال کرتے ہوئے زیادہ انسان دوست کنٹریکٹ کے تعاملات کو فعال کرنا ہے۔

<span dir="ltr">Etherscan</span> کے برعکس، <span dir="ltr">Sourcify</span> میٹا ڈیٹا ہیش کے ساتھ مکمل میچز کو سپورٹ کرتا ہے۔ تصدیق شدہ کنٹریکٹس اس کی [عوامی ریپوزٹری](https://docs.sourcify.dev/docs/repository/) میں <span dir="ltr">HTTP</span> اور [<span dir="ltr">IPFS</span>](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) پر پیش کیے جاتے ہیں، جو کہ ایک لامركزی، [مواد سے مخاطب (content-addressed)](https://docs.storacha.network/concepts/content-addressing/) اسٹوریج ہے۔ یہ <span dir="ltr">IPFS</span> پر کنٹریکٹ کی میٹا ڈیٹا فائل لانے کی اجازت دیتا ہے کیونکہ منسلک میٹا ڈیٹا ہیش ایک <span dir="ltr">IPFS</span> ہیش ہوتا ہے۔

مزید برآں، کوئی بھی <span dir="ltr">IPFS</span> پر سورس کوڈ فائلز بھی بازیافت کر سکتا ہے، کیونکہ ان فائلوں کے <span dir="ltr">IPFS</span> ہیشز بھی میٹا ڈیٹا میں پائے جاتے ہیں۔ کسی کنٹریکٹ کی تصدیق اس کے <span dir="ltr">API</span> یا [<span dir="ltr">UI</span>](https://sourcify.dev/#/verifier) پر میٹا ڈیٹا فائل اور سورس فائلز فراہم کر کے، یا پلگ انز کا استعمال کر کے کی جا سکتی ہے۔ <span dir="ltr">Sourcify</span> مانیٹرنگ ٹول نئے بلاکس پر کنٹریکٹ کی تخلیق کو بھی سنتا ہے اور اگر ان کا میٹا ڈیٹا اور سورس فائلز <span dir="ltr">IPFS</span> پر شائع ہوتی ہیں تو کنٹریکٹس کی تصدیق کرنے کی کوشش کرتا ہے۔

[<span dir="ltr">Sourcify</span> پر کنٹریکٹس کی تصدیق کے بارے میں مزید](https://soliditylang.org/blog/2020/06/25/sourcify-faq/)۔

### Tenderly {#tenderly}

[<span dir="ltr">Tenderly</span> پلیٹ فارم](https://tenderly.co/) <span dir="ltr">Web3</span> ڈیولپرز کو سمارٹ کنٹریکٹس بنانے، ٹیسٹ کرنے، مانیٹر کرنے اور چلانے کے قابل بناتا ہے۔ ڈیبگنگ ٹولز کو مشاہدے (observability) اور بنیادی ڈھانچے کے بلڈنگ بلاکس کے ساتھ ملا کر، <span dir="ltr">Tenderly</span> ڈیولپرز کو سمارٹ کنٹریکٹ کی ڈیولپمنٹ کو تیز کرنے میں مدد کرتا ہے۔ <span dir="ltr">Tenderly</span> کی خصوصیات کو مکمل طور پر فعال کرنے کے لیے، ڈیولپرز کو کئی طریقوں کا استعمال کرتے ہوئے [سورس کوڈ کی تصدیق انجام دینے](https://docs.tenderly.co/monitoring/contract-verification) کی ضرورت ہوتی ہے۔

کسی کنٹریکٹ کی نجی یا عوامی طور پر تصدیق کرنا ممکن ہے۔ اگر نجی طور پر تصدیق کی جائے، تو سمارٹ کنٹریکٹ صرف آپ کو (اور آپ کے پروجیکٹ کے دیگر اراکین کو) نظر آتا ہے۔ کسی کنٹریکٹ کی عوامی طور پر تصدیق کرنے سے یہ <span dir="ltr">Tenderly</span> پلیٹ فارم استعمال کرنے والے ہر فرد کو نظر آتا ہے۔

آپ [ڈیش بورڈ](https://docs.tenderly.co/contract-verification)، [<span dir="ltr">Tenderly Hardhat</span> پلگ ان](https://docs.tenderly.co/contract-verification/hardhat)، یا [<span dir="ltr">CLI</span>](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) کا استعمال کرتے ہوئے اپنے کنٹریکٹس کی تصدیق کر سکتے ہیں۔

ڈیش بورڈ کے ذریعے کنٹریکٹس کی تصدیق کرتے وقت، آپ کو <span dir="ltr">Solidity</span> کمپائلر کے ذریعے تیار کردہ سورس فائل یا میٹا ڈیٹا فائل، پتہ/نیٹ ورک، اور کمپائلر سیٹنگز درآمد کرنے کی ضرورت ہوتی ہے۔

<span dir="ltr">Tenderly Hardhat</span> پلگ ان کا استعمال کم کوشش کے ساتھ تصدیق کے عمل پر زیادہ کنٹرول کی اجازت دیتا ہے، جو آپ کو خودکار (بغیر کوڈ) اور دستی (کوڈ پر مبنی) تصدیق کے درمیان انتخاب کرنے کے قابل بناتا ہے۔

## مزید مطالعہ {#further-reading}

- [کنٹریکٹ کے سورس کوڈ کی تصدیق](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)