آكسيوم: بروتوكول اتصال لامركزي ومقاوم للرقابة

🚀 تفاصيل النشر المباشر

• الشبكة: Arbitrum One (Mainnet L2)
• معرف السلسلة: 42161
• نقطة نهاية RPC: https://arb1.arbitrum.io/rpc (أو أي نقطة نهاية مخصصة من Alchemy/Infura)
• عنوان عقد وكيل آكسيوم: 0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63

(ملاحظة: يستخدم آكسيوم بنية وكيل قابل للترقية UUPS. يجب دائمًا توجيه جميع تفاعلات العميل إلى عنوان الوكيل هذا، وليس إلى عقد التنفيذ الأساسي).

📖 كيفية قراءة البيانات (المفهرس / العملاء)

يجب على العملاء أبدًا محاولة قراءة منشورات البروتوكول مباشرة من متغيرات حالة العقد الذكي (نظرًا لأن الحفاظ على الغاز هو أولوية، لا يتم تخزين المحتوى في الحالة). بدلاً من ذلك، يجب على العملاء فهرسة أحداث البلوكشين.

✍️ كيفية نشر البيانات (إرسال المعاملة من العميل)

لنشر البيانات إلى البروتوكول، يجب على العملاء تقديم معاملة على السلسلة تستدعي دالة publishAxiom على عقد الوكيل.

---

هدف آكسيوم هو توفير منصة تواصل اجتماعي مجهولة بالكامل، لامركزية، ومقاومة للرقابة.

لجعل ذلك ممكنًا، تنقسم البنية بشكل صارم: الأساس (البروتوكول) والعملاء (البرمجيات). يحدد هذا المستودع هذا الأساس — عقد ذكي وهيكل بيانات موحد على شبكة طبقة ثانية من إيثريوم.

نطاق المشروع

يؤسس البروتوكول أساس المنصة:

• اتفاقية التسمية القياسية: هيكل واضح يحدد كيف يتم إرسال الحمولات إلى العقد الذكي وكيف يقرأها العملاء.
• الثبات: تعمل البلوكشين كقاعدة بيانات مقاومة للتلاعب وآمنة.
• التركيز على التدوين المصغر: البروتوكول غير مصمم لكميات كبيرة من البيانات على السلسلة، بل يتبع مفهوم التدوين المصغر التقليدي (منشورات قصيرة). لا يتم تخزين ملفات الوسائط بشكل أصلي على السلسلة؛ بدلاً من ذلك، يتم تضمينها عبر روابط خارجية عند الحاجة.
• الحماية من البريد العشوائي: رسوم المعاملات ورسوم دخول منخفضة لمرة واحدة لأول منشور للمحفظة تمنع هجمات تضخم الحالة بواسطة شبكات البوتات.
• التوجيه الأمني: يفرض البروتوكول فصل OPSEC للرسائل بناءً على متطلبات أمنية محددة.

---

مستويات الأمان في البروتوكول

صمم آكسيوم لتمكين حرية التعبير الحقيقية للمستخدمين في البلدان التي يكون فيها الاتصال مقيدًا. يميز البروتوكول بين ثلاثة مستويات أمان. يفترض أن المستخدمين يعرفون مستوى الأمان المناسب لحالتهم الخاصة.

• المستوى 1: مفتوح يتم الاتصال علنيًا بنص عادي على البلوكشين. يمكن لجميع العملاء قراءة ومعالجة كل حركة المرور. يُسمح بتضمين الروابط (مثل الصور عبر موفري طرف ثالث) في هذا المستوى. التوقع هو أن التواصل القياسي لوسائل التواصل الاجتماعي يحدث هنا—بما في ذلك صور القطط المضحكة. هذا يولد ضوضاء مهمة داخل الشبكة. إنه أقل أمانًا فيما يتعلق بتتبع IP الخالص، لكن المنشورات تظل غير قابلة للرقابة تمامًا.
• المستوى 2: مغلق هذا المستوى مخصص للأمان الصارم. يدعم حصريًا رسائل النص العادي. يمنع البروتوكول روابط الوسائط هنا لاستبعاد أي تسريبات IP عند تحميل العملاء للمحتوى الخارجي تقنيًا. يجب على المستخدمين ضمان الحصول على العملة المشفرة المستخدمة لرسوم الغاز بشكل مجهول بأنفسهم.
• المستوى 3: مشفر مبني لأقصى درجات الخصوصية. يتم تشفير الرسائل نفسها باستخدام AES-256-GCM قبل إرسالها. يتم تخزين البيانات الوصفية فقط، ومتجه التهيئة (IV)، والنص المشفر على البلوكشين. فقط عملاء المستخدمين الذين يمتلكون المفتاح التشفيري الصحيح يمكنهم فك تشفير وقراءة هذه الرسائل.

أمان الشبكة وتتبع IP (قاعدة صارمة)

لجميع المستويات، يعد التوجيه البصلي (مثل Tor) إلزاميًا بشكل صارم. يؤدي التواصل مع مزودي RPC التجاريين (مثل Infura أو Alchemy) إلى تسريب عنوان IP للمرسل بنص عادي. لسد ثغرات OPSEC التي قد تهدد حياة المنشقين، يُطلب من العملاء توجيه المعاملات إلى عقد RPC حصريًا عبر شبكة Tor.

---

معايير التشفير (للمستوى 3)

بالنسبة للرسائل في المستوى 3، يجب على جميع العملاء الالتزام الصارم بمعايير التشفير التالية لضمان قابلية التشغيل البيني وتجنب المساس بالأمان.

1. خوارزمية التشفير: AES-256-GCM يجب تشفير جميع حمولات المستوى 3 بشكل متماثل باستخدام AES في وضع GCM بطول مفتاح 256 بت. يجب إعادة إنشاء متجه التهيئة (IV/Nonce) بشكل عشوائي لكل رسالة على حدة ويُكتب على البلوكشين كبيانات وصفية بنص عادي. هذا يمنع التعرف على الأنماط من قبل المراقبين الخارجيين.
2. اشتقاق المفتاح: Argon2id يقوم المستخدمون بإدخال كلمات مرور قابلة للقراءة البشرية في عملائهم. يجب أبدًا استخدام هذه مباشرة كمفاتيح AES. يُطلب من العملاء بشكل صارم استخدام خوارزمية التجزئة Argon2id. (ملاحظة: يجب على المطورين تعريف معاملات ثابتة للتكرارات واستخدام الذاكرة داخل العميل بحيث يولد الجميع نفس المفتاح تمامًا).
3. تبادل المفاتيح: خارج النطاق لا يتعامل آكسيوم مع تبادل المفاتيح على السلسلة. لا يخزن البروتوكول مفاتيح عامة. تبادل كلمة المرور (السر المشترك) لقناة معينة هو مسؤولية المستخدمين ويجب أن يحدث خارج الشبكة (مثل وجهًا لوجه).
4. سلامة البيانات يولد AES-GCM علامة مصادقة. يجب على العملاء التحقق من صحة هذه العلامة. إذا فشل التحقق، يجب على العميل تجاهل الرسالة بصمت (إسقاط).

---

هيكل البيانات، تسليم الحمولة، والفهرسة

يستخدم آكسيوم تسليم حمولة هجين (تقسيم ABI). لمنع العقد الذكي من الاضطرار إلى فك تنسيقات البيانات المكلفة، يتم فصل البيانات قبل الإرسال:

1. متغيرات المنطق: يتم تمرير المستوى (uint8 _level) ومتجه التهيئة (bytes _iv) كمعاملات مباشرة إلى العقد الذكي، لأنه يحتاجها لفرض قواعده الأمنية.
2. البيانات المعتمة: يتم بناء محتوى الرسالة الفعلي داخليًا بواسطة العميل كـ JSON وضغطه إلى CBOR (تمثيل الكائن الثنائي المختصر). يتعامل العقد مع حزمة CBOR هذه "بشكل أعمى" ويوجهها مباشرة إلى سجل الأحداث.

مفاتيح الحمولة (هيكل CBOR)

يستخدم آكسيوم أحرفًا مفردة كمفاتيح لتوفير البايتات. يتم حذف المؤلف (msg.sender) والطابع الزمني (block.timestamp)، حيث يستخرج العقد الذكي هذه القيم بطريقة مقاومة للتلاعب على أي حال.

• t (النوع): عدد صحيح. نوع الإجراء.
• c (المحتوى): سلسلة/بايتات. النص أو الاسم أو النص المشفر.
• h (الوسوم/العلامات): مصفوفة. اختياري. يُستخدم للتصنيف (قنوات فرعية).
• m (تلميح الرسالة): بايتات (طول 2). للمستوى 3 فقط. تجزئة HMAC بطول 2 بايت تُستخدم للتجميع التقريبي.
• r (الرد على): بايتات. اختياري. تجزئة المعاملة لمنشور مشار إليه.

أنواع الإجراءات (حقل t)

• 0 = تحديث الملف الشخصي (يربط عنوان المحفظة باسم قابل للقراءة في الحقل c)
• 1 = منشور (رسالة قياسية)
• 2 = رد (r يتطلب تجزئة المنشور الأصلي)
• 3 = إعجاب (r يتطلب تجزئة المنشور)
• 4 = إلغاء الإعجاب (يلغي النوع 3)
• 5 = إعادة تغريد / إعادة نشر (r يتطلب تجزئة المنشور)
• 6 = إلغاء إعادة التغريد (يلغي النوع 5)

القنوات الفرعية والتوجيه المظلم (حقل h)

• المستوى 1 و 2: تُمرر الوسوم بنص عادي.
• المستوى 3 (مشفر): يُمنع منعًا باتًا تمرير الوسوم بنص عادي على مستوى البروتوكول، لأن هذا يسرب البيانات الوصفية. يجب تشفير الوسوم تمامًا مثل المحتوى (c). بالنسبة للمراقبين الخارجيين، تكون الوسوم غير مرئية تمامًا (توجيه مظلم).

المستوى 3: التجميع التقريبي (حقل m)

نظرًا لأن الوسوم مشفرة في المستوى 3، يجب على العملاء من الناحية النظرية محاولة فك تشفير كل رسالة على حدة (فك تشفير تجريبي). لمنع زيادة تحميل وحدة المعالجة المركزية، يستخدم آكسيوم تلميحات الرسالة:

• يحسب المرسل HMAC-SHA256(AES_Key, IV) ويضع أول 2 بايت كحقل m في حمولة CBOR.
• يحسب المستقبلون هذا التلميح لكلمات المرور المخزنة محليًا. يتم تنفيذ عملية فك التشفير المكلفة فقط في حالة وجود تطابق. هذا يرشح 99.99% من حركة المرور غير ذات الصلة دون تسريب بيانات وصفية.

---

الهوية: الملفات الشخصية العالمية مقابل الأسماء المستعارة الخاصة

يتعامل آكسيوم مع الهوية بشفافية كاملة: عنوان محفظة L2 (msg.sender) هو الهوية الاجتماعية والمالية الوحيدة. ينقل البروتوكول مسؤولية OPSEC المالية بالكامل إلى المستخدم (مثل استخدام الخلاطات والجسور لشراء رموز الغاز بشكل مجهول).

يتصرف إجراء تحديث الملف الشخصي (t: 0) بشكل مختلف اعتمادًا على مستوى الأمان المختار:

1. الهوية العالمية (المستوى 1 و 2) إذا أرسلت محفظة تحديثًا غير مشفر للملف الشخصي، فإنه يعمل كإعلان عالمي. تصبح المحفظة معروفة على نطاق الشبكة بهذا الاسم. يرى الجميع هذا الاسم (مثل بناء سمعة عامة كـ @Dissident99).
2. الأسماء المستعارة الخاصة والألقاب (المستوى 3) إذا أرسلت محفظة تحديث ملف شخصي ضمن حمولة مشفرة من المستوى 3، فإنه ينشئ اسمًا مستعارًا خاصًا ومعزولًا. هذا الاسم المستعار يكون مرئيًا فقط داخل القناة الفرعية المفككة تشفيرها للمستخدمين الذين يعرفون كلمة المرور. هذا يسمح بتوزيع أدوار بأسماء مستعارة في مجموعات مغلقة دون تغيير الهوية العالمية. أولوية العرض: بالنسبة للمستوى 3، يجب على الواجهة الأمامية دائمًا التحقق من وجود اسم مستعار محلي قبل الرجوع إلى الاسم العالمي.

---