اسمارٹ کانٹریکٹس کی تصدیق

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

"سورس کوڈ کی تصدیق" اور "رسمی تصدیق (formal verification)" کے درمیان فرق کرنا اہم ہے۔ سورس کوڈ کی تصدیق، جس کی تفصیل ذیل میں دی جائے گی، سے مراد یہ تصدیق کرنا ہے کہ ہائی لیول زبان (جیسے Solidity) میں اسمارٹ کانٹریکٹ کا دیا گیا سورس کوڈ اسی بائٹ کوڈ (bytecode) میں مرتب (compile) ہوتا ہے جسے کانٹریکٹ ایڈریس پر عمل میں لایا جانا ہے۔ تاہم، رسمی تصدیق اسمارٹ کانٹریکٹ کی درستگی کی تصدیق کو بیان کرتی ہے، جس کا مطلب ہے کہ کانٹریکٹ توقع کے مطابق برتاؤ کرتا ہے۔ اگرچہ یہ سیاق و سباق پر منحصر ہے، کانٹریکٹ کی تصدیق سے عام طور پر سورس کوڈ کی تصدیق ہی مراد ہوتی ہے۔

سورس کوڈ کی تصدیق کیا ہے؟

Ethereum Virtual Machine (EVM) میں اسمارٹ کانٹریکٹ کو ڈیپلائے کرنے سے پہلے، ڈیولپرز کانٹریکٹ کے سورس کوڈ کو—جو Solidity میں لکھی گئی ہدایات یا کسی اور ہائی لیول پروگرامنگ زبان میں ہوتا ہے—بائٹ کوڈ میں مرتب (compile) کرتے ہیں۔ چونکہ EVM ہائی لیول ہدایات کو نہیں سمجھ سکتی، اس لیے EVM میں کانٹریکٹ کی منطق (logic) کو چلانے کے لیے سورس کوڈ کو بائٹ کوڈ (یعنی لو لیول، مشین کی ہدایات) میں مرتب کرنا ضروری ہے۔

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

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

مکمل تصدیق کیا ہے؟

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

بائٹ کوڈ میں اضافی ڈیٹا شامل کر کے اس سے بچنا ممکن ہے جو سورس کوڈ کی درستگی کے لیے ایک کرپٹوگرافک گارنٹی کے طور پر، اور تالیف (compilation) کی معلومات کے فنگر پرنٹ کے طور پر کام کرے۔ ضروری معلومات Solidity کے کانٹریکٹ میٹا ڈیٹا (opens in a new tab) میں مل سکتی ہیں، اور اس فائل کا ہیش کانٹریکٹ کے بائٹ کوڈ کے ساتھ منسلک کیا جاتا ہے۔ آپ اسے میٹا ڈیٹا پلے گراؤنڈ (opens in a new tab) میں عملی طور پر دیکھ سکتے ہیں۔

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

اس قسم کی تصدیق جو میٹا ڈیٹا ہیش کا فائدہ اٹھاتی ہے اسے "مکمل تصدیق (full verification) (opens in a new tab)" (یا "کامل تصدیق") کہا جاتا ہے۔ اگر میٹا ڈیٹا ہیشز میل نہیں کھاتے یا تصدیق میں ان پر غور نہیں کیا جاتا تو یہ ایک "جزوی میچ (partial match)" ہو گا، جو فی الحال کانٹریکٹس کی تصدیق کرنے کا زیادہ عام طریقہ ہے۔ یہ ممکن ہے کہ بدنیتی پر مبنی کوڈ داخل کیا جائے (opens in a new tab) جو مکمل تصدیق کے بغیر تصدیق شدہ سورس کوڈ میں ظاہر نہیں ہو گا۔ زیادہ تر ڈیولپرز مکمل تصدیق سے واقف نہیں ہیں اور اپنی تالیف کی میٹا ڈیٹا فائل نہیں رکھتے، اس لیے اب تک کانٹریکٹس کی تصدیق کے لیے جزوی تصدیق ہی ڈی فیکٹو (de facto) طریقہ رہا ہے۔

سورس کوڈ کی تصدیق کیوں اہم ہے؟

ٹرسٹ لیسنیس (Trustlessness)

ٹرسٹ لیسنیس (Trustlessness) بلاشبہ اسمارٹ کانٹریکٹس اور ڈی سینٹرلائزڈ ایپلی کیشنز (dapps) کے لیے سب سے بڑی بنیاد ہے۔ اسمارٹ کانٹریکٹس "ناقابل تغیر (immutable)" ہوتے ہیں اور انہیں تبدیل نہیں کیا جا سکتا؛ ایک کانٹریکٹ صرف اسی کاروباری منطق (business logic) پر عمل کرے گا جو ڈیپلائمنٹ کے وقت کوڈ میں بیان کی گئی تھی۔ اس کا مطلب ہے کہ ڈیولپرز اور انٹرپرائزز Ethereum پر ڈیپلائے کرنے کے بعد کانٹریکٹ کے کوڈ میں چھیڑ چھاڑ نہیں کر سکتے۔

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

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

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

صارف کی حفاظت

اسمارٹ کانٹریکٹس کے ساتھ، عام طور پر بہت سا پیسہ داؤ پر لگا ہوتا ہے۔ اس کے لیے اعلیٰ حفاظتی ضمانتوں اور اسمارٹ کانٹریکٹ کو استعمال کرنے سے پہلے اس کی منطق کی تصدیق کی ضرورت ہوتی ہے۔ مسئلہ یہ ہے کہ بے ایمان ڈیولپرز اسمارٹ کانٹریکٹ میں بدنیتی پر مبنی کوڈ داخل کر کے صارفین کو دھوکہ دے سکتے ہیں۔ تصدیق کے بغیر، بدنیتی پر مبنی اسمارٹ کانٹریکٹس میں بیک ڈورز (backdoors) (opens in a new tab)، متنازعہ ایکسیس کنٹرول میکانزم، قابل استحصال کمزوریاں، اور دیگر چیزیں ہو سکتی ہیں جو صارف کی حفاظت کو خطرے میں ڈالتی ہیں اور جن کا پتہ نہیں چل پاتا۔

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

Ethereum اسمارٹ کانٹریکٹس کے لیے سورس کوڈ کی تصدیق کیسے کریں

Ethereum پر اسمارٹ کانٹریکٹ کو ڈیپلائے کرنے کے لیے ایک خاص ایڈریس پر ڈیٹا پے لوڈ (مرتب شدہ بائٹ کوڈ) کے ساتھ ٹرانزیکشن بھیجنے کی ضرورت ہوتی ہے۔ ڈیٹا پے لوڈ سورس کوڈ کو مرتب کر کے تیار کیا جاتا ہے، اس کے علاوہ ٹرانزیکشن میں ڈیٹا پے لوڈ کے ساتھ منسلک کانٹریکٹ انسٹینس کے کنسٹرکٹر آرگیومنٹس (constructor arguments) (opens in a new tab) شامل ہوتے ہیں۔ تالیف (Compilation) ڈیٹرمنسٹک (deterministic) ہوتی ہے، جس کا مطلب ہے کہ اگر وہی سورس فائلیں، اور تالیف کی ترتیبات (جیسے کمپائلر ورژن، آپٹیمائزر) استعمال کی جائیں تو یہ ہمیشہ ایک ہی آؤٹ پٹ (یعنی کانٹریکٹ بائٹ کوڈ) پیدا کرتی ہے۔

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

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

نوٹ کریں کہ یہ تصدیق کی ایک سادہ سی وضاحت ہے اور اس میں بہت سی مستثنیات ہیں جو اس کے ساتھ کام نہیں کریں گی جیسے کہ ناقابل تغیر متغیرات (immutable variables) (opens in a new tab) کا ہونا۔

سورس کوڈ کی تصدیق کے ٹولز

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

Etherscan

اگرچہ زیادہ تر ایک Ethereum بلاک چین ایکسپلورر کے طور پر جانا جاتا ہے، Etherscan اسمارٹ کانٹریکٹ ڈیولپرز اور صارفین کے لیے سورس کوڈ کی تصدیق کی سروس (opens in a new tab) بھی پیش کرتا ہے۔

Etherscan آپ کو اصل ڈیٹا پے لوڈ (سورس کوڈ، لائبریری ایڈریس، کمپائلر سیٹنگز، کانٹریکٹ ایڈریس وغیرہ) سے کانٹریکٹ بائٹ کوڈ کو دوبارہ مرتب کرنے کی اجازت دیتا ہے۔ اگر دوبارہ مرتب کیا گیا بائٹ کوڈ آن چین کانٹریکٹ کے بائٹ کوڈ (اور کنسٹرکٹر پیرامیٹرز) سے وابستہ ہے، تو کانٹریکٹ کی تصدیق ہو جاتی ہے (opens in a new tab)۔

ایک بار تصدیق ہو جانے کے بعد، آپ کے کانٹریکٹ کے سورس کوڈ کو "Verified" کا لیبل ملتا ہے اور اسے دوسروں کے آڈٹ کے لیے Etherscan پر شائع کیا جاتا ہے۔ اسے Verified Contracts (opens in a new tab) سیکشن میں بھی شامل کیا جاتا ہے—جو تصدیق شدہ سورس کوڈز والے اسمارٹ کانٹریکٹس کی ایک ریپوزٹری ہے۔

Etherscan کانٹریکٹس کی تصدیق کے لیے سب سے زیادہ استعمال ہونے والا ٹول ہے۔ تاہم، Etherscan کی کانٹریکٹ کی تصدیق میں ایک خامی ہے: یہ آن چین بائٹ کوڈ اور دوبارہ مرتب کیے گئے بائٹ کوڈ کے میٹا ڈیٹا ہیش کا موازنہ کرنے میں ناکام رہتا ہے۔ اس لیے Etherscan میں میچز جزوی میچز (partial matches) ہوتے ہیں۔

Etherscan پر کانٹریکٹس کی تصدیق کے بارے میں مزید (opens in a new tab)۔

Blockscout

Blockscout (opens in a new tab) ایک اوپن سورس بلاک چین ایکسپلورر ہے جو اسمارٹ کانٹریکٹ ڈیولپرز اور صارفین کے لیے کانٹریکٹ کی تصدیق کی سروس (opens in a new tab) بھی فراہم کرتا ہے۔ ایک اوپن سورس متبادل کے طور پر، Blockscout اس بات میں شفافیت پیش کرتا ہے کہ تصدیق کیسے کی جاتی ہے اور تصدیق کے عمل کو بہتر بنانے کے لیے کمیونٹی کے تعاون کو قابل بناتا ہے۔

دیگر تصدیقی خدمات کی طرح، Blockscout آپ کو بائٹ کوڈ کو دوبارہ مرتب کر کے اور ڈیپلائے کیے گئے کانٹریکٹ کے ساتھ اس کا موازنہ کر کے اپنے کانٹریکٹ کے سورس کوڈ کی تصدیق کرنے کی اجازت دیتا ہے۔ ایک بار تصدیق ہو جانے کے بعد، آپ کے کانٹریکٹ کو تصدیق کا درجہ مل جاتا ہے اور سورس کوڈ آڈیٹنگ اور تعامل کے لیے عوامی طور پر دستیاب ہو جاتا ہے۔ تصدیق شدہ کانٹریکٹس کو آسانی سے براؤز کرنے اور دریافت کرنے کے لیے Blockscout کی تصدیق شدہ کانٹریکٹس کی ریپوزٹری (opens in a new tab) میں بھی درج کیا جاتا ہے۔

Sourcify

Sourcify (opens in a new tab) کانٹریکٹس کی تصدیق کے لیے ایک اور ٹول ہے جو اوپن سورس اور ڈی سینٹرلائزڈ ہے۔ یہ کوئی بلاک ایکسپلورر نہیں ہے اور صرف مختلف EVM پر مبنی نیٹ ورکس (opens in a new tab) پر کانٹریکٹس کی تصدیق کرتا ہے۔ یہ دوسرے ٹولز کے لیے اس کے اوپر تعمیر کرنے کے لیے ایک عوامی انفراسٹرکچر کے طور پر کام کرتا ہے، اور اس کا مقصد میٹا ڈیٹا فائل میں موجود ABI اور NatSpec (opens in a new tab) تبصروں کا استعمال کرتے ہوئے زیادہ انسان دوست کانٹریکٹ کے تعاملات کو فعال کرنا ہے۔

Etherscan کے برعکس، Sourcify میٹا ڈیٹا ہیش کے ساتھ مکمل میچز کو سپورٹ کرتا ہے۔ تصدیق شدہ کانٹریکٹس اس کی عوامی ریپوزٹری (opens in a new tab) میں HTTP اور IPFS (opens in a new tab) پر پیش کیے جاتے ہیں، جو کہ ایک ڈی سینٹرلائزڈ، کنٹینٹ ایڈریسڈ (content-addressed) (opens in a new tab) اسٹوریج ہے۔ یہ IPFS پر کانٹریکٹ کی میٹا ڈیٹا فائل لانے کی اجازت دیتا ہے کیونکہ منسلک میٹا ڈیٹا ہیش ایک IPFS ہیش ہوتا ہے۔

مزید برآں، کوئی بھی IPFS پر سورس کوڈ فائلیں بازیافت کر سکتا ہے، کیونکہ ان فائلوں کے IPFS ہیشز بھی میٹا ڈیٹا میں پائے جاتے ہیں۔ کسی کانٹریکٹ کی تصدیق اس کے API یا UI (opens in a new tab) پر میٹا ڈیٹا فائل اور سورس فائلیں فراہم کر کے، یا پلگ انز کا استعمال کر کے کی جا سکتی ہے۔ Sourcify مانیٹرنگ ٹول نئے بلاکس پر کانٹریکٹ کی تخلیق کو بھی سنتا ہے اور اگر ان کا میٹا ڈیٹا اور سورس فائلیں IPFS پر شائع ہوتی ہیں تو کانٹریکٹس کی تصدیق کرنے کی کوشش کرتا ہے۔

Sourcify پر کانٹریکٹس کی تصدیق کے بارے میں مزید (opens in a new tab)۔

Tenderly

Tenderly پلیٹ فارم (opens in a new tab) Web3 ڈیولپرز کو اسمارٹ کانٹریکٹس بنانے، ٹیسٹ کرنے، مانیٹر کرنے اور چلانے کے قابل بناتا ہے۔ ڈیبگنگ ٹولز کو آبزرویبلٹی (observability) اور انفراسٹرکچر بلڈنگ بلاکس کے ساتھ ملا کر، Tenderly ڈیولپرز کو اسمارٹ کانٹریکٹ کی ڈیولپمنٹ کو تیز کرنے میں مدد کرتا ہے۔ Tenderly کی خصوصیات کو مکمل طور پر فعال کرنے کے لیے، ڈیولپرز کو کئی طریقوں کا استعمال کرتے ہوئے سورس کوڈ کی تصدیق کرنے (opens in a new tab) کی ضرورت ہوتی ہے۔

کسی کانٹریکٹ کی نجی یا عوامی طور پر تصدیق کرنا ممکن ہے۔ اگر نجی طور پر تصدیق کی جائے، تو اسمارٹ کانٹریکٹ صرف آپ کو (اور آپ کے پروجیکٹ کے دیگر اراکین کو) نظر آتا ہے۔ کسی کانٹریکٹ کی عوامی طور پر تصدیق کرنے سے یہ Tenderly پلیٹ فارم استعمال کرنے والے ہر شخص کو نظر آتا ہے۔

آپ ڈیش بورڈ (opens in a new tab)، Tenderly Hardhat پلگ ان (opens in a new tab)، یا CLI (opens in a new tab) کا استعمال کرتے ہوئے اپنے کانٹریکٹس کی تصدیق کر سکتے ہیں۔

ڈیش بورڈ کے ذریعے کانٹریکٹس کی تصدیق کرتے وقت، آپ کو Solidity کمپائلر کے ذریعے تیار کردہ سورس فائل یا میٹا ڈیٹا فائل، ایڈریس/نیٹ ورک، اور کمپائلر کی ترتیبات درآمد کرنے کی ضرورت ہوتی ہے۔

Tenderly Hardhat پلگ ان کا استعمال کم محنت کے ساتھ تصدیق کے عمل پر زیادہ کنٹرول کی اجازت دیتا ہے، جو آپ کو خودکار (نو-کوڈ) اور دستی (کوڈ پر مبنی) تصدیق کے درمیان انتخاب کرنے کے قابل بناتا ہے۔

مزید مطالعہ

کانٹریکٹ کے سورس کوڈ کی تصدیق (opens in a new tab)