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

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

• الشبكة: 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، يجب على الواجهة الأمامية دائمًا التحقق من وجود اسم مستعار محلي قبل الرجوع إلى الاسم العالمي.

هندسة العقد الذكي وإنفاذات OPSEC

يعتمد آكسيوم على التحقق على السلسلة بتعقيد O(1). للحفاظ على تكاليف الغاز في أدنى حد مطلق، يقوم العقد الذكي فقط بإجراء فحوصات تشفير أساسية. يتم تفريغ جميع عمليات التحقق من المحتوى كثيفة الاستخدام للموارد إلى العملاء (الطبقة 2).

1. التحقق على السلسلة (العقد الذكي)

يعمل العقد كحارس غير قابل للفساد. إذا لم تلتزم الحمولة بالقواعد الصارمة، يتم إلغاء المعاملة.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract Axiom is Initializable, UUPSUpgradeable, OwnableUpgradeable {
    uint256 public entryFee;
    mapping(address => uint8) public walletPath; // 0=New, 1=PathA(Level1), 2=PathB(Level2/3)

    event AxiomPost(address indexed sender, uint8 level, bytes iv, bytes cbor, uint256 timestamp);

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize() initializer public {
        __Ownable_init(msg.sender);
        entryFee = 0.0001 ether;
    }

    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}

    function publishAxiom(
        uint8 _level,
        bytes calldata _iv,
        bytes calldata _cbor
    ) external payable {
        require(_level >= 1 && _level <= 3, "Invalid level");

        uint8 requiredPath = (_level == 1) ? 1 : 2;
        uint8 currentPath = walletPath[msg.sender];

        if (currentPath == 0) {
            require(msg.value >= entryFee, "Anti-Sybil: Insufficient entry fee");
            walletPath[msg.sender] = requiredPath;
        } else {
            require(msg.value == 0, "Fee already paid");
            require(currentPath == requiredPath, "OPSEC Violation: Wallet is tainted");
        }

        if (_level == 3) {
            require(_iv.length == 12, "Level 3 strictly requires a 12-byte IV");
        } else {
            require(_iv.length == 0, "Level 1 and 2 require strictly empty IV");
        }

        emit AxiomPost(msg.sender, _level, _iv, _cbor, block.timestamp);
    }

    function withdraw() external onlyOwner {
        payable(owner()).transfer(address(this).balance);
    }
}

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

2. التحقق خارج السلسلة (بواسطة العملاء)

إذا انتهك منشور قواعد البروتوكول، يجب على العميل تجاهله بصمت (إسقاط محلي).

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

البنية التحتية وهندسة العميل الموصى بها

تم نشر آكسيوم على شبكة طبقة ثانية من إيثريوم (L2) (مثل Arbitrum Nova).

لتجنب زيادة تحميل الأجهزة المحمولة (عمر البطارية، قيود التخزين، حدود WebAssembly لـ Argon2id)، يفرض آكسيوم بنية عميل عالية الأداء:

• نواة آكسيوم (عقدة مستضافة ذاتيًا): خادم/حاوية Docker (مثل التشغيل على NAS) تقرأ البلوكشين عبر RPC، وتفهرس الأحداث، وتنفذ التشفير كثيف الموارد بشكل أصلي.
• واجهة مستخدم آكسيوم (عميل رقيق): تطبيق جوال أو واجهة ويب تتواصل فقط مع نواة آكسيوم الخاصة بالمستخدم عبر API.

استرجاع البيانات و EIP-4444

لا يقوم العملاء بتنزيل حالة البلوكشين بأكملها. يقومون بتصفية حدث AxiomPost الخاص بالعقد الذكي، والذي يحتوي على جميع البيانات الضرورية بنص عادي (المرسل، المستوى، IV، CBOR، الطابع الزمني).

نظرًا لأن عقد إيثريوم ستتخلص في النهاية من البيانات التاريخية (الأحداث الأقدم من 365 يومًا) وفقًا لـ EIP-4444، يوصي البروتوكول بأن تعمل نوى آكسيوم المحلية كأرشيفات لا مركزية، مخزنة قواعد البيانات بشكل دائم.

مثال سير العمل: منشور من المستوى 3

لتوضيح كيفية عمل البنية في الممارسة العملية، إليك استعراض كامل لدورة الحياة.

السيناريو: تريد أليس نشر الرسالة "Meeting at 8 PM" في القناة الفرعية "AxiomDev". وافقت المجموعة مسبقًا خارج الإنترنت على كلمة المرور "Secret123".

الخطوة 1: التحضير المحلي والتشفير (نواة آكسيوم)

تتعامل نواة آكسيوم الخاصة بأليس مع المهام الحسابية الثقيلة:

1. اشتقاق المفتاح: تقوم بتحويل كلمة المرور إلى مفتاح AES بطول 256 بت باستخدام Argon2id.
2. توليد IV: يتم إنشاء متجه تهيئة عشوائي بطول 12 بايت (مثل 0x12ab34cd56ef789012ab34cd).
3. التشفير: يتم تشفير المحتوى والوسم ("AxiomDev") باستخدام AES-GCM.
4. توليد التلميح: يتم حساب تجزئة HMAC بطول 2 بايت للتجميع التقريبي (m: "0xa1b2").

الخطوة 2: بناء الحمولة (تسلسل CBOR)

نظرًا لأن المستوى و IV يتم تمريرهما مباشرة إلى العقد، يتم استبعادهما من كائن CBOR.

التمثيل الداخلي لـ JSON:

{
  "t": 1,
  "c": "0x8a4f...",
  "h": ["0x9b5e..."],
  "m": "0xa1b2"
}

يتم ضغط هذا JSON إلى مصفوفة بايت CBOR خام (0xa3617401...) لتوفير الغاز.

الخطوة 3: استدعاء العقد الذكي (تفاعل البلوكشين)

تقوم أليس باستدعاء دالة العقد. مهم: يتم توجيه الاستدعاء بشكل صارم عبر Tor!

(أمثلة لـ L3 و L1:)

// Example 1: Client calling the Smart Contract for an encrypted Level 3 post
await axiomContract.publishAxiom(
    3,                                      // _level: 3
    "0x12ab34cd56ef789012ab34cd",           // _iv: 12 bytes hex string required
    "0xa3617401616358208a4f..."             // _cbor: packed CBOR hex string
);

// Example 2: Client calling the Smart Contract for a public Level 1 post
await axiomContract.publishAxiom(
    1,                                      // _level: 1
    "0x",                                   // _iv: strictly empty byte array
    "0xa361740161634c48656c6c6f204178..."   // _cbor: packed CBOR hex string
);

يقوم العقد الذكي بعد ذلك بإصدار الحدث:

Event: AxiomPost(Sender: 0xAlice..., Level: 3, IV: 0x12ab..., CBOR: 0xa361..., Timestamp: 1710425890)

الخطوة 4: الفهرسة وفك التشفير التجريبي (المستقبل)

نواة آكسيوم الخاصة بوب تستمع إلى البلوكشين وتستقبل الحدث.

1. التخزين المحلي والتعرف: يتم كتابة الحدث في قاعدة البيانات المحلية. تكتشف النواة Level 3 وتفك حزمة CBOR للوصول إلى المحتوى والوسوم والتلميح m.
2. فك التشفير التجريبي: تتحقق النواة من التلميح m بطول 2 بايت مقابل كلمات مرور بوب المخزنة.
3. التطابق والإعادة التوجيه: يطابق التلميح "Secret123". تؤكد علامة GCM أن الحمولة لم يتم التلاعب بها. يتم فك تشفير البيانات في ذاكرة الوصول العشوائي وإرسالها إلى هاتف بوب الذكي عبر API المحلي. تظهر الرسالة "Meeting at 8 PM" في خلاصة "#AxiomDev".
4. التراكم غير المعروف: بالنسبة للمستخدمين الذين ليس لديهم كلمة المرور الصحيحة، يفشل فحص التلميح. يتم حذف ضوضاء البيانات غير القابلة للقراءة هذه تلقائيًا بعد انتهاء صلاحية مخزن مؤقت دوار (مثل 30 يومًا).