AeroNyx

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

AeroNyx18 يونيو 20267 دقيقة قراءة51 مشاهدة

تشغيل عقد 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.

<!-- memchain-witness-operations-v1:start -->

تشغيل الشواهد المثبتة

الشواهد المثبتة هي سياسة ثقة صريحة يحددها مشغل منسق التزامات MemChain. يجب إعداد عقد follower مستقلة ومدققة ومخصصة لحفظ سجل المنسق فقط.

toml
[memchain]
commitment_coordinator_enabled = true
commitment_witness_node_ids = ["<64-hex-ed25519-node-id-1>", "<64-hex-ed25519-node-id-2>"]
commitment_witness_startup_required = false
commitment_witness_min_verified = 2

استبدل جميع القيم المؤقتة قبل التحقق. يُسمح بثلاث هويات Ed25519 فريدة وغير صفرية بطول 32 بايت كحد أقصى، ولا تصلح هذه الإعدادات إلا على المنسق.

النشر الآمن: حدّث عقدتي follower مدققتين على الأقل؛ أضف هوياتهما الدقيقة مع تعطيل strict؛ نفّذ aeronyx-server validate -c /etc/aeronyx/server.toml؛ أعد التشغيل وتحقق من قبول الدليل الموقع ضمن operator_pinned؛ فعّل strict فقط بعد تكرار الاختبار.

عند تعطيل strict، يؤدي تعذر الوصول إلى witness إلى تحذير degraded واضح مع الحفاظ على التوافر. نتيجة remote-ahead أو divergence الموقعة تمنع التشغيل دائماً. ومع strict، يمنع غياب أي دليل متحقق التشغيل أيضاً.

Checkpoint هي واجهة بروتوكول موقعة؛ طلب GET مجهول ليس health check. تحسن الشواهد كشف rollback، لكنها لا تنشئ بمفردها إجماعاً أو quorum أو finality.

نشر إنتاجي تم التحقق منه — 14 يوليو 2026

يستخدم منسق إنتاج واحد ثلاث هويات witness مثبتة صراحةً من المشغل. تعمل الآن عقدتا follower مستقلتان ومدققتان بخدمة checkpoint متوافقة؛ وقد تحققت كل منهما من السجل نفسه المؤلف من 33 block و8,339 commitment وخزنته. قبل المنسق استجابتين منفصلتين وموقعتين من نوع converged من العقدتين، ثم فعّل commitment_witness_startup_required = true.

عند إعادة التشغيل المتحقق منها، سجل startup guard القيم configured=3 وeligible=3 وattempted=3 وverified=2 وconverged=2؛ ولم تُفتح منافذ UDP وTUN إلا بعد نجاح الفحص. هذا دليل rollback من عقد يثبتها المشغل، وليس consensus أو quorum أو finality لسلسلة عامة أو token execution.

<!-- witness-threshold-enforced-v1:start -->

فرض حد تشغيل 2-of-3 — 14 يوليو 2026

يضبط منسق الإنتاج الآن commitment_witness_min_verified = 2 مع commitment_witness_startup_required = true. يتوقف التشغيل عندما يقدم أقل من شاهدين مثبتين ومختلفين دليلاً موقعاً صالحاً: عدم وجود استجابة صالحة ينتج signed_checkpoint_unavailable، واستجابة واحدة تنتج signed_checkpoint_threshold_unmet. تحقق آخر تشغيل إنتاجي من شاهدين من أصل ثلاثة قبل فتح UDP أو TUN أو مستمع API العام.

هذا حد تشغيل يحدده المشغل، وليس consensus للشبكة أو quorum أو finality أو انتخاب قائد أو fork choice. يرسل Rust heartbeat حقول السياسة والنتيجة المجمعة فقط، ومنها startup_minimum_verified، من دون كشف هويات الشهود أو العناوين أو تجزئات checkpoint أو التواقيع.

<!-- witness-threshold-enforced-v1:end --> <!-- memchain-witness-operations-v1:end --> <!-- 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 /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain
النتيجةإجراء المشغل
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 /root/open/AeroNyx
./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 وبيانات البروتوكول في /var/lib/aeronyx والهوية/الإعداد في /etc/aeronyx و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://127.0.0.1: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 /etc/aeronyx/server.toml. هذا السلوك موجود في main الحالي؛ ويجب إعادة بناء العقدة المثبتة أو ترقيتها إلى إصدار يتضمنه.

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

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