ایک اہم اہداف جو بلاکچین پر مبنی پروجیکٹس حاصل کرنا چاہتے ہیں ڈیٹا کی تصدیق ہے۔ لائیو مثالوں کے لیے، آپ ڈیجیٹل شناخت اور آن لائن دستاویزات کے ذخیرہ اور چیک کو دیکھ سکتے ہیں۔ درحقیقت، ان میں سے کسی بھی صورت میں فرد یا ہستی کی تصدیق کے لیے کارروائی/لین دین شروع کرنے والے کی تصدیق کی ضرورت ہوتی ہے۔ مثال کے طور پر، اگر اس شخص کے پاس شناختی دستاویز کی ڈیجیٹل شکل ہے، تو ملکیت کو یقینی بنانا بہت ضروری ہو جاتا ہے۔ اس طرح یہ ڈیٹا کی تصدیق کے مسئلے کی ایک بہترین مثال ہے۔ آئیے حل کی آسان ترین شکل کا جائزہ لیتے ہیں — ایک ڈیجیٹل دستخط، جس کی جانچ سمارٹ کنٹریکٹ کی ترقی کے دوران اہم نکات میں سے ایک ہے۔
طریقہ آسان ہے:
1) سسٹم ہر ایک کے لیے معلوم قوانین کے ذریعے ایک پیغام تیار کرتا ہے۔
2) دستخط کنندہ کو پیغام ملتا ہے اور علامتوں کا ایک مخصوص سیٹ شامل کرتا ہے — ڈیجیٹل دستخط، ایک نجی کلید کے ذریعے پیغام سے بنایا گیا کوڈ
3) تیار کردہ دستخط اب معاہدے پر بھیجے جاتے ہیں، جہاں دستخط کنندہ کا پتہ بازیافت کرنے کے لیے اسے تحلیل کیا جاتا ہے۔
سولیڈیٹی آپ کو دستخط کی تیاری اور مزید سڑنے کے لیے ECDSA الگورتھم پیش کرتی ہے۔ ہمیں الگورتھم میں گہرا غوطہ لگانے کی ضرورت نہیں ہے (آپ ضروری معلومات حاصل کر سکتے ہیں۔ مناسب ذرائع میں)۔ ہمیں صرف یہ جاننے کی ضرورت ہے کہ ECDSA غیر متناسب کرپٹوگرافی کی ایک مثال ہے، جہاں پہلا صارف اپنی نجی کلید سے ایک دستخط بناتا ہے، اور دوسرا صارف دستخط کنندہ کی عوامی کلید کو بازیافت کرنے کے لیے ایک معیاری الگورتھم کا اطلاق کرتا ہے۔ اس طرح، یہ دستخط کے ذریعہ کی تصدیق کر سکتا ہے. اس کے بجائے، آئیے عملی حصے پر توجہ مرکوز کریں — دستخط کا استعمال اور جانچ۔
سب سے پہلے، ہمیں ایک مسئلہ کو تسلیم کرنے کی ضرورت ہے. مثال کے طور پر، معاہدے کو کچھ کارروائی کرنے کی ضرورت ہے، آئیے کہتے ہیں، کال کرنے والے کا پتہ محفوظ کریں۔ اگرچہ معاہدہ صرف اس صورت میں اسٹوریج انجام دے جب کال کرنے والے کی تصدیق ہو، ہمیں اس بات کا یقین کرنے کی ضرورت ہے کہ کوئی بھی ان کا پتہ بغیر اجازت کے استعمال نہ کر سکے۔ مستند کال کرنے والے کو بازیافت کرنے کے لیے، ہمیں کچھ پیغام تیار کرنے، اس پر دستخط کرنے، اور اسے معاہدے کے اندر ہی ختم کرنے کی ضرورت ہے۔
آپ تلاش کر سکتے ہیں سولیڈیٹی دستاویزات میں معیاری حل (مثال کے طور پر، 0.8.4 میں۔ - مضمون کے اس وقت کا تازہ ترین مستحکم ورژن)۔ دستاویزات ہمیں معاہدہ پیش کرتے ہیں، جس میں درج ذیل بلٹ ان فعالیت کی ضرورت ہوتی ہے: دستخط کنندہ کو بازیافت کرنے کے لیے پیغام تیار کرنا، دستخط تقسیم کرنا، اور اسمبلی کوڈ۔ مثال تمام ضروری طریقوں کو ظاہر کرتی ہے اور بہت سیدھی ہے، حالانکہ اس کے دو نقصانات ہیں: اس میں آفاقیت کا فقدان ہے، اور حل کی جانچ کی کوئی اچھی مثال نہیں ہے۔ اسی لیے میں کوڈ کا اپنا ورژن اور (اصل مقصد) — معاہدے کی جانچ کی حکمت عملی فراہم کرتا ہوں۔
ضرور، آپ استعمال کر سکتے ہیں۔ معیاری اوپن زیپلین لائبریری ECDSA آپریشنز کے لیے، لیکن آپ کو دوبارہ انہی مسائل کا سامنا کرنا پڑے گا - لچک کی کمی اور جانچ کے طریقوں کی کمی۔ تو، آئیے دستخط پر مبنی منطق کی اپنی مثال میں غوطہ لگائیں۔ آپ مکمل تلاش کرسکتے ہیں۔ میرے GitHub میں کام کرنے کی مثال، لیکن کچھ جگہیں ہیں جو میں پوری طرح دکھانا چاہتا ہوں۔
سب سے پہلے، ہم پیغام تیار کریں گے. جیسا کہ آپ دیکھ سکتے ہیں، یہ دو پیکڈ اور ہیش والے بٹوے کے پتوں سے بنتا ہے:
کوڈ کا دوسرا اہم ٹکڑا معیاری Ethereum پیغام کے ساتھ پیغام کو ہیش کرنا ہے۔
یہ ظاہر کرتا ہے کہ پیغام ایتھریم نیٹ ورک کے اندر بھیجا گیا تھا اور اس کی لمبائی 32 بائٹ ہے، جو کہ کوئی بے ترتیب نمبر نہیں ہے۔ پچھلے آپریشنز کے بعد، ہمارے پاس ہیش ہے، جس کی لمبائی 32 بائٹ ہے۔ اس طرح کی شکل میں اضافی ہیشنگ فنکشن کا ہونا ضروری ہے، اور ہم تھوڑی دیر بعد استدلال پر بات کریں گے۔
دوسرے کوڈ کے ٹکڑے کافی معیاری ہیں۔ دستخط کو تقسیم کرنے کا فنکشن مندرجہ ذیل ہے:
اور دستخط کنندہ کو بازیافت کرنے کا فنکشن یہ ہے:
بیرونی انٹرفیس کے لیے، ہم کسٹم فنکشن کا استعمال کریں گے، جو دستخط اور ضروری دلائل وصول کرتا ہے، یہ چیک کرتا ہے کہ آیا صارف پہلے سے رجسٹرڈ ہے، پیغام بناتا ہے، اور دستخط کی تصدیق کرتا ہے:
سب سے پہلے، ہم اس پیغام کی نقل کریں گے جس پر دستخط کرنے کی ضرورت ہے۔ ہم استعمال کریں گے۔ ethers.js لائبریری، جو ہے (ایک ساتھ ویب ایکسیمیم) سب سے زیادہ استعمال شدہ اور آسان لائبریری۔ چونکہ یہ ایک اوپن سورس لائبریری ہے، اس لیے آپ دریافت کرنے کے لیے آزاد ہیں۔ اس کا کوڈ اور دستاویزات. نیز، یہ لائبریری ہمیں درج ذیل پیغام کی تعمیر کے لیے بہترین انٹرفیس فراہم کرتی ہے۔
دونوں کے نقصانات میں سے ایک ویب ایکسیمیم اور اخلاقیات لائبریریاں یہ ہیں کہ ان کے پاس مقامی گاناچے ماحول کے لیے تمام افعال موجود نہیں ہیں کیونکہ دونوں لائبریریوں کا مقصد مکمل ایتھرم نوڈس کے ساتھ کام کرنا ہے۔ اس کے باوجود، استعمال کرتے ہوئے مقامی جانچ کے لئے ایک نقطہ نظر ہے web3-اکاؤنٹ کی فعالیت. اگرچہ آپ کو ایک اضافی اکاؤنٹ بنانے کی ضرورت ہے، جو گلوکار کی فعالیت کو نافذ کرے گا اور موجودہ web3 فراہم کنندہ سے کنکشن فراہم کرے گا:
تو، اب ہمارے پاس پیغام تیار اور دستخط شدہ ہے۔ لیکن، یہ سب کچھ نہیں ہے؛ بات کرنے کے لیے کچھ چیزیں باقی ہیں۔ ہڈ کے نیچے دونوں لائبریریاں (ویب 3 اور ایتھر) دستخط کی تخلیق سے پہلے پیغام کی اضافی ہیشنگ فراہم کرتی ہیں۔ اس کے علاوہ، پیغام کو صرف ہیش نہیں کیا گیا ہے بلکہ معیاری ایتھریم پیغام کے ساتھ جوڑا گیا ہے جو ہم نے پہلے دیکھا تھا:
اور اسی لیے ہم نے معاہدے میں اضافی طریقہ شامل کیا۔ لہذا، اگر آپ حسب ضرورت پیغامات استعمال کرنا چاہتے ہیں، اضافی ہیشنگ وغیرہ کو چھوڑنا چاہتے ہیں، تو آپ کو دستخطی فعالیت کا ایک حسب ضرورت ورژن بنانا ہوگا۔ ہم نے اوپر کی وجہ پر تبادلہ خیال کیا ہے — دونوں معیاری لائبریریاں پیغام پر دستخط کرنے کے لیے مخصوص طریقہ کو نافذ کرتی ہیں، جسے صرف فعالیت کو اوور رائیڈ کر کے تبدیل کیا جا سکتا ہے۔
آخری مرحلے کے طور پر، آئیے ٹیسٹ چلائیں اور چیک کریں کہ آیا یہ صحیح طریقے سے کام کرتا ہے:
ہم نے دستخط کی تیاری، تیار کردہ پیغام، دستخط کی منظوری، اور مسترد کرنے کا تجربہ کیا ہے۔ تو یہ تصدیقی فعالیت کے لیے ٹیسٹوں کا ایک مکمل مجموعہ ہے۔
- اکاؤنٹ
- عمل
- ایڈیشنل
- یلگورتم
- تمام
- دلائل
- مضمون
- مستند
- بٹ
- مقدمات
- چیک
- کوڈ
- کنٹریکٹ
- کرپٹپٹ
- موجودہ
- اعداد و شمار
- ترقی
- ڈیجیٹل
- ڈیجیٹل شناخت
- دستاویزات
- ماحولیات
- ethereum
- ایتھریم نیٹ ورک
- چہرہ
- پہلا
- لچک
- توجہ مرکوز
- فارم
- مفت
- مکمل
- تقریب
- اچھا
- ہیش
- ہیشنگ
- HTTPS
- ia
- شناختی
- معلومات
- IP
- IT
- کلیدی
- تازہ ترین
- لائبریری
- مقامی
- درمیانہ
- نیٹ ورک
- نوڈس
- پیش کرتے ہیں
- تجویز
- آن لائن
- کھول
- اوپن سورس
- آپریشنز
- نجی
- ذاتی کلید
- منصوبوں
- عوامی
- عوامی کلید
- کا جائزہ لینے کے
- رن
- مقرر
- سادہ
- So
- استحکام
- تقسیم
- ذخیرہ
- ذخیرہ
- حکمت عملی
- کے نظام
- ٹیسٹ
- ٹیسٹنگ
- ٹیسٹ
- ماخذ
- us
- توثیق
- بٹوے
- وکیپیڈیا
- کے اندر
- کام
- کام کرتا ہے