وضعیت اسفبار حسابرسی وب3 و راه‌حل‌های آن

Balancer، یک پروتکل قدیمی و به خوبی حسابرسی شده، اخیراً "هک" شد. Yearn Finance که به همان اندازه به خوبی حسابرسی شده بود نیز همینطور. سال‌ها پیش Euler Finance از طریق یک تابع که در پاسخ به یک حسابرسی قبلی معرفی شده بود "هک" شد. USPD قبل از استقرار حسابرسی شد و سپس فرآیند استقرار حسابرسی نشده خودش هک شد که منجر به شکست کامل در عرض حدود 3 ماه پس از راه‌اندازی شد. هیچ کس که توجه داشته باشد باور ندارد که حسابرسی‌ها تضمینی برای امنیت چیزی هستند. بسیاری سوال می‌کنند که آیا اصلاً ارزشی دارند یا خیر.

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

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

نکته ما اینجا این نیست که حسابرسان کار اشتباهی انجام می‌دهند. حسابرسان کاری را انجام می‌دهند که پروژه‌هایی که آن‌ها را درگیر می‌کنند درخواست می‌کنند. محدوده حسابرسی توسط پروژه تعیین می‌شود. به عنوان یک مثال افراطی: اگر Do Kwon حسابرسانی را برای طرح استیبل کوین خود درگیر کرده بود، آن‌ها متذکر می‌شدند که به طور بالقوه ناپایدار است. این مسئله به عنوان "تایید شده" علامت‌گذاری می‌شد و هیچ کاری انجام نمی‌شد یا متفاوت نبود.

این مشکل اصلاً هیچ ربطی به مطالعاتی مانند مواردی که ادعا می‌کردند اکوسیستم Terra-LUNA دو بسیار قوی است ندارد. پیش‌بینی آینده دشوار است و این نوع مطالعات به درستی به عنوان بازاریابی خودخواهانه در نظر گرفته می‌شوند که در نهایت مشکلات اصلی را تایید می‌کنند. انتظار می‌رود تحقیقات حمایت شده توسط پروژه موارد را در نور مثبت نشان دهند. نکته کلی حسابرسی‌ها ارائه یک دیدگاه عینی شخص ثالث است. به تبلیغات اغراق‌آمیز نباید اعتماد کرد و حسابرسی‌ها تضمین یا بیمه نیستند. زندگی همینطور است.

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

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

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

Jovay

Jovay یک L2 مرتبط با Ant Financial یا Alibaba یا چیزی در آن منطقه کلی است. اما واقعاً مهم نیست که Jovay چه کاری انجام می‌دهد. این چیزی است که از نرم‌افزار خارج از یک سازمان بزرگ و با بودجه خوب ساخته شده است. این حسابرسی هشت مسئله را فهرست می‌کند:

1. یک اشتباه برنامه‌نویسی قانونی که متعاقباً رفع شد.
2. اینکه پروتکل بدون نیاز به اعتماد نیست. این یک نوع مشکل است اما همچنین بخش اصلی طراحی است.
3. حمله "شارژ مجدد جعلی" که به بخش وسیعی از اکوسیستم اعمال می‌شود و مختص پروژه نیست.
4. سرورهای RPC از HTTP به جای HTTPS استفاده می‌کنند. این رابط‌ها اطلاعات محرمانه را پردازش نمی‌کنند. این برای میلیاردها وب‌سایت فقط خواندنی کاملاً امن اعمال می‌شود.
5. محاسبات کوانتومی خطری برای اتریوم ایجاد می‌کند. خوب. بسیار مرتبط با موضوع.
6. قراردادهای هوشمند EVM می‌توانند آسیب‌پذیر باشند. نه جدی. می‌گوید "قراردادهای هوشمند Evm در معرض بردارهای حمله مختلف به دلیل استقرار کد تغییر ناپذیر و تعاملات پیچیده هستند که به طور بالقوه منجر به سرقت وجوه می‌شوند..." خوب. دوباره واقعاً احترام به تمرکز محدود این حسابرسی.
7. طراحی سکوانسر در معرض MEV است. مانند بقیه اکوسیستم اتریوم. همچنین شب‌ها خیلی تاریک است.
8. کیفیت کد می‌تواند بهبود یابد. برخلاف اکثر کدهای دیگری که از ابتدای محاسبات نوشته شده‌اند.

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

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

Hyperliquid

Hyperliquid چند گزارش حسابرسی منتشر کرده است. اولین گزارش حسابرسی شش مشکل را یافت و گزارش دوم تایید کرد که آن‌ها حل شده‌اند. اما محدوده حسابرسی موارد زیر را مستثنی کرد:

1. سایر قراردادهای هوشمند بخشی از سیستم Hyperliquid
2. اجزای آف چین، مانند اعتبارسنج‌ها
3. اجزای فرانت اند
4. زیرساخت مربوط به پروژه
5. نگهداری کلید

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

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

Ondo

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

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

آن حسابرسی‌ها نسبتاً اخیر هستند. اما برای ارائه زمینه‌ای این حسابرسی از اکتبر 2022 مسائل واقعی زیادی را شناسایی می‌کند. تقریباً 200 مورد از آن‌ها. بیشتر آن‌ها رفع شدند، برخی شبیه به موارد فوق بودند و فقط تایید شدند. نکته این است که حسابرسی قبلاً کار مشخص و اساسی انجام می‌داد: جستجو برای خطاهای برنامه‌نویسی که نمی‌توانست قصد برنامه‌نویس باشد. برنامه‌نویسان این خطاها را رفع می‌کردند زیرا آن‌ها، می‌دانید، اشتباهات واقعی بودند نه فقط تصمیمات طراحی مشکوک ساخته شده در محصول.

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

پروژه‌هایی که دقیقاً همانطور که در نظر گرفته شده بودند کار می‌کردند - نه همانطور که رویا دیده می‌شد، همانطور که در واقعیت در نظر گرفته شده بود - گاهی اوقات منفجر می‌شوند زیرا رویاهای طراحان از ثبات وقتی با دنیای واقعی مواجه می‌شوند می‌شکنند.

می‌توانید این تکامل را در حسابرسی‌های این یک پروژه ببینید.

Mutuum Finance

اکنون ما reductio ad absurdum حسابرسی‌ها را داریم. این یکی یک مسئله واحد را شناسایی می‌کند:

مسئله عدم شفافیت در مورد توزیع اولیه توکن و اینکه چگونه ممکن است با مشکلات تمرکز مرتبط باشد است. این "کاهش یافته" زیرا:

سپس جزئیات multisig زیادی وجود دارد. و در نهایت پاسخ حسابرس:

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

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

هدف این حسابرسی چیست؟ اگر کد هیچ اشکال قابل شناسایی نداشت حسابرس می‌توانست فقط آن را بنویسد. گاهی اوقات یک سفر به دکتر یا مکانیک یک گواهی سلامت تمیز تولید می‌کند. بنابراین با این سوال رها می‌شویم که آیا فقط مقدار ناچیزی از کد حسابرسی شد؟ یا شاید خود پروژه فقط مقدار ناچیزی از کد است؟ آیا حسابرس احساس نیاز کرد که چیزی در گزارش بگذارد زیرا در غیر این صورت همه چیز خیلی پوچ بود؟ چرا کسی به این مشکل خورد؟

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

بهبودها

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

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

Ethena نشان می‌دهد که صادق بودن پروژه را محکوم نمی‌کند! می‌توانید استدلال کنید که با صادق‌تر بودن پروژه علاقه بیشتری را جذب کرد. صداقت همچنین مزیت اضافی ارائه پوشش قانونی بیشتر در صورت اشتباه شدن چیزی را دارد. پروژه‌ها باید از قبل بخواهند این کار را انجام دهند.

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

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

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

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

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

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