AeroNyx

تشغيل عقد الخصوصية اللامركزية وفحوصات الصحة

AeroNyx18 يونيو 20265 دقيقة قراءة115 مشاهدة

تشغيل عقد AeroNyx: الصحة والاكتشاف وblind relay والتعافي بعد إعادة التشغيل والسعة وpacket runtime وإثبات القفزتين والصيانة الآمنة لذاكرة Cargo المؤقتة.

«تشغيل عقد الخصوصية اللامركزية للخصوصية وفحوصات الصحة» صفحة عربية رسمية ضمن وثائق AeroNyx. تفصل AeroNyx بين طبقة البروتوكول وتجربة المنتج: البروتوكول يقدم قدرات مفتوحة ومرنة، بينما App و Nodeboard والدردشة المشفرة والتخزين المشفر وتشغيل العقد تشكل تجربة الاستخدام.

نظرة عامة

تشرح هذه الصفحة بالعربية دور «تشغيل عقد الخصوصية اللامركزية للخصوصية وفحوصات الصحة» داخل بروتوكول الخصوصية المفتوح AeroNyx، ونطاق التنفيذ الحالي، وثوابت الخصوصية، وملاحظات التطوير والتشغيل.

الدور داخل بنية AeroNyx

ينتمي هذا الموضوع إلى مشغلو العقد. يجب فهم AeroNyx كقدرات بروتوكول مشتركة بين العملاء وعقد الخصوصية اللامركزية ومنسقي backend و Nodeboard، وليس كخدمة مركزية واحدة.

نقاط التنفيذ الحالية

  • كل قدرة تتعلق بمحتوى المستخدم يجب أن تمر كتشفير طرفي أو كائن مشفر.
  • يمكن لعقد الخصوصية اللامركزية الإبلاغ عن الصحة والسعة والاتصالات وإثباتات المسار والإحصاءات المجمعة، لكنها لا تقرأ الرسائل أو بيانات الاعتماد أو أسرار المستخدم.
  • يوفر Nodeboard رؤية تشغيلية: صحة العقدة، peer discovery، التعافي بعد إعادة التشغيل، السعة، الحزم/المرور، وحالة البروتوكول.
  • في المرحلة الحالية ينسق backend ويرتب ويجمع ويفتح واجهات وثائق عامة؛ ويمكن نقل بعض المسؤوليات لاحقاً إلى طبقة Rust.

حدود الخصوصية

الثابت الأساسي في AeroNyx هو blind-node invariant: عقد relay ومنسقو MemChain يتعاملون فقط مع ciphertext والطوابع الزمنية والإثباتات وإشارات الصحة المجمعة وبيانات توجيه محدودة. لا ينبغي لهم قراءة النص الصريح أو DNS أو الوجهات أو إعادة بناء علاقات التواصل.

ما الذي يجب أن يراقبه مشغلو العقد

على المشغلين متابعة النطاق الترددي وحدود الاتصال ومجموعة IP و conntrack وواصفات الملفات و packet drops و pps و bps و peer store وحداثة heartbeat و restart recovery. يجب أن تساعد الواجهة في التشخيص دون كشف محتوى المستخدم أو بيانات قابلة للربط.

تكامل المطورين والمنتجات

يجب على العملاء و App و AI agents والخدمات الخارجية إعادة استخدام envelope المشفر والتوقيعات و blind relay وبيانات الاعتماد المجهولة و healthchecks الخاصة بـ AeroNyx. أي API جديد يجب أن يوضح ما هو metadata عام وما يجب أن يبقى داخل E2E payload.

الحالة الحالية

تصف هذه الصفحة الحدود العامة الحالية لبروتوكول ومنتج AeroNyx. يجب تحديث multi-hop routing و blind-signed vouchers و encrypted media blob ومزامنة MemChain وتحسين node discovery تحت نفس translation_key.

<!-- signed-commitment-ledger-related-v1:start -->

مواصفة البروتوكول ذات الصلة

دفتر التزامات موقّع وحماية بالشهود

<!-- signed-commitment-ledger-related-v1:end --> <!-- aof-semantic-integrity-v1:start -->

فحص سلامة MemChain AOF

أضف هذا الحاجز المخصص للقراءة إلى كل ترقية وإعادة تشغيل مخططة. مخرجاته المجمعة آمنة للأتمتة التشغيلية.

bash
sudo aeronyx-server memchain verify-aof \
  --config <node-config>

sudo aeronyx-server memchain verify-aof \
  --path <node-state>
النتيجةإجراء المشغل
status: verified و torn_tail_bytes: 0تابع التحقق من الإعداد وإعادة التشغيل المحمية.
torn_tail_detectedلا تعدل الملف يدوياً. وحده guarded append-open يزيل الذيل غير المكتمل بعد فحص دلالي كامل.
خطأ سلامةتوقف واحفظ AOF والسجلات للمراجعة؛ تلف سجل كامل يفشل بشكل مغلق.

الخصوصية: لا ترفع ملف AOF نفسه ولا تلصقه أو تنشره. شارك فقط مخرجات الفاحص المجمعة.

الحد الكامل للسلامة والإثبات: دفتر التزامات موقّع وحماية بالشهود.

<!-- aof-semantic-integrity-v1:end --> <!-- build-cache-maintenance-v1:start -->

صيانة محكومة لذاكرة بناء Cargo المؤقتة

قد تترك عمليات البناء المتكررة عشرات الجيجابايت من كائنات Cargo القابلة لإعادة الإنشاء. يفحص الأمر الموحد المساحة ويستعيدها من دون حذف حالة البروتوكول أو إعادة تشغيل الخدمة.

1. الجرد من دون تغيير المضيف

شغّل أولاً الجرد للقراءة فقط. يعرض target القديم وbuild root المعزول وإصدار Rust المثبت وSHA-256 للملف التنفيذي المحمي وسعة نظام الملفات المجمعة.

bash
cd <node-repository>
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. معاينة كل عنصر قابل للحذف

راجع dry-run سطراً بسطر. يتطلب الحذف root و--yes صريحاً؛ ولا يبدأ status أو upgrade تنظيفاً ضمنياً.

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --dry-run

3. تشغيل التنظيف المؤكد

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --yes

عند استخدام build root مخصص، صدّر AERONYX_BUILD_TARGET_ROOT في الأوامر الثلاثة كي يستخدم الجرد والتنظيف target المعزول نفسه.

النطاق المحمي والقابل للحذف

  • محمي: يحافظ على target/release/aeronyx-server وcache الحالي للـ toolchain/service وبقية ملفات release وrollback وبيانات البروتوكول في <node-state> والهوية/الإعداد في <node-config-directory> وcache الخدمات الأخرى.
  • قابل لإعادة الإنشاء: يحذف فقط مخرجات Cargo القابلة لإعادة البناء: مجلدات debug/cross-target القديمة وdeps وbuild و.fingerprint وincremental و.rlib و.rmeta و.d وtargets القديمة للخدمة نفسها.
  • حماية التنفيذ: قبل الحذف يأخذ deployment lock المشترك مع install/upgrade ويتحقق من أن MainPID يشغّل الملف المحمي. يحسب hash قبل التنظيف وبعده ويفشل إذا تغير.

التحقق بعد الصيانة

لا تعيد الصيانة تشغيل العقدة ولا تتطلب تفريغ الجلسات النشطة. بعدها تحقق من service health وstartup readiness وdiscovery quorum وحداثة إثبات القفزتين.

bash
./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

دليل التحقق في الإنتاج — 26 يوليو 2026

استعاد تشغيل محكوم 50,649,768 KiB وانخفض الاستخدام من 90% إلى 65%. بقي SHA-256 وMainPID وعدد إعادة التشغيل ثابتاً؛ وظل startup بلا أخطاء وإثبات القفزتين ready/stable.

حدود الخصوصية: يعرض الجرد المسارات والأحجام وإصدار toolchain وhash الملف التنفيذي والسعة المجمعة فقط. لا يقرأ payload مشفراً أو سجلات MemChain أو المفاتيح أو هويات peers أو routes أو عناوين العملاء أو DNS أو الوجهات أو social graph.

<!-- build-cache-maintenance-v1:end --> <!-- memchain-llm-provider-operations-v1:start -->

تشغيل cognitive worker الاختياري

إن SuperNode cognitive worker اختياري ومعطل افتراضياً. فعّله فقط على عقدة معالجة ذات دور ثقة مفهوم.

أدنى إعداد لمزود محلي

toml
[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://localhost:11434/v1"
api_key = ""
model = "llama3.2"
max_tokens = 1000
temperature = 0.3

[memchain.supernode.routing]
fallback = "local-ollama"

[memchain.supernode.privacy]
default_level = "structured"
allow_full_for = []

يُدعم أيضاً api_key = "$ENV_VAR". لا تضع الأسرار في إعدادات محفوظة ضمن المستودع.

صيغ endpoint المتوافقة مع OpenAI

تصل الصيغ الثلاث إلى endpoint نفسه لـ Chat Completions:

  • https://provider.example
  • https://provider.example/v1
  • https://provider.example/v1/chat/completions

عند type = "anthropic" يمكن حذف api_base؛ يستخدم runtime الحالي endpoint الرسمي لـ Anthropic Messages.

الأعطال وحدود الموارد

  • يُحدّ الرد الناجح إلى 8 MiB قبل تحليل JSON، ويُحدّ نص تشخيص الخطأ إلى 64 KiB.
  • أخطاء النقل أو API أو التحليل أو الرد الفارغ تضع المزود في cooldown مدته 30 ثانية وفق ساعة رتيبة بدلاً من تعطيله نهائياً.
  • يُحترم HTTP 429 Retry-After ضمن 1-300 ثانية، وتُستخدم 30 ثانية عند غيابه.
  • يمكن للـ router استخدام مزود سليم آخر، ثم يعيد النظر تلقائياً في المزود المتعطل بعد انتهاء cooldown من دون مهمة مجدولة.

قبل إعادة التشغيل نفّذ aeronyx-server validate -c <node-config>. هذا السلوك موجود في main الحالي؛ ويجب إعادة بناء العقدة المثبتة أو ترقيتها إلى إصدار يتضمنه.

حد الخصوصية: تبقى عقد التخزين وrelay ذات مبدأ node-blind. يرى cognitive worker المفعّل وأي مزود خارجي prompt الذي يسمح به مستوى الخصوصية. أبقِ default_level = "structured" واترك allow_full_for فارغاً دون موافقة صريحة على معالجة المحتوى الكامل.

<!-- memchain-llm-provider-operations-v1:end -->