یکی از اهداف اصلی که پروژه های مبتنی بر بلاک چین به آن دست می یابند، تأیید صحت داده ها است. برای مثال های زنده، می توانید به هویت دیجیتال و ذخیره سازی اسناد آنلاین و چک ها نگاه کنید. در واقع، هر یک از این موارد به تأیید آغازگر اقدام/معامله برای تأیید شخص یا نهاد نیاز دارد. به عنوان مثال، اگر شخص دارای فرم دیجیتالی سند شناسایی باشد، اطمینان از مالکیت بسیار مهم است. بنابراین این یک مثال عالی از مشکل قابلیت تأیید داده ها است. بیایید سادهترین شکل راهحل را مرور کنیم - امضای دیجیتال، که آزمایش آن یکی از نکات مهم در طول توسعه قرارداد هوشمند است.
رویکرد ساده است:
1) سیستم با قوانین شناخته شده برای همه پیامی تولید می کند
2) امضا کننده پیام را دریافت می کند و مجموعه خاصی از نمادها را اضافه می کند - امضای دیجیتال، کدی که از پیام توسط یک کلید خصوصی ساخته شده است.
3) امضای تولید شده اکنون به قرارداد ارسال می شود، جایی که برای بازیابی آدرس امضاکننده تجزیه می شود.
Solidity الگوریتم ECDSA را برای تولید امضا و تجزیه بیشتر به شما ارائه می دهد. ما نیازی به فرو رفتن عمیق در خود الگوریتم نداریم (شما می توانید اطلاعات لازم را پیدا کنید در منابع مناسب). تنها چیزی که باید بدانیم این است که ECDSA نمونه ای از رمزنگاری نامتقارن است که در آن کاربر اول با کلید خصوصی خود یک امضا ایجاد می کند و کاربر دوم یک الگوریتم استاندارد را برای بازیابی کلید عمومی امضاکننده اعمال می کند. بنابراین، می تواند منبع امضا را تأیید کند. در عوض، بیایید روی بخش عملی تمرکز کنیم - استفاده از امضا و آزمایش.
اول از همه، باید یک مشکل را بشناسیم. به عنوان مثال، قرارداد باید اقداماتی را انجام دهد، مثلاً آدرس تماس گیرنده را ذخیره کند. اگرچه قرارداد فقط در صورتی باید ذخیره شود که تماس گیرنده تأیید شده باشد، باید مطمئن باشیم که هیچ کس نمی تواند بدون اجازه از آدرس او استفاده کند. برای بازیابی تماسگیرنده معتبر، باید مقداری پیام تولید کنیم، آن را امضا کنیم و آن را در قرارداد تجزیه کنیم.
شما می توانید پیدا کنید راه حل استاندارد در مستندات Solidity (مثلا، در 0.8.4 - آخرین نسخه پایدار در لحظه مقاله). اسناد قرارداد را به ما پیشنهاد میکنند که به عملکرد داخلی زیر نیاز دارد: تولید پیام، تقسیم امضا، و کد اسمبلی برای بازیابی امضاکننده. مثال تمام روشهای لازم را نشان میدهد و بسیار ساده است، اگرچه دو منفی دارد: جهانی بودن ندارد و نمونه خوبی از تست راهحل وجود ندارد. به همین دلیل است که من نسخه خود را از کد و (هدف واقعی) - استراتژی آزمایش قرارداد را ارائه می کنم.
مطمئناً می توانید استفاده کنید کتابخانه استاندارد OpenZeppelin برای عملیات ECDSA، اما شما دوباره با مشکلات مشابه روبرو خواهید شد - عدم انعطاف پذیری و رویکردهای تست. بنابراین، بیایید به مثال من از منطق مبتنی بر امضا بپردازیم. می توانید کامل را پیدا کنید نمونه کار در GitHub من، اما مکان های کمی وجود دارد که می خواهم به طور کامل نشان دهم.
اول از همه، ما پیام را آماده می کنیم. همانطور که می بینید، از دو آدرس کیف پول بسته بندی شده و هش شده تشکیل شده است:
دومین قطعه مهم کد، هش کردن پیام همراه با پیام استاندارد اتریوم است:
این نشان می دهد که پیام در شبکه اتریوم ارسال شده است و طول آن 32 بایت است که یک عدد تصادفی نیست. بعد از عملیات قبلی، هش را داریم که طول آن 32 بایت است. داشتن تابع هش اضافی در چنین شکلی ضروری است و ما کمی بعد در مورد استدلال بحث خواهیم کرد.
سایر قطعات کد بسیار استاندارد هستند. عملکرد تقسیم امضا به شرح زیر است:
و در اینجا تابع بازیابی امضا کننده است:
برای رابط خارجی، از تابع سفارشی استفاده می کنیم که امضا و آرگومان های لازم را دریافت می کند، بررسی می کند که آیا کاربر قبلاً ثبت نام کرده است، پیام را تشکیل می دهد و امضا را تأیید می کند:
ابتدا پیامی را که باید امضا شود تقلید می کنیم. ما استفاده خواهیم کرد ethers.js کتابخانه، که (همراه با web3) پرکاربردترین و راحت ترین کتابخانه. از آنجایی که این یک کتابخانه منبع باز است، شما آزاد هستید که کاوش کنید کد و اسناد آن. همچنین، این کتابخانه رابط کاملی را برای ساخت پیام زیر به ما می دهد:
یکی از معایب هر دو web3 و اترها کتابخانه ها این است که آنها همه عملکردهای محیط محلی Ganache را ندارند زیرا هر دو کتابخانه برای کار با گره های Ethererum کامل هستند. با این وجود، رویکردی برای استفاده از آزمایش محلی وجود دارد قابلیت web3-account. اگرچه شما نیاز به ایجاد یک حساب اضافی دارید که عملکرد خواننده را اجرا می کند و اتصال به ارائه دهنده وب 3 فعلی را فراهم می کند:
بنابراین، اکنون پیام تولید و امضا شده است. اما، این همه چیز نیست. چند چیز برای صحبت باقی مانده است هر دو کتابخانه (web3 و اترها) در زیر هود، هش اضافی پیام را قبل از ایجاد امضا فراهم می کنند. همچنین، پیام نه تنها هش شده است، بلکه با پیام استاندارد اتریوم که قبلاً دیدیم ترکیب شده است:
و به همین دلیل روش اضافی را به قرارداد اضافه کردیم. بنابراین، اگر میخواهید از پیامهای سفارشی استفاده کنید، از هش کردن اضافی و غیره صرفنظر کنید، باید یک نسخه سفارشی از قابلیت امضا ایجاد کنید. ما دلیل را در بالا مورد بحث قرار دادیم - هر دو کتابخانه استاندارد رویکرد معمولی را برای امضای پیام پیادهسازی میکنند، که تنها با نادیده گرفتن عملکرد قابل تغییر است.
به عنوان آخرین مرحله، آزمایش را اجرا می کنیم و بررسی می کنیم که آیا درست کار می کند یا خیر:
ما تولید امضا، پیام تولید شده، تایید امضا و رد را آزمایش کرده ایم. بنابراین این مجموعه کاملاً کاملی از آزمایشات برای عملکرد تأیید است.
- حساب
- عمل
- اضافی
- الگوریتم
- معرفی
- استدلال
- مقاله
- معتبر
- بیت
- موارد
- چک
- رمز
- قرارداد
- رمزنگاری
- جاری
- داده ها
- پروژه
- دیجیتال
- هویت دیجیتال
- اسناد و مدارک
- محیط
- ethereum
- شبکه اتریوم
- چهره
- نام خانوادگی
- انعطاف پذیری
- تمرکز
- فرم
- رایگان
- کامل
- تابع
- خوب
- مخلوط
- حس کردن
- HTTPS
- ia
- هویت
- اطلاعات
- IP
- IT
- کلید
- آخرین
- کتابخانه
- محلی
- متوسط
- شبکه
- گره
- ارائه
- پیشنهادات
- آنلاین
- باز کن
- منبع باز
- عملیات
- خصوصی
- کلید خصوصی
- پروژه ها
- عمومی
- کلید عمومی
- این فایل نقد می نویسید:
- دویدن
- تنظیم
- ساده
- So
- استحکام
- انشعاب
- ذخیره سازی
- opbevare
- استراتژی
- سیستم
- آزمون
- تست
- تست
- منبع
- us
- تایید
- کیف پول
- ویکیپدیا
- در داخل
- مهاجرت کاری
- با این نسخهها کار