MemChain والتخزين المشفر

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

نظرة عامة

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

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

ينتمي هذا الموضوع إلى Nodeboard. يجب فهم 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-external-witness-v1:start -->

سجل الالتزامات والحماية من التراجع

تحتفظ MemChain بسجل التزامات لا يقبل إلا الإضافة للسجلات المشفرة. تحتوي الكتلة على التزامات سلامة وبيانات ترتيب، ولا تحتوي على نص الذكريات أو مفاتيح فك التشفير. الغرض هو كشف العبث والتراجع؛ وليست سلسلة كتل عامة ولا تدّعي إجماعاً موزعاً أو نهائية أو تنفيذ رموز.

قبل فتح UDP أو TUN أو واجهة API العامة، يتحقق المنسق بالترتيب من نمط المتانة، وسلسلة الالتزامات المحفوظة كاملة، ومرساة القمة المحلية الموقعة، وأدلة نقاط التحقق المحفوظة، ونقاط التحقق الموقعة من العقد الخارجية التي ثبّتها المشغل.

يجب أن تكون الشواهد هويات Ed25519 يثبتها المشغل صراحة. لا تحصل عقدة permissionless على سلطة قرار التشغيل لمجرد ظهورها في peer store.

نشر إنتاجي تم التحقق منه — 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.

يرسل heartbeat نطاق الشواهد وعددها ومتطلب strict فقط، ولا يرسل الهويات أو العناوين أو التجزئات أو التواقيع أو المحتوى المشفر أو المالكين أو العلاقات الاجتماعية.

<!-- 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-external-witness-v1:end --> <!-- signed-commitment-ledger-related-v1:start -->

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

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

<!-- signed-commitment-ledger-related-v1:end --> <!-- memchain-model-provider-boundary-v1:start -->

اختيار العقل وحدود مزود النموذج

تفصل MemChain التخزين الأعمى للعقدة عن المعالجة الإدراكية الاختيارية. تفعيل cognitive worker في SuperNode لا يمنح عقد التخزين أو relay إذناً بقراءة الذاكرة.

ما الذي يمكن لكل مكوّن رؤيته

• عقدة التخزين أو relay ذات مبدأ node-blind ترى ciphertext وblind indexes وبيانات توجيه محدودة وإشارات صحة مجمعة؛ ولا تستقبل الذاكرة كنص صريح افتراضياً.
• يستقبل SuperNode cognitive worker المفعّل فقط task payload الذي يسمح به المستوى structured أو summary أو full.
• يمكن لمزود نموذج خارجي قراءة prompt المرسل إليه كاملاً. لا تستخدم full إلا بموافقة صريحة ومع مزود اختاره المستخدم أو المشغل بوصفه موثوقاً.
• يبقي النموذج المحلي المتوافق مع OpenAI الاستدلال داخل حدود المشغل، لكن worker الذي يشغله يظل مكوّن معالجة موثوقاً وليس عقدة تخزين عمياء.

عزل وقت التشغيل

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

تحمي هذه الحدود توفر العقدة، لكنها لا تجعل الاستدلال الخارجي مشفراً طرفياً. يظل المزود الخارجي قرار ثقة مستقلاً وصريحاً.

<!-- memchain-model-provider-boundary-v1:end -->