اكتشاف العقد والتسليم المشفر القابل للتحقق
كيف تكتشف عقد AeroNyx النظراء الموقّعين، وتختار مساراً متنوعاً من قفزتين، وتمرر ChatRelay المعتم، وتتحقق من التسليم بتوقيع العقدة النهائية.
في 17 يوليو 2026 أرسل اختبار إنتاج حمولة ChatRelay معتمة من عميل موثّق من US1 عبر Korean1 إلى Noway1. خزّنتها العقدة النهائية في pending store وأعادت receipt موقعة تحققت منها عقدة المصدر. هذا دليل محدود لمسار ChatRelay مؤهل، وليس ادعاءً بأن كل حزم AeroNyx تستخدم onion routing.
ثابت البروتوكول: يُمنع أن تتلقى بنية relay نصاً صريحاً أو مفاتيح فك التشفير. ترى العقدة الوسطى route metadata محدودة وproof وTTL وnext hop وciphertext معتماً فقط، وتتلقى العقدة النهائية أقل metadata لازمة لـ store-and-forward مع ciphertext.
ما يعمل حالياً
تعمل حالياً peer descriptors موقعة وpeer store دائم وgossip واختبارات الوصول وتفضيل المسار الداعم للـ receipt وجلسات عميل موثقة وterminal pending store وإيصالات تسليم موقعة.
مسار التسليم الموثق
- ينشئ العميل session باستخدام Ed25519 وX25519 مؤقت، ويرسل
ChatRelayداخلDataPacketمشفر. تربط عقدة المصدر sender بهوية session وتختار middle وterminal متنوعين. لا يُحتسب التسليم إلا بعد التحقق من receipt مرتبطة بالمسار وpayload commitment الدقيق والterminal المتوقع وfreshness.
authenticated client -> source -> middle -> terminal pending store
<- terminal-signed receipt <-
ترتبط receipt النهائية بمعرف route ID وبـ payload commitment الدقيق وهوية terminal المتوقعة ونافذة freshness. وتُرفض أي receipt غير مطابقة أو قديمة.
مستويات الدليل
تُفصل ثلاثة مستويات حتى لا يُعرض فحص الصحة كتسليم حقيقي:
| رمز الدليل | المعنى |
|---|---|
synthetic_onion_message_delivery_probe | اختبار مسار مضبوط، وليس حركة مستخدم حقيقية. |
opaque_relay_acceptance | قبول عمل relay مشفر ومحايد المصدر؛ لا يثبت terminal delivery. |
verified_client_onion_delivery_receipt | وصل payload الموثق إلى terminal المتوقع وتحققت source من receipt الموقعة. |
تنوع المسار
يجب أن تكون source وmiddle وterminal عقداً مختلفة. يُرفض تطابق IPv4 /24 أو IPv6 /48 أو DNS host الموحّد، وتفشل endpoints غير الصالحة بشكل مغلق. تنوع ASN أو ملكية المشغل لم يُنفذ بعد.
التوافق بين الإصدارات
تُفضّل المسارات الداعمة للـ receipt. يمكن استخدام peers أقدم كخيار محدود، لكن من دون receipt صحيحة لا تزداد verified_client_onion_deliveries ولا يُعرض التسليم كموثّق.
عقد API العام
تتوفر بطاقة العقدة عبر GET http://<node>:8422/api/discovery/public-card، والتجميع الآمن للخصوصية عبر GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/. يبقى المسار القديم vpn للتوافق فقط؛ والمنتج هو AeroNyx Privacy Protocol.
{
"real_relay_ready": true,
"verified_client_onion_deliveries": 1,
"verified_client_onion_delivery_age_seconds": 42,
"message_delivery_proof_ready": true,
"message_delivery_ready": true,
"message_delivery_evidence_mode": "verified_client_onion_delivery_receipt"
}
حدود الخصوصية
تعرض API العامة readiness والعدادات وعمر الدليل بشكل مجمع فقط، ولا تعرض route IDs أو endpoints أو keys أو payloads أو عناوين العملاء أو الوجهات أو DNS أو social graph. النظام أعمى للمحتوى لكنه لم يثبت بعد مقاومة التحليل العالمي أو إخفاء بمستوى Tor.
القيود الحالية
- يشمل التحقق
ChatRelayالموثق والمؤهل بقفزتين فقط، لا كل الحزم أو الصوت أو media. العدادverified_client_onion_deliveriesإشارة process-local تُصفّر عند restart، وليس مجموعاً تاريخياً أو إجماعاً عالمياً.
صياغة واجهة المنتج
يُعرض verified_client_onion_delivery_receipt فقط كـ Verified client delivery، وopaque_relay_acceptance كـ Encrypted relay active، وsynthetic_onion_message_delivery_probe كـ Path probe passed. يجب عدم دمج الحالات.