تست و تأیید رسمی برای امنیت قرارداد هوشمند Web3

وقت خواندن: 9 دقیقه

تصور کنید به چتربازی می روید. قبل از پریدن از هواپیما، صد بار چتر نجات خود را بررسی می کنید، درست است؟ بررسی و آزمایش بخشی جدایی ناپذیر از امنیت است. به هر چیز مرتبط با امنیت فکر کنید احتمالاً مکانیزمی برای آزمایش پس از آن وجود خواهد داشت، چه نصب دوربین مداربسته یا بررسی جوهر قلم قبل از امتحان کتبی در مدرسه، همه ما از اقدامات ایمنی پیروی می کنیم. هر چه ریسک بیشتر باشد، بیشتر چیزها را آزمایش می کنیم. و وقتی در مورد قراردادهای هوشمند صحبت می کنیم، خطر بسیار زیاد است. وقتی صحبت از امنیت قراردادهای هوشمند می شود، نمی توانید بی دقت باشید.

1. امنیت همیشه مورد نیاز است.

مطمئناً می توانید در را دو یا سه بار قفل کنید مهم نیست. آیا می توانید مطمئن باشید که در زمانی که شما رفته اید، نمی توان خانه شما را سرقت کرد؟ شما نمی توانید زیرا نمی دانید که سارق ممکن است چه کاری انجام دهد تا وارد خانه شود - همین امر برای هر اقدام ایمنی که انجام می دهیم صادق است. هیچ روش کاملاً ایمنی وجود ندارد که ایمنی را تضمین کند. با این حال، اقدامی که ما انجام می‌دهیم به سرعت شانس ما را برای ایمن بودن افزایش می‌دهد، یعنی همان بازی. ما می خواهیم با به کارگیری اقدامات مختلف، شانس ایمن بودن را افزایش دهیم.

دنیای Web3 متفاوت نیست. هیچ روش مطمئنی برای نجات خود وجود ندارد، اما داشتن حسابرسان با تجربه از QuillAudits می تواند شانس ایمن شدن پروتکل شما را به شدت افزایش دهد و امنیت به روز شما را تضمین کند. در وب 3، دو مکانیسم مهم وجود دارد که به شما کمک می کند تا با انجام برخی آزمایشات روی پروتکل خود، میزان امنیت خود را درک کنید:

1. تست قرارداد هوشمند
2. تایید رسمی قراردادهای هوشمند

بیایید آنها را با جزئیات درک کنیم و یاد بگیریم که چگونه به ما کمک می کنند تا نقاط ضعف یا آسیب پذیری قراردادهایمان را بشناسیم.

2. تست قرارداد هوشمند

یک توسعه دهنده با تجربه می تواند کار را با کد به یک ماشین توضیح دهد. با این حال، گاهی اوقات ماشین به دلیل نقص یا یک خطای منطقی در کد، مکانیسم دقیقی را که توسعه‌دهنده در ذهن داشته است، نشان نمی‌دهد. تست فرآیندی است که به شناسایی محل خرابی کد ما کمک می‌کند و چه کاری می‌توان انجام داد تا با عملکردی که برای انجام آن نیاز داریم مطابقت داشته باشد.

تست قرارداد هوشمند مرحله ای از چرخه توسعه است که در آن ما تجزیه و تحلیل دقیق قراردادهای خود را انجام می دهیم و سعی می کنیم دریابیم کجا و چرا کد ما شکست می خورد. تقریباً تمام قراردادهای هوشمند تحت این مرحله قرار می گیرند. تست قرارداد هوشمند به دو روش انجام می شود. بیایید آنها را بررسی کنیم.

2.1 خودکار

همانطور که از نام آن پیداست، این روش برای آزمایش قراردادهای هوشمند برای انجام تست اسکریپت استفاده می شود. این شامل نرم افزار خودکار است که آزمایش های مکرر را برای یافتن هر گونه آسیب پذیری و نقص در قراردادهای هوشمند انجام می دهد. این ابزارهای تست خودکار را می توان با داده های تست و نتایج مورد انتظار پیکربندی کرد. سپس نتیجه واقعی با نتایج مورد انتظار مقایسه می شود تا بررسی شود که آیا قرارداد به درستی کار می کند یا خیر. تست های خودکار را می توان بیشتر به سه دسته طبقه بندی کرد.

2.1.1. تست عملکردی

فرض کنید برنامه ای می نویسید که دو عدد a و b را بگیرد و سپس جمع هر دو عدد را برگردانید. بنابراین برای بررسی آن برنامه، 2 و 8 را می دهید و نتیجه مورد انتظار را 10 می کنید. حالا وقتی برنامه اجرا می شود، باید 10 را نیز برگرداند. اگر این کار را کرد، خوب کار می کند، و کد ما درست است، اما اگر این کار را انجام دهد. اینطور نیست، پس کد ما خطایی دارد. 

آزمایش عملکردی مستلزم درک نحوه رفتار قرارداد شما در شرایط خاص است. ما می توانیم آن را با اجرای یک محاسبات با مقادیر انتخاب شده و مقایسه خروجی برگشتی آزمایش کنیم. تست عملکردی دارای سه کلاس است:

1. تست واحد:- این به آزمایش اجزای جداگانه قرارداد هوشمند برای صحت می پردازد. قاطعانه است یا به عباراتی در مورد متغیرها نیاز دارد.

2. ادغام آزمونng: - این به آزمایش چندین مؤلفه جداگانه با هم می پردازد. تست ادغام یک سطح بالاتر از تست واحد در سلسله مراتب است. این به ما کمک می کند تا خطاهای ناشی از تعامل عملکردهای مختلف را که ممکن است بخشی از قراردادهای هوشمند دیگر باشد، تعیین کنیم.

3. سیستم آزمونng: - این بالاترین در سلسله مراتب است. در این، کل قرارداد را به عنوان یک سیستم کاملاً یکپارچه آزمایش می کنیم تا ببینیم آیا مطابق با نیازهای ما عمل می کند یا خیر. این کار از دید کاربر انجام می شود و بهترین راه برای انجام آن، استقرار آن در شبکه های آزمایشی است.

2.1.2. تجزیه و تحلیل استاتیک

حتی بدون اجرای برنامه می توان آنالیز استاتیک را انجام داد. این شامل تجزیه و تحلیل کد منبع یا بایت کد قرارداد هوشمند قبل از اجرا است. بنابراین با ذکر نام، تجزیه و تحلیل استاتیک می تواند منجر به شناسایی برخی آسیب پذیری های رایج شود.

2.1.3. تحلیل دینامیک

برخلاف تجزیه و تحلیل استاتیک، تجزیه و تحلیل پویا در طول زمان اجرای قراردادهای هوشمند برای شناسایی مسائل در کد انجام می شود. تحلیلگرهای کد پویا وضعیت اجرای قرارداد را مشاهده می‌کنند و گزارش مفصلی از آسیب‌پذیری‌ها و نقض مالکیت تولید می‌کنند. Fuzzing تحت تحلیل دینامیک قرار می گیرد. Fuzzing عبارت است از تغذیه ورودی نادرست یا مخرب برای اجرای ناخواسته کد.

2.2 دفترچه راهنما

همانطور که از نام آن پیداست، این روش تست قرارداد هوشمند شامل تعامل منظم با توسعه دهنده انسانی است. ممیزی کد، جایی که توسعه دهندگان از طریق خطوط کد عبور می کنند، تحت حالت دستی تست قرارداد هوشمند قرار می گیرند.

حالت دستی به زمان، مهارت، پول و تلاش قابل توجهی نیاز دارد. با این حال، نتیجه اغلب ارزش آن را دارد زیرا، با این کار، آسیب‌پذیری‌هایی را شناسایی می‌کنیم که ممکن است در آزمایش خودکار مورد توجه قرار نگیرند. دو نوع اساسی تست دستی وجود دارد:

2.2.1 ممیزی کد: - 

بهترین راه برای آزمایش اینکه آیا اقدامات ایمنی شما به درستی کار می کند یا خیر، تلاش برای شکستن آن است. به عنوان مثال، اگر می خواهید بررسی کنید که آیا قفل ماشین شما به درستی کار می کند یا خیر، سعی کنید آن را بشکنید. حالا ممکن است بپرسید که یک دزد ماهر ماشین می تواند به راحتی وارد ماشین من شود. من ممکن است نه، بنابراین راه حل این است که یک نفر را استخدام کنید که در نفوذ مهارت داشته باشد تا بتواند شما را راهنمایی کند!

 بله، من در مورد QuillAudits صحبت می کنم. ما تیمی از حسابرسان ماهر هستیم که می‌توانیم شما را راهنمایی کنیم. ممیزی کد نیازمند یک طرز فکر مهاجم برای یافتن تمام آسیب پذیری های احتمالی در کد منبع است. ممیزی کد یک ارزیابی دقیق از کد قرارداد هوشمند برای کشف آسیب‌پذیری‌ها و نقص‌های احتمالی است.

2.2.2 Bug Bounty: -

اگر فکر می‌کنید ممکن است در کد منبع شما نقص‌های امنیتی وجود داشته باشد (که اغلب وجود دارد) و نمی‌توانید آنها را پیدا کنید، می‌توانید با ایجاد یک سیستم پاداش، این کار را به فریلنسرها برون‌سپاری کنید. این بیشتر شبیه اعلام جایزه برای هر کسی است که بتواند قرارداد هوشمند شما را هک کند. با انجام این کار، با آسیب پذیری موجود در قرارداد هوشمند خود آشنا می شوید تا بتوانید بهتر از آن محافظت کنید و کاربران خود را از ضرر نجات دهید.

3. تأیید رسمی قراردادهای هوشمند

راستی آزمایی رسمی فرآیند ارزیابی صحت قرارداد بر اساس مشخصات رسمی است. این به این معنی است که تأیید رسمی ارزیابی می کند که آیا کد مورد نظر را انجام می دهد یا خیر. تأیید رسمی از روش های رسمی برای تعیین، طراحی و تأیید برنامه ها استفاده می کند.

3.1 مشخصات رسمی چیست؟

در زمینه قراردادهای هوشمند، مشخصات رسمی به خواصی اشاره دارد که باید تحت هر شرایط ممکن یکسان بمانند. اینها ویژگی های «ناغیر» هستند زیرا نمی توانند تغییر کنند و اظهارات منطقی در مورد اجرای قرارداد را نشان دهند.

مشخصات رسمی مجموعه ای از عبارات نوشته شده به زبان رسمی است. مشخصات ویژگی های مختلف را پوشش می دهد و نحوه رفتار ویژگی های قرارداد را در شرایط دیگر توضیح می دهد. مشخصات رسمی بسیار مهم هستند زیرا اگر قراردادها دارای متغیرهای ثابت نشوند یا ویژگی ها در طول اجرا تغییر کنند، می تواند منجر به بهره برداری احتمالی از اموال شود که ممکن است منجر به زیان زیادی شود.

این می تواند به ما کمک کند تعیین کنیم آیا یک قرارداد هوشمند با مشخصات مطابقت دارد یا رفتارهای غیرمنتظره ای دارد. تأیید رسمی دارای سه جزء است: مشخصات، مدل و موتور تأیید.

3.1.1 مشخصات

مشخصات، شرح واضح، بدون ابهام و کاملی از الزامات یک قرارداد هوشمند است. باید توضیح دهد که قرارداد قرار است چه کاری را انجام دهد و چه کاری را نباید انجام دهد. در اینجا یک نمونه مشخصات برای یک قرارداد ساده و هوشمند است که دو عدد را اضافه می کند:

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

مدل 3.1.2

یک مدل به طور رسمی قرارداد هوشمندی را نشان می‌دهد که می‌توان از آن برای استدلال درباره رفتار آن استفاده کرد. یکی از مدل های محبوب برای قراردادهای هوشمند، زبان برنامه نویسی Solidity است. در اینجا یک مدل نمونه برای تابع add توضیح داده شده در بالا آمده است:

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 موتور تأیید

موتور تأیید ابزاری است که می تواند یک مدل را تجزیه و تحلیل کند و صحت آن را در مورد مشخصات داده شده تأیید کند. چندین موتور تأیید برای قراردادهای هوشمند موجود است، از جمله:

افسانه: یک ابزار اجرای نمادین منبع باز که می تواند طیف گسترده ای از آسیب پذیری های امنیتی را در قراردادهای هوشمند Solidity شناسایی کند.

Remix IDE: یک محیط توسعه یکپارچه که شامل یک ابزار تأیید رسمی است که می تواند صحت قراردادهای هوشمند را تأیید کند.

Certora Prover: یک ابزار تجاری که می تواند صحت قراردادهای هوشمند را با استفاده از استدلال ریاضی خودکار تأیید کند. در اینجا مثالی از نحوه استفاده از تأیید رسمی برای تأیید صحت قرارداد هوشمند با استفاده از Certora Prover آورده شده است:

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

در مثال بالا، ما یک قرارداد هوشمند Solidity را تعریف می کنیم که شامل یک مدل از تابع افزودن، یک مشخصات برای تابع و یک موتور تأیید (Certora Prover) است که می تواند صحت عملکرد را تأیید کند. ما همچنین یک تابع تست (test_add) تعریف می کنیم که می تواند برای تأیید صحت تابع استفاده شود.

3.2 تست در مقابل تایید رسمی

همانطور که بحث کردیم، آزمایش نتایج مورد انتظار را برای برخی از ربات‌های داده ورودی که فاقد آن هستند برمی‌گرداند، زیرا نمی‌توانیم درباره داده‌هایی که روی آنها آزمایش نشده است بگوییم. بررسی آن در هر ورودی ممکن عملا غیرممکن است. بنابراین ما در مورد "صحت عملکردی" آن مطمئن نیستیم. اینجاست که تأیید رسمی وارد می‌شود. روش‌های تأیید رسمی از تکنیک‌های ریاضی دقیق برای تعیین و تأیید نرم‌افزار یا قراردادهای هوشمند استفاده می‌کنند.

3.3 تکنیک های تأیید رسمی

تأیید رسمی دارای دامنه وسیعی از تکنیک ها برای افزایش است امنیت قرارداد هوشمند. در این قسمت از وبلاگ به بررسی چند مورد به صورت جداگانه می پردازیم.

3.3.1 بررسی مدل

همانطور که در مورد چیستی مشخصات رسمی بحث کردیم، قرارداد هوشمند را با مشخصات آن در این تکنیک تأیید رسمی بررسی می کنیم. این قراردادهای هوشمند به عنوان سیستم های انتقال حالت نشان داده می شوند و ویژگی ها با استفاده از منطق زمانی تعریف می شوند. 

این تکنیک در درجه اول برای ارزیابی ویژگی های زمانی استفاده می شود که رفتار قراردادهای هوشمند را در طول زمان نشان می دهد. ویژگی کنترل دسترسی (تماس مدیریت خود تخریبی) را می توان به عنوان منطق رسمی نوشت. سپس الگوریتم بررسی مدل می تواند تأیید کند که آیا قرارداد این تأیید رسمی را برآورده می کند یا خیر.

بررسی مدل از تکنیکی به نام اکتشاف فضایی حالت استفاده می‌کند، که اساساً تمام حالت‌های احتمالی قرارداد هوشمند ما را امتحان می‌کند و سپس بررسی می‌کند که آیا هر یک از آنها منجر به نقض مالکیت می‌شود یا خیر. با این حال، این ممکن است به حالت های بی نهایت زیادی منجر شود. از این رو بررسی‌کنندگان مدل بر تکنیک‌های انتزاعی تکیه می‌کنند تا تحلیل کارآمد قراردادهای هوشمند را ممکن کنند.

3.3.2 اثبات قضیه

اثبات قضیه در مورد استدلال ریاضی در مورد درستی برنامه ها است. با ایجاد یک تصور منطقی از سیستم و مشخصات قرارداد و تأیید "هم ارزی منطقی" بین اظهارات سروکار دارد. هم ارزی منطقی یک رابطه ریاضی است که می گوید گزاره A درست است اگر و فقط اگر گزاره B درست باشد.

همانطور که در تکنیک بررسی مدل یاد گرفتیم، قراردادها را به عنوان سیستم های انتقال با حالت های محدود مدل می کنیم. اثبات قضیه می تواند تجزیه و تحلیل سیستم های حالت نامتناهی را انجام دهد. با این حال، یک اثبات کننده قضیه خودکار همیشه نمی تواند بفهمد که آیا یک مسئله منطقی قابل حل است یا خیر. بنابراین، کمک های انسانی اغلب برای هدایت اثبات کننده قضیه در استخراج براهین صحت مورد نیاز است.

4. نتیجه

تست و تایید رسمی هر دو بخش جدایی ناپذیر توسعه قرارداد هوشمند هستند. اینها روش هایی هستند که برای ایمن کردن قراردادهای هوشمند و کمک به آماده سازی قراردادها برای استقرار استفاده می شوند. اما همانطور که می دانید، امنیت هرگز کافی نیست. بسیاری از قراردادهای هوشمند فقط به این دلیل هک می شدند که آزمایش مناسبی وجود نداشت. اکنون بیش از هر زمان دیگری جامعه web3 به پروتکل‌های امن‌تری نیاز دارد. 

ما در QuillAudits ماموریت داریم که به محافظت از پروتکل های شما کمک کنیم. با تیم ماهر و با تجربه خود، مطمئن می شویم که حتی یک آسیب پذیری مورد توجه قرار نگیرد. از وب سایت ما دیدن کنید و پروژه Web3 خود را ایمن کنید!

28 نمایش ها

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• منبع: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/