الانتقال إلى المحتوى الرئيسي

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
تكتشف عمليات التدقيق بعض فئات الأخطاء (أنماط الهجوم المعروفة وأخطاء التحكم في الوصول وتجاوز الأعداد الصحيحة) وتفتقد فئات أخرى (أخطاء التصميم الاقتصادي والتلاعب بنظرية اللعبة وأخطاء التكامل مع البرامج الأخرى). تحتوي برامج Raydium على عدة جولات من عمليات التدقيق لكل منها؛ تسرد هذه الصفحة عمليات التدقيق وتناقش ما تحققه كل عملية تدقيق بالفعل.

​
جدول التدقيق حسب البرنامج

البرنامجالمدققالتاريخالتقرير
Order-book AMMKudelski SecurityQ2 2021عرض
السيولة المركزة (CLMM)OtterSecQ3 2022عرض
AMM لدفتر الطلبات المحدّثOtterSecQ3 2022عرض
المراهنةOtterSecQ3 2022عرض
هجرة AMM لدفتر الطلبات و OpenBookMadShieldQ2 2023عرض
AMM بالناتج الثابت (CPMM)MadShieldQ1 2024عرض
حرق وكسب (قفل السيولة)HalbornQ4 2024عرض
LaunchLabHalbornQ2 2025عرض
CPMM (تحديث)Sec3Q3 2025عرض
تحديث CLMM — Limit Order و Dynamic Fee و Single Asset FeeSec3Q2 2026عرض
أجرى فريق Neodyme أيضاً مراجعات شاملة عبر اتفاقيات برنامج البحث عن الأخطاء. يتم نسخ جميع تقارير التدقيق لبرامج Raydium تحت github.com/raydium-io/raydium-docs/audit/. ينشر كل مدقق أيضاً على موقعه الخاص.

​
ما تغطيه عمليات التدقيق

عملية تدقيق Raydium النموذجية (من 3 إلى 6 أسابيع، مدققان) تغطي:
  • التحكم في الوصول — هل تم تأمين كل عملية حساسة بشكل صحيح؟
  • الحسابات — تجاوزات، نقائص، اتجاه التقريب، دقة النقطة الثابتة.
  • التحقق من الحسابات — هل لكل حساب المالك والـ mint والسلطة الصحيحة؟
  • أنماط تشبه إعادة الدخول — هل يتم تحديث الحالة قبل أم بعد CPI؟
  • اشتقاق PDA — هل البذور متسقة عبر جميع المواقع؟
  • رموز الأخطاء والرسائل — هل تنعكس أخطاء الحالة بشكل نظيف؟
  • جودة الكود — Rust الطبيعي والكود الميت والفروع التي لا يمكن الوصول إليها.

​
ما لا تغطيه عمليات التدقيق

  • نظرية اللعبة الاقتصادية — على سبيل المثال «إذا كان بإمكاني إنشاء 1000 تجمع مجاناً، هل يمكنني إساءة استخدام الموجه؟»
  • MEV / الترتيب — هجمات ساندويتش، front-running عبر تواطؤ المدقق.
  • البنية الأساسية خارج السلسلة — موثوقية RPC وصحة المفهرس والواجهة الأمامية.
  • التكاملات مع البرامج الأخرى — الأخطاء التي تظهر فقط عند التكوين مع عقود إقراض أو خيارات أو محررات معينة.
  • السلوكيات الناشئة بمرور الوقت — ماذا يحدث بعد 10 ملايين مركز؟ تنظر عمليات التدقيق إلى حالات اختبار صغيرة الحجم.
هذا هو السبب في أن التدقيق ≠ ضمان الأمان. تكمل Raydium عمليات التدقيق ببرامج البحث عن الأخطاء والمراقبة والهندسة الدفاعية.

​
حالة حل الأمور

تنتج كل عملية تدقيق قائمة بالأمور (حرجة / عالية / متوسطة / منخفضة / معلوماتية) مع عدد الشدة وحالة كل أمر (تم الإصلاح / معترف به / لن يتم الإصلاح). لا يتم نسخ تفاصيل كل أمر هنا — اقرأ كل تقرير مباشرة عبر الجدول أعلاه.

​
إعادة التدقيق بعد التغييرات الجوهرية

عندما يطلق البرنامج ترقية جوهرية (تعليمات جديدة أو حقل حساب جديد أو دعم امتداد جديد)، تأمر Raydium بإعادة تدقيق. مراجعة Sec3 Q3 2025 لـ CPMM ومراجعة Sec3 Q2 2026 لـ CLMM (Limit Order و Dynamic Fee و Single Asset Fee) المدرجة في الجدول أعلاه هي إعادة تدقيق من هذا النوع. نطاق إعادة التدقيق أضيق (فقط الفرق)، لكنها بالفعل إعادة تدقيق حقيقية — وليس فقط مراجعة كود. تضاف التقارير الخاصة بإعادات التدقيق إلى تقرير التدقيق الأساسي.

​
التحقق على السلسلة

يجب أن يطابق بصمة البرنامج المنشور بصمة كود البرنامج المدقق. يمكن لأي شخص التحقق: 
# سحب bytecode البرنامج المنشور.
solana program dump <PROGRAM_ID> program.so

# بناء المستودع في commit المدقق.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# المقارنة.
sha256sum program.so target/deploy/raydium_cp_swap.so
تنتج Anchor verifiable builds bytecode حتمية؛ يجب أن تتطابق البصمات تماماً. إذا لم تتطابق، فإن البرنامج المنشور ليس هو البرنامج المدقق — اطلب تصعيد. تنشر Raydium البصمات المتوقعة لكل نشر في قسم الإصدارات في المستودع.

​
كيفية قراءة تقرير التدقيق

دليل قصير لغير المدققين:
  1. انتقل إلى ملخص الأمور — جدول يوضح عدد مستويات الخطورة. إذا كان العدد “حرج” > 0 ورأيت حالة “مفتوح”، فاستكشف.
  2. اقرأ وصف كل أمر وحالته. «تم الإصلاح في commit XYZ» يعني تم حله؛ «معترف به» يعني أن الفريق قبل المخاطرة؛ «تم إصلاح جزئياً» يستحق نظرة أقرب.
  3. امسح قسم النطاق. إذا لم تغطِ عملية التدقيق التعليمات أو الحساب الذي تهتم به، فإن عدم وجود أمور هناك ليس دليلاً على الأمان.
  4. تصفح قسم توصيات المدقق. غالباً ما يكون أكثر فائدة من الأمور — يسلط الضوء على ملاحظات “لم نتمكن من إثبات رسمياً لكننا قلقون”.

​
تكامل برنامج البحث عن الأخطاء

تعمل عمليات التدقيق قبل النشر؛ برامج البحث عن الأخطاء تعمل بشكل مستمر بعد النشر. يغطي برنامج bounty الخاص بـ Raydium (security/disclosure) كل ما تغطيه عمليات التدقيق بالإضافة إلى:
  • الهجمات الاقتصادية التي لا تغطيها عمليات التدقيق.
  • الأخطاء الموجودة في التكاملات الجديدة.
  • أخطاء التنفيذ في SDKs والمكونات خارج السلسلة.
عادة ما يتم دفع اكتشاف whitehat في برنامج البحث عن الأخطاء بشكل أسرع من انتظار دورة التدقيق التالية؛ الحوافز محاذاة للكشف السريع. البرنامج النشط مستضاف على Immunefi: immunefi.com/bug-bounty/raydium/information.

​
الحوادث التاريخية

كانت هناك حادثتان بارزتان في العالم الحقيقي في برامج Raydium:

​
استغلال سلطة التجمع (ديسمبر 2022)

ما: تم اختراق مفتاح خاص لسلطة تجمع AMM v4، مما سمح للمهاجم بتصريف عدة تجمعات. النطاق: إدارة المفاتيح التشغيلية وليس خطأ في البرنامج. لم تكن عملية التدقيق قد أشارت إلى الكود لأن الكود كان صحيحاً؛ كان فشل عملية إدارة المفاتيح. الإصلاح: هجرة Multisig (تم نقل جميع أدوار السلطة إلى Squads multisig)؛ ضوابط تشغيلية إضافية. الدرس: عمليات التدقيق لا تغطي إدارة المفاتيح. انظر security/admin-and-multisig.

​
تجميد تكامل OpenBook (يناير 2023)

ما: تحديث برنامج OpenBook غيّر دلالات الحساب؛ لم تتمكن MonitorStep crank الخاصة بـ AMM v4 من تسوية PnL حتى وصلت إصلاح AMM v4. النطاق: خطأ تكامل — لم يكن أي برنامج خاطئاً في العزلة. الإصلاح: إصلاح AMM v4 والنشر المنسق. الدرس: عمليات تدقيق البرنامج A لا تكتشف الأخطاء في تكامل البرنامج A مع البرنامج B. الأداة الصحيحة هي اختبار التكامل والنشرات المرحلية.

​
مؤشرات

المصادر: