چگونه از امنیت بریج ها اطمینان حاصل کنیم؛ روش های بررسی امنیت پل های بلاک چینی

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

بررسی آسیب‌پذیری‌های پل‌های بلاکچینی

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

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

با افزایش تعداد زنجیره‌های متصل شده به یکدیگر توسط یک پل، تعداد قراردادهای هوشمند مورد نیاز برای انجام عملیات‌های مختلف پل به صورت سهمی (Quadratically) افزایش می‌یابد. افزایش تعداد قراردادهای هوشمند که در زمان‌های مختلف مطابق با پیکربندی‌های سفارشی نوشته و اجرا می‌شوند، ریسک امنیتی در پل‌ها را به سرعت افزایش می‌دهد. در مدل Hub-and-Spoke، یک آسیب‌پذیری مربوط به زنجیره هاب یا شبکه، می‌تواند به‌طور مشابه منجر به آسیب در بخش‌های مختلف شود.

بررسی نحوه هک بریج‌ها

هک اخیر پل بلاکچینی Nomad که امکان انتقال توکن‌ها را بین شبکه‌های اتریوم، آوالانچ، Evmos، میلکومدا (Milkomeda C1) و مون‌بیم (Moonbeam) فراهم می‌کرد، نشان داد وجود یک باگ در قرارداد هوشمند بریج می‌تواند منجر به از دست رفتن بیشتر یا تمام سرمایه‌های پل شود؛ اگرچه اشکال مورد بحث یک آسیب‌پذیری منحصربه‌فرد مرتبط با پل نبود، اما احتمالا این آسیب از یک شکست عملیاتی در قراردادهای هوشمند پل ناشی می‌شود.

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

همچنین در مورد بریج Wormhole مهاجم توانست با نفوذ امنیتی به این شبکه با استفاده از حملات اکسپلویت و به دلیل وجود یک باگ با ایجاد یک امضای جعلی، بیش از۳۲۰ میلیون دلار از دارایی کاربران این پل را سرقت کند. باگ موجود در کدهای ورم هول به مهاجم اجازه می‌داد با دستکاری قرارداد هوشمند این پل در حالی که هیچ اتریومی در شبکه سولانا نداشت، برای خود اتریوم‌های جعلی صادر کرده و در نتیجه ۱۲۰٬۰۰۰ واحد اتر را به بلاک چین اتریوم منتقل و برداشت کند.

معرفی ویژگی‌های امنیتی مورد نیاز در بریج‌ها

بدون تمرکز بر امنیت و نظارت بیشتر، سوءاستفاده از باگ بریج‌ها و سرقت از آنها اجتناب‌ناپذیر است. ارزش کل قفل شده (TVL) بسیار زیادی که توسط پل‌ها نگهداری می‌شود، آنها را به اهداف جذاب‌تری نسبت به پروتکل‌های معمولی تبدیل می‌کند. در هر یک از موارد ذکرشده، آسیب‌پذیری مورد سوءاستفاده به منطق یا ویژگی‌های پروتکل مربوط نمی‌شود، بلکه این حملات مربوط به اشکالات قرارداد هوشمند و نظارت‌های عملیاتی در این بریج‌ها مربوط است.

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

کاربران برای استفاده از پل‌ها چندین ویژگی را مورد بررسی قرار می‌دهند:

•  تجربه کاربری خوب
• اسلیپیج یا لغزش کم
•  اطمینان از ایمن بودن دارایی‌های خود

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

• ویژگی‌های اساسی برای کسب اعتماد
• کیفیت کد
• ویژگی‌های امنیتی

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

ویژگی‌های اساسی برای کسب اعتماد

به طور کلی می‌توان یک بریج را می توان به ۳ جز تقسیم کرد:

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

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

زمان سانسور	زمان مورد نیاز اجماع	تعداد ولیدیتورها	مکانیسم اجماع	نام بریج
۴ دقیقه	۸ دقیقه	۴۷	اثبات سهام نیابتی (DPOS)	Axelar
۱ دقیقه	۲ دقیقه	۲	2-party independence	LayerZero
۱۲ دقیقه	۱۳ دقیقه	۲۴	MPSC + equal-weight TSS	Multichain
هر ۱ دقیقه آپدیت می‌شود	آپتیمیستیک	آپتیمیستیک	آپتیمیستیک	Nomad
۷ دقیقه	۱۳ دقیقه	۱۹	چند امضایی (multi-sig)	Wormhole

اکسلار (Axelar)

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

پیام‌های کراس چین توسط شبکه Axelar از طریق امضاهای آستانه‌ای (Threshold Signatures) تایید می‌شوند. در این امضاها دو فاکتور (t,n) وجود دارند که در آن قدرت رای امضاکنندگان برای امضای پیام در آن باید بیشتر از t باشد. شبکه Axelar در حال حاضر حداکثر ۵۰ اعتبار‌سنج دارد و برای امضای پیام‌ها و اجرای تراکنش‌ها باید از بیش از ۶۶.۶۷ درصد از ولیدیتورها، تراکنش را تایید کنند. شایان ذکر است که تمامی متغیرها را در این شبکه می‌توان از طریق پروپوزال‌های حاکمیتی تغییر داد.

اگرچه در این شبکه حداکثر تعداد اعتبارسنج‌ها از نظر تئوری نامحدود است، اما در عمل به نظر می‌رسد که قدرت رای‌دهی دارای اشکالاتی است؛ زیرا لازم نیست اعتبارسنج‌ها در هر زنجیره‌ای که توسط این شبکه پشتیبانی می‌شوند، نودهای جداگانه راه‌اندازی کنند. در لیست ولیدیتورهای فعلی شبکه Axelar در مجموع ۴۷ اعتبارسنج وجود دارد، در حالی که تنها ۲۰ مورد از آنها قدرت رای معینی دارند که این تعداد برای هر زنجیره متفاوت است. برای مثال، اگر فقط نودهایی را در نظر بگیریم که پیام‌های ارسالی از شبکه Aurora را تایید می‌کنند، ۸ رای برای ارسال موفقیت‌آمیز یک پیام مورد نیاز است و تنها ۴ نود می‌توانند به تبانی برای سانسور یک پیام اقدام کنند.

لایه صفر (LayerZero)

LayerZero یک پروتکل قابلیت همکاری متقابل زنجیره‌ای (CCIP) است که مشکل ارتباط بین زنجیره‌های مختلف را کاهش می‌دهد. اوراکل پیش‌فرض در این پروتکل یک Chainlink DON است که از یک طرح امضای آستانه بین سه شرکت‌کننده (FTX، Polygon و Sequoia) استفاده می‌کند. در زمان نگارش این مقاله به دلیل ماهیت غیر قابل دسترسی پایگاه کد‌های پروتکل LayerZero، نحوه اجرای آن قابل مشاهده نیست.

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

پروتکل Multichain

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

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

شبکه Multichain در حال حاضر متشکل از ۲۴ نود SMPC است که توسط موسسات مختلف اجرا می‌شود. برای تایید یک پیام در این بریج به اکثریت گره‌ها نیاز است. در نتیجه امنیت این پروتکل به امنیت گره‌های SMPC متکی است. برای انجام یک تراکنش در این پروتکل به تایید بیش از نیمی از نودها نیاز است. در این پروتکل ۱۳ امضا‌کننده برای ارسال زنجیره‌ای داده‌ها و امضای ۱۲ نود برای سانسور پیام‌ها نیاز است.

پروتکل Nomad

Nomad یک پروتکل پیام‌رسانی میان زنجیره‌ای است که هدف آن ارائه خدمات به شبکه‌های سازگار با ماشین مجازی اتریوم است. این پروتکل از رویکرد آپتیمیستیک برای اعتبارسنجی پیام‌ها استفاده می‌کند که در آن پیام‌ها به درخت Merkle اضافه می‌شوند، در یک ریشه جدید هش شده و توسط یک Updater در زنجیره منبع منتشر می‌شوند.

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

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

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

قراردادهای هوشمند پروتکل Nomad از طریق یک مدل حاکمیت چند امضایی قابل ارتقا هستند. برای اجرای تغییرات حاکمیتی حداقل به ۳ امضا از ۵ امضا نیاز است. لازم به ذکر است که هک اخیر پروتکل Nomad هیچ ارتباطی با امنیت مکانیسم اجماع آن نداشته است؛ بلکه وجود یک خطا در پیکربندی قراردادهای هوشمند این پروتکل باعث انجام این هک شد.

پروتکل Wormhole

Wormhole از یک شبکه امنیتی اثبات اعتبار (Proof-of-Authority) به عنوان یک اوراکل و یک شبکه رله بدون مجوز برای انتقال پیام‌ها به صورت میان زنجیره‌ای استفاده می‌کند. این شبکه دارای ۱۹ نود یا اصطلاحا نگهبان (Guardian) است که هر یک از آنها به اجرای یک فول نود برای هر یک از زنجیره‌های پشتیبانی‌شده توسط Wormhole پرداخته و پیام‌های منتشر‌شده توسط قراردادهای اصلی Wormhole را در هر زنجیره بررسی می‌کنند. نودهای این پروتکل پیام‌ها را تایید و امضا می‌کنند و سپس آنها را در شبکه همتا‌به‌همتا (P2P) با یکدیگر به اشتراک می‌گذارند. هنگامی که یک پیام توسط بیش از ۲/۳ نودها یا حداقل ۱۳ امضا تایید شد، به زنجیره هدف منتقل می‌شود.

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

ضمانت امنیتی این پروتکل در گرو اعتبار نودهای آن است. نودهای پروتکل Wormhole شامل گروهی ۱۹ نفره از بزرگترین شبکه‌ها و زیرساخت‌ها در Web3 است. برای ثبت یک پیام نادرست در شبکه ورم هول نیاز است تا ۱۳ نود با یکدیگر تبانی کنند. همچنین با امضای ۷ نود سانسور یک پیام امکان‌پذیر می‌شود. علاوه بر این نودهای این پروتکل می‌توانند به حذف یا جایگزینی سایر نودها رای بدهند.

بررسی کیفیت کد (Code Quality Assurance)

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

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

• دریافت اعتبارنامه‌های متعدد از سازمان‌های معتبر و انتشار آنها به صورت عمومی

برگزاری بانتی‌ها

• اختصاص جوایز قانع‌کننده برای ایجاد انگیزه برای توسعه‌دهندگان به منظور پیدا کردن اشکالات کدها

تست کردن

•  انجام تست‌های متعدد از پروتکل با ایجاد هر تغییر در کد‌ها برای شناسایی اشکالات کد

تامین امنیت پیش از استقرار کد

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

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

در جدول زیر CI مخفف عبارت یکپارچه‌سازی پیوسته (Continuous integration) است. در مهندسی نرم‌افزار یکپارچه‌سازی پیوسته، عملی است که برای ادغام همه نسخه‌های کاری توسعه‌دهندگان در یک خط اصلی مشترک، چندین بار در روز انجام می‌شود. گریدی بوچ (Grady Booch) برای اولین بار اصطلاح CI را در روش خود در سال ۱۹۹۱ پیشنهاد کرد.

همچنین CD به معنای تحویل مستمر (Continuous delivery) است. تحویل مستمر یک رویکرد در مهندسی نرم‌افزار است که در آن تیم‌ها نرم‌افزار را در دوره‌های کوتاه تولید می‌کنند و تضمین می‌کنند که نرم‌افزار را می‌توان به طور قابل اعتماد در هر زمان منتشر کرد. هدف CD ساخت، آزمایش و انتشار نرم‌افزار با سرعت بیشتر است.

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

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

برنامه‌نویسی Bash یا Bash scripting بخش بسیار مفید و قدرتمندی از مدیریت و توسعه سیستم است. Bash یک Unix shell (رابط کاربری خط فرمان) است که از یک رابط خط فرمان (CLI) برای تعامل با یک سیستم عامل (OS) استفاده می‌کند. هر دستوری که می‌توانید از خط فرمان اجرا کنید، می‌تواند در یک اسکریپت bash استفاده شود. از این اسکریپت‌ها برای اجرای یک سری از دستورات استفاده می‌شود.

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

امنیت اجرا	انجام	تست جوایز (Bounties)	بازبینی کد	نام بریج
استفاده از کدهای متن باز و checksum verification	CI/CD running	اختصاص ۱ میلیون دلار با استفاده از پروتکل  Immunefi	چندین بازبینی عمومی	Axelar
کدهای متن باز و توسعه توسط تیم	تست جاوا اسکریپت به صورت مستقل	اختصاص ۱۵ میلیون دلار به صورت خصوصی	چندین بازبینی عمومی	LayerZero
متن باز، استقرار کدها به صورت دستی	پوشش تست یکپارچه و محدود	اختصاص ۲ میلیون دلار با استفاده از پروتکل  Immunefi	چندین بازبینی عمومی	Multichain
متن باز، استفاده از bash build scripts	CI/CD running	اختصاص ۱ میلیون دلار با استفاده از پروتکل  Immunefi	بازبینی توسط Quantstamp	Nomad
متن باز، شبیه سازی ارتقا مبتنی بر تجمیع؛ راستی‌آزمایی و تأیید مستقل نگهبان	CI/CD running	اختصاص ۱۰ میلیون دلار با استفاده از پروتکل  Immunefi	چندین بازبینی عمومی و بازبینی توسط شرکت‌های مطرح	Wormhole

اکسلار

Axelar چندین بازبینی کد عمومی و معتبر دارد و یک مجموعه آزمایشی نسبتا قوی را اجرا می‌کند. یکپارچه‌سازی مداوم (CI) و تحویل مداوم (CD) توسط این شرکت در حال اجرا است، اسکریپت‌های ساخت bash و Checksum Verification در این پروتکل‌ انجام می‌شود.

این پروتکل دارای یک برنامه پاداش باگ فعال Immunefi است و در صورت یافتن اشکالات با شدت بحران به کاربران ۱ میلیون دلار پاداش می‌دهد؛ البته پاداش برای سطوح پایین‌تر بسیار کمتر است. همچنین قراردادهای هوشمند پروتکل Axelar به صورت منظم مورد بازبینی قرار می‌گیرد.

توسعه‌دهندگان می‌توانند تغییرات مدنظر خود را در کدهای این پروتکل در گیت هاب اعمال کنند. پس از انجام این کار کدها در قسمت Pull Request سایت گیت هاب ثبت و توسط حداقل یکی از توسعه‌دهندگان و یکی از ناظران پروتکل اکسلار مورد بازبینی قرار گرفته و تغییرات اعمال می‌شوند.

پروتکل LayerZero

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

همچنین به نظر می‌رسد آزمایش‌هایی که برای تست این کدها وجود دارند نسبتا قدیمی و محدود به آزمایش‌های جاوا اسکریپت هستند. پروتکل LayerZero در ماه آوریل اعلامیه‌ای درباره همکاری با Immunefi و اختصاص ۱۵ میلیون دلار برای پیدا کردن باگ در این پروتکل منتشر کرد؛ اما تاکنون هیچ برنامه و دستورالعملی در مورد نحوه ارسال اشکالات توسط LayerZero منتشر نشده است.

پروتکل Multichain

Multichain مورد چندین بازبینی کد عمومی قرار گرفته است و یک برنامه جایزه حداکثر ۲ میلیون دلاری با Immunefi دارد. معیارهای آزمایش کدها در این پروتکل به طور منظم انجام نمی‌شود. به نظر می‌رسد این تست‌ها محدود به یک ABI عمومی و آزمایش انتقال ساده است. همچنین به نظر می‌رسد که فرآیند استقرار در این پروتکل تا حد زیادی دستی است، اگرچه CI و CD نیز در حال اجرا و آزمایش است. کدهای پروتکل Multichain در حال حاضر توسط توسعه‌دهندگان مورد بازبینی قرار می‌گیرند؛ اما به نظر می‌رسد که فقط توسعه‌دهنده اصلی می‌تواند این کد‌ها را ادغام کند.

پروتکل Nomad

Nomad به تازگی توسط شرکت Quantstamp مورد بازبینی قرار گرفته است و یک برنامه جایزه پیدا کردن باگ تا ۱ میلیون دلار در پروتکل Immunefi دارد. مجموعه آزمایشی Nomad شامل چند آزمایش در مورد مسیریابی و پیام‌رسانی است. این پروتکل مشابه Axelar، دارای اسکریپت‌های ساخت bash برای ساخت و تایید بایت کد است. کدهای Nomad در گیت‌هاب در حال بازبینی و تغییر است و برای اعمال این تغییرات نیاز به توسعه‌دهنده اصلی + یک بازبین مستقل است.

پروتکل Wormhole

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

کدهای Wormhole در گیت‌هاب از ترکیب تست واحد و یکپارچه‌سازی استفاده می‌کند، مجموعه گسترده‌ای از CI و CD دارد و مجموعه‌ای از شبیه‌سازی‌ها را برای تایید سازگاری به‌عنوان ارتقا و قابلیت ارتقا در آینده اجرا می‌کند. علاوه بر این پروتکل Wormhole به مشارکت‌کنندگان اجازه می‌دهد به صورت فعال کدهای این پروتکل را مورد بررسی قرار دهند. برای اعمال تغییرات در کدهای Wormhole به حداقل ۳ عضو برای ادغام کد نیاز است. این اعضا شامل توسعه‌دهنده اصلی + ۲ بازبین مستقل هستند.

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

ویژگی‌های امنیتی

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

اکسلار

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

• در نظر گرفتن یک میزان معین برای انتقال وجوه به داخل یا خارج از یک زنجیره
• تعیین محدودیت برای دارایی‌های رپد شده در زنجیره اصلی

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

پروتکل LayerZero

مدل کار بریج LayerZero شامل شرطی است که با استفاده از آن تراکنش، رله را در زنجیره مقصد انتخاب می‌کند. در نتیجه محلی که ویژگی‌های ایمنی درون پروتکل می‌توانند در این مدل مقیاس شوند، درون خود رله است. در ماه آوریل، تیم LayerZero رویکرد خود را برای ویژگی‌های امنیتی درون پروتکل به نام‌های گنبد (Dome) و قبل از جنایت (Pre-crime) اعلام کرد.

در حال حاضر اطلاعات کمی در مورد ویژگی Dome وجود دارد، اما اطلاعاتی در وبلاگ پروتکل LayerZero درباره نحوه عملکرد Pre-Crime ارائه شده است. در این مدل به یک برنامه کاربر (UA) اجازه می‌دهد تا مجموعه‌ای از حالت‌ها را تعریف کند، در مقابل لایه relayer باید آنها را تایید کند. در صورتی که این حالت‌ها نشوند، relayer تراکنش را ارسال نمی‌کند. توجه به این نکته مهم است که به نظر می‌رسد این ویژگی‌ها ماهیت اختصاصی دارند و در حال حاضر متن باز نیستند و اگرچه از نظر مفهومی قوی هستند، ارزیابی مستقل اثربخشی آنها دشوار است.

پروتکل Multichain

Multichain در یک پست برخی از اقدامات امنیتی خود، از جمله ذکر چند ویژگی امنیتی در پیکربندی بریج خود را ارائه کرده است. این ویژگی‌های امنیتی عبارتند از:

محدودیت مقدار تراکنش و محدودیت حجم کل

• این ویژگی به بلاک چین‌هایی با اندازه تراکنش‌های بالاتر اجازه می‌دهد تا با یک محدودیت خاص محدود شوند. علاوه بر این برای زنجیره‌هایی با حجم کلی کم، رویکرد محدودیت حجم کل اتخاذ شده است.

نظارت بر روی زنجیره

• این الگو شامل نظارت بر نرم‌افزار و ناظران زنجیره‌ای برای تشخیص رفتار غیرعادی و آغاز فعالیت‌هایی برای واکنش به هر گونه اتفاق است.

تعلیق محصولات

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

صندوق امنیتی

• این صندوق در واقع یک صندوق بیمه است که ۱۰ درصد از تمام کارمزدهای زنجیره‌ای را برای جبران دارایی‌های از دست رفته کاربران در شرایط خاص دریافت می‌کند.

پروتکل Nomad

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

پروتکل Wormhole

مدل پیام‌رسانی در پروتکل Wormhole چندپخشی است که به موجب آن پیام‌ها توسط شبکه Guardian/Oracle از زنجیره مبدا تایید می‌شوند. این مدل اساسا به یک شبکه Oracle بسیار قوی نیاز دارد که در آن ویژگی‌های امنیتی درون پروتکل قادر به مقیاس‌پذیری هستند. پروژه Wormhole دارای سه ویژگی اصلی امنیتی است که در حال توسعه آنها است. این ویژگی‌های عبارتند از:

Governor

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

Accounting

این ویژگی در Guardian/Oracle پیاده‌سازی شده است و به Guardian‌ها اجازه می‌دهد تا بلاک چین خود را حفظ کنند ( این ویژگی به عنوان wormchain شناخته می‌شود.) که می‌تواند به عنوان دفتر کل کراس چین بین زنجیره‌های متفاوت عمل کند. با استفاده از این دفتر کل نگهبانان به عنوان تایید کننده زنجیره عمل کرده و یک پلاگین حسابداری را پیاده‌سازی می‌کنند. این ویژگی باعث می‌شود که اگر یک تراکنش میان زنجیره‌ای انجام شود؛ اما زنجیره مبدا بودجه کافی نداشته باشد تا زمانی که در زنجیره مبدا موجودی‌ها تطبیق داده نشود، این معاملات انجام نشوند.

Emergency Shutdown

این ویژگی به نگهبانان اجازه می‌دهد در صورت وجود یک تهدید برای بریج، با رسیدن به اجماع به صورت موقت انتقال توکن‌ها را غیرفعال کنند.

جمع بندی

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

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