بررسی جامع امنیت اکوسیستم دیفای؛ از اقدامات پیشگیرانه تا واکنش به حمله

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

مروری بر امنیت اکوسیستم دیفای

براساس گزارش چینالیسس (Chainalysis)، حملات هکری به پروتکل‌های دیفای در سال ۲۰۲۳ منجر از دست رفتن بیش از ۱.۱ میلیارد دلار دارایی کاربران شده است. اگرچه این آمار نسبت به سال قبل از آن کاهش داشته، اما هکرها از روش‌های جدیدی استفاده کرده‌اند. حتی برخی پروتکل‌های معروف که امنیت بالایی داشتند، مانند کرو فایننس (Curve) و کایبرسواپ (KyberSwap) نیز هدف حمله قرار گرفته‌اند. همچنین حملات پیچیده‌ای به آسیب‌پذیری زیرساخت‌ها از جمله ریلی فلش باتز ( Flashbots Relay) انجام شده است.

براساس داده‌های داشبورد سکیوریتی اینسیدنت (Security Incident Dashboard) در نیمه اول سال ۲۰۲۴ نیز هکرها در کمین پروتکل‌های دیفای بوده‌اند و در بیش از ۵۰ حمله، بالغ بر ۱۰۰٬۰۰۰ دلار خسارت وارد کرده‌اند.

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

اقدامات امنیتی پیش‌از راه‌اندازی پروتکل

تدابیر امنیتی پیش از راه‌اندازی پروتکل‌های دیفای شامل آدیت کد، تایید رسمی و تست‌های امنیتی است.

بازبینی کد (Code Audit)

یکی از روش‌های متداول برای اطمینان از امنیت پروتکل، بازبینی کد (Code Audit) است. در این فرآیند، شرکت‌های حسابرسی به‌صورت نیمه خودکار کدها را بازبینی می‌کنند. ابتدا آسیب‌پذیری‌های رایج به‌طور خودکار شناسایی شده و سپس موارد خاص و پیچیده‌ توسط متخصصان به‌صورت دستی بررسی می‌شوند. از شرکت‌های مطرح در این زمینه می‌توان به اوپن زیپلین (OpenZeppelin)، بلاک‌سک (BlockSec) و چین‌سکیوریتی (ChainSecurity) اشاره کرد.

علاوه بر شرکت‌های حسابرسی کد، «پلتفرم‌های رقابت بازبینی» هم وجود دارند. این پلتفرم‌ها به جای ارائه خدمات مستقیم، شرایط مشارکت در حسابرسی‌ها را به‌صورت عمومی منتشر می‌کنند و از محققان امنیتی دعوت به‌عمل می‌آورند تا به‌صورت رقابتی در بازبینی کدها شرکت کنند. شرکت‌کنندگانی که موفق به کشف آسیب‌پذیری‌های پروتکل شوند، پاداش دریافت می‌کنند. ازجمله پلتفرم‌های رقابت بازبینی می‌توان به Code 4 rena ،SHERLOCK ،Cantina و Secure 3 اشاره کرد. ممکن است که این پلتفرم‌ها از لحاظ معیارهایِ ارزیابی آسیب‌پذیری، توزیع پاداش‌ها و استانداردهای مشارکت با یکدیگر تفاوت داشته باشند.

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

• ناتوانی در شناسایی مشکلات امنیتی احتمالی در زمان اجرا: از آنجایی که بازرسی کد به صورت استاتیک و بدون اجرای برنامه انجام می‌شود، قادر به شناسایی مشکلات امنیتی در زمان اجرا و در محیط واقعی نیست. مسائل امنیتی در زمان اجرا عمدتا به خاطر آسیب‌پذیری‌های ناشی از ارتقا قرارداد، تغییرات پیکربندی و وابستگی‌های خارجی پروتکل رخ می‌دهند. به‌علاوه، قابلیت ترکیب‌پذیری (Composability) پروتکل‌های دیفای می‌تواند این مشکلات را تشدید کند.
• توجه ناکافی به برخی مسائل: ممکن است در طول فرآیند بازبینی کد به برخی مسائل توجه کافی نشود. به‌طور مثال، آسیب‌پذیری از دست دادن دقت محاسباتی (Precision Loss) یک مشکل رایج است که ممکن است توسط بازرسان و تیم‌های پروتکل نادیده گرفته شود. بعد از حوادثی مانند هاندرد فایننس(Hundred Financ) و چنلز فایننس (Channels Finance) متخصصان حوزه امنیت، اهمیت تاثیر از دست دادن دقت را بیشتر درک کردند.
• کمبود منابع بازبینی باکیفیت: انجام حسابرسی کد با دقت و کیفیت بالا نیازمند افرادی با تخصص‌های بین‌رشته‌ای است که در زمینه امنیت قراردادهای هوشمند، مالی و علوم کامپیوتر دانش لازم را داشته باشند. اما تعداد دانشگاه‌هایی که به‌طور مستمر و در مقیاس بزرگ چنین متخصصانی را تربیت کنند، انگشت‌شمار است. در نتیجه، حتی اگر پروتکل‌ها بازرسی شوند، بازرسی به اندازه کافی حرفه‌ای نیست و این امر منجر به کاهش کیفیت خدمات بازررسی می‌شود.

بررسی رسمی

منظور از بررسی رسمی (Formal verification) اثبات درستی یا نادرسی یک سیستم بر اساس مشخصات یا ویژگی‌های رسمی از‌پیش‌تعریف شده با استفاده از روش‌های ریاضی است. در این فرآیند، رفتار پروتکل‌های دیفای با استفاده از مدل‌های ریاضی با مشخصات رسمی مقایسه می‌شود تا از مطابقت آن‌ها اطمینان حاصل ‌شود. به‌طور مثال، ابزار “Prover” که توسط شرکت “Certora” توسعه پیدا کرده است، می‌تواند بررسی رسمی را روی پروتکل‌های دیفای انجام دهد. مراحل کار به این صورت است که توسعه‌دهندگان پروتکل، قوانین یا مشخصات را به Prover ارائه می‌دهند، سپس این ابزار تمامی وضعیت‌های ممکن را بررسی می‌کند و از طریق مقایسه نتایج با قوانین، آسیب‌پذیری‌ها را شناسایی می‌کند.

مهم‎ترین مزیت ارزیابی امنیت پروتکل‌های دیفای از بررسی رسمی این است که صحت پروتکل از طریق ریاضیات اثبات می‌شود. اما این روش در کاربردهای عملی، نقاط ضعفی دارد که باعث شده توسعه‌دهندگان کمتر از آن استقبال کنند.

• نیاز به ارائه مشخصات دقیق: در فرآیند بررسی رسمی، توسعه‌دهندگان باید مشخصات و مستندات دقیقی را از رفتار مورد انتظار پروتکل فراهم کنند که متاسفانه اکثر آن‌ها تخصص لازم را در این حوزه ندارند.
• نیاز به بروزرسانی مکرر: با هر بار ارتقای پروتکل، مشخصات آن نیز باید به‌روزرسانی و پروتکل مجددا ارزیابی شود. ممکن است انجام این کار برای برخی پروتکل‌ها زمان‌بر و پرهزینه باشد.

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

ارزیابی امنیتی

در روش ارزیابی امنیتی (Security Testing) پروتکل‌های دیفای از مجموعه‌ای از تست‌ها برای کشف مشکلات امنیتی احتمالی استفاده می‌شود. برخلاف بررسی رسمی که از روش‌های ریاضی و داده‌های نمادین برای اثبات درستی پروتکل استفاده می‌کند، ارزیابی امنیتی مبتنی بر داده‌های ورودی واقعی است. بنابراین، استفاده از این روش کارآمدتر است؛ اما جامعیت کمتری دارد.

اقدامات امنیتی بعد از راه‌اندازی پروتکل‌های دیفای

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

باگ بانتی

باگ بانتی (Bug Bounty) برنامه‌ای برای عیب‌یابی سیستم در ازای پاداش و محافظت اکوسیستم در برابر هک است. در واقع، پروژه با اعلام جزییات برنامه و مقدار پاداش‌ها یک پل ارتباطی میان پروتکل و محققان امنیتی ایجاد می‌کند. شرکت‌کنندگان در صورتی که موفق به شناسایی آسیب‌پذیری‌های روز صفر (Zero-Day Vulnerabilities) پروتکل شوند، جایزه دریافت می‌کنند. ایمیونیفای (Immunefi) یکی از پلتفرم‌های برجسته باگ بانتی در وب ۳ است.

تشخیص حملات

پلتفرم‌های تشخیص حمله (Attack Detection) از طریق اسکن معاملات، تراکنش‌های مخرب را شناسایی می‌کنند. این پلتفرم‌ها هر تراکنشی که با پروتکل تعامل دارد را بررسی می‌کنند، رفتارهای مخرب را می‌یابند و بعد از شناسایی آن‌ها، پیام هشدار صادر می‌کنند. به‌طور مثال، پلتفرم بلاک‌سک فالکون (BlockSec Phalcon) استخرهای حافظه و تراکنش‌های آنچین را اسکن می‌کند و از طریق آنالیز ویژگی‌های رفتاری تراکنش‌ها، رفتارهای مخرب (قراردادها و پروپزال‌های مخرب) را شناسایی می‌کند. این سیستم مانند یک نگهبان امنیتی بی‌وقفه تمام جزییات تراکنش‌ها را تحت‌نظر می‌گیرد و حرکات غیرعادی را از الگوهای رفتاری تراکنش‌ها استخراج می‌کند. همچنین برای شناسایی حملات احتمالی از مدل‌های مالی مشابه با مدل‌هایی که بانک‌ها برای شناسایی تقلب استفاده می‌کنند، کمک می‌گیرد. هایپرنیتو (Hypernative)، هگزاگیت (Hexagate) و آیرن‌بلاکس ون سکیوریتی نتورک (Ironblocks Venn Security Network) نمونه‌های دیگری از پلتفرم‌های شناسایی حملات هستند.

نظارت بر عملیات

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

به‌طور مثال، پلتفرم اوپن زپلین دیفندر (OpenZeppelin Defender) به توسعه‌دهندگان در نوشتن، استقرار و اجرای ایمن قراردادهای هوشمند کمک می‌کند. همچنین پلتفرم BlockSec Phalcon می‌تواند نظارت بر ارتقای قراردادها، تراکنش‌های کیف پول، کنترل دسترسی‌ها و ریسک‌های مرتبط با حاکمیت را برعهده بگیرد. در سیستم مانیتورینگ غیرمتمرکز فورتا نتورک (Forta Network) هم کاربران می‌توانند با ساخت ربات‌ یا خرید اشتراک ربات‌های موجود، در صورت وقوع تهدیدات امنیتی مانند حملات فیشینگ، پیام هشدار دریافت کنند.

اقدامات امنیتی واکنش به حمله

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

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

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

مسدودسازی حمله

در پروتکل‌های دیفای، برای مقابله با هکرها شناسایی حمله به‌تنهایی کافی نیست. اگر پروتکل قابلیت مسدودسازی خودکار حملات (Attack Blocking) را نداشته باشد، ممکن است اقدامات دستی دیر انجام شوند و خسارات سنگینی به‌بار بیاید. در حمله به پروتکل‌هایی مانند گاما استراتژیز (Gamma Strategies)، کایبرسواپ (KyberSwap) و تل‌کوین (Telcoin) واکنش به حملات، چند دقیقه یا حتی چند ساعت طول کشید. هکرها موفق شدند در این فاصله چندین تراکنش مخرب را انجام دهند و دارایی‌های زیادی را سرقت کنند.

حمله به صرافی غیرمتمرکز ولوکور (Velocore) و Rho در ماه جولای منجر به تعلیق عملکرد زنجیره‌های لینیا (Linea) و اسکرول (Scroll) شد. به دنبال این اتفاقات، مشکل متمرکز بودن زنجیره‌های لایه ۲ (L2) بیش از پیش احساس شد.

فرآیند مسدودسازی حملات در پروتکل‌های دیفای وابسته به دو فناوری اصلی است:

• تشخیص زودهنگام (Early Detection): این تکنولوژی به پروتکل اجازه می‌دهد قبل از اینکه تراکنش به بلاکچین ارسال شود، آن را در مرحله «حافظه موقت» بررسی کند و ببیند که آیا تراکنش مخرب است یا خیر.
• پیشگیری خودکار (Automatic Preemption): در این روش قبل از آپلودشدن تراکنش مخرب در زنجیره، یک تراکنش پیشگیرانه برای تعلیق توافق به زنجیره ارسال می‌شود. به این ترتیب، حمله قبل از وقوع متوقف می‌شود و از بروز خسارت جلوگیری می‌کند.

پلتفرم BlockSec Phalcon تنها پلتفرمی است که این تکنولوژی‌های پیشرفته را دارد. پس از اینکه هکر تراکنش مخرب را ارسال می‌کند، موتور نظارت بر حملات فالکون این تراکنش را زودتر شناسایی می‌کند، به کاربران هشدار می‌دهد و پروتکل را به‌طور خودکار متوقف می‌کند تا خسارت‌ها به صفر برسد. کارآیی این محصول در جلوگیری از حملات سایبری در بیش از ۲۰ عملیات با استفاده از هکرهای کلاه سفید (white hat)‌ اثبات شده است و توانسته بیش از ۲۰ میلیون دلار را نجات دهد.

پاسخ خودکار

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

اتاق جنگ

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

پروژه SEAL 911 تیمی متشکل از هکرهای کلاه سفید است که به کاربران، توسعه‌دهندگان و پژوهشگران امنیتی کمک می‌کند در شرایط اضطراری امنیتی به‌طور مستقیم با کارشناسان معتمد ارتباط برقرار کنند. کاربران می‌توانند از طریق ربات تلگرامی Seal 911 به‌سرعت یک اتاق جنگ راه‌اندازی کنند تا در هنگام حمله به پروژه به چالش‌های امنیتی پاسخ دهد.

آنالیز دلایل حمله

زمانی که به یک پروتکل حمله می‌شود شناسایی ریشه مشکل بسیار مهم است و به جلوگیری از حملات مشابه در آینده کمک می‌کند. این مشکل ممکن است یک آسیب‌پذیری درون قرارداد هوشمند یا نحوه سوء استفاده از آن باشد. برای آنالیز تراکنش‌های مرتبط با حمله، نیازمند ابزارهای تخصصی هستیم که از جمله آن‌ها می‌توانیم به فالکون اکسپلورر (Phalcon Explorer)، اوپن‌چین (OpenChain) و تندرلی (Tenderly) اشاره کنیم.

ردیابی جریان وجوه

ردیابی جریان مالی به معنای پیگیری دارایی‌های اولیه مهاجمان و سودهای حاصل از حمله در زنجیره است تا بتوانیم سرنخ آدرس‌ها و نهادهای مرتبط را به‌دست بیاوریم. اگر این وجوه به سمت نهادهای متمرکز مانند صرافی‌ها منتقل شده باشند، می‌توانیم از مقامات قانونی برای فریز و مسدود کردن دارایی کمک بگیریم. شرکت‌ها و پلتفرم‌هایی مانند چینالیسس، تی‌آر‌اِم لبز (TRM Labs)، آرکهام (ARKHAM)، اِلیپتیک (ELLIPTIC) و متاسلوث (MetaSleuth) از جمله مواردی هستند که خدمات ردیابی جریان مالی را ارائه می‌دهند.

معرفی منابع آموزشی برای اقدامات امنیتی پروتکل‌های دیفای

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

• Secureum: یک انجمن در دیسکورد است که روی امنیت اتریوم تمرکز دارد و به‌طور پیوسته مسابقه امنیت قرارداد هوشمند Secureum RACE را برگزار می‌کند.

https://x.com/TheSecureum

• Security Incidents Dashboard: یک پلتفرم آنلاین است و اطلاعات حملات سایبری که خسارت آن‌ها بیش از ۱۰۰٬۰۰۰ دلار باشد را در زمان واقعی جمع‌آوری و به‌روزرسانی می‌کند. به‌عبارت دیگر این داشبورد اطلاعات دقیقی را درباره هر حمله شامل میزان خسارت، زنجیره‌های تحت تاثیر، انواع آسیب‌پذیری‌ها، علت حمله و مستنداتی از نحوه انجام حمله را در اختیار کاربران قرار می‌دهد.

https://app.blocksec.com/explorer/security-incidents

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

https://rekt.news/

• RugDoc: این پلتفرم یک انجمن آموزشی و امنیتی در حوزه دیفای است و اطلاعات ارزیابی ریسک پروژه را ارائه می‌دهد. پلتفرم RugDocWiKi نیز به معرفی اکوسیستم و فناوری دیفای می‌پردازد.

/https://rugdoc.io/

• DeFiHackLabs: یک انجمن امنیتی در حوزه وب ۳ است که به متخصصان و استعداد‌های امنیتی وب ۲ کمک می‌کند وارد این حوزه شوند. این پلتفرم میزبان بیش از ۲٬۰۰۰ عضو و ۲۰۰ هکر کلاه‌سفید از سراسر جهان است و منابع آموزشی ارزشمندی را در اختیار کاربران قرار می‌دهد

https://x.com/DeFiHackLabs

• Solodit: این پلتفرم گزارش‌های آدیت را از شرکت‌های حسابرسی وب ۳ جمع‌آوری می‌کند.

https://solodit.xyz/

• Ethernaut: یک بازی مبتنی بر وب ۳ و سالیدیتی است که در آن بازیکنان باید آسیب‌پذیری‌های موجود در قراردادهای اتریوم را شناسایی کنند.

https://ethernaut.openzeppelin.com/

جمع‌بندی

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