الخصوصية القابلة للبرمجة: تقنيات Aztec وGarbled Circuits

تطور بنية الخصوصية: من أدوات الخلط إلى البروتوكولات القابلة للبرمجة

تتلاشى أدوات الخلط (Mixers) الكلاسيكية مثل Tornado Cash أو Sinbad تحت ضغط الجهات التنظيمية، وعوبات مكتب مراقبة الأصول الأجنبية (OFAC)، وتحليل رسم بياني للمعاملات باستخدام التتبع العنقودي الاستدلالي. يتم حظر إخفاء الهوية الأصلي على مستوى تجمعات السيولة (Liquidity Pools) في طبقة العقود الذكية عبر قوائم العناوين عالية المخاطر (Chainalysis، Elliptic) المدمجة في عقد RPC الخاصة بكبار المزودين (Infura، Alchemy).

تنتقل الصناعة نحو مفهوم الخصوصية القابلة للبرمجة (Programmable Privacy). فبدلاً من إخفاء حقيقة المعاملة نفسها عن طريق تمويه الإيداعات داخل التجمع، تتيح الحلول الجديدة على مستوى البروتوكول تنفيذ منطق أعمال عشوائي وعقود ذكية فوق البيانات المشفرة. وتقود هذا التحول شبكات مبنية على بنيات zk-rollup تدعم Programmable Privacy، مثل Aztec (Noir)، والشبكات السرية المتخصصة من الطبقة الأولى (L1) مثل COTI 2.0، مستفيدة من التقنيات والأدوات التشفيرية من الجيل الجديد.

الدوائر المشفرة (Garbled Circuits) في البلوكشين

في صميم منصات مثل COTI 2.0 تكمن الأداة التشفيرية الكلاسيكية بروتوكول ياو (Yao's Garbled Circuits)، المصممة خصيصاً لتناسب بيئة البلوكشين اللامركزية. وعلى عكس zk-SNARKs، التي تثبت صحة البيانات دون الكشف عنها، تتيح Garbled Circuits لطرفين أو أكثر لا يثقون ببعضهما البعض حساب دالة منطقية (Boolean function) تعسفية على المدخلات السرية دون أن يتمكن أي طرف من الاطلاع على بيانات الطرف الآخر.

ميكانيكا الدائرة المشفرة

• 1. تمثيل المنطق في صورة دائرة منطقية: يتم تجميع أي عملية حسابية (تحويل الرموز، التحقق من الرصيد، التقييم الائتماني) في رسم بياني موجه لا دوري (DAG) يتكون من بوابات منطقية (AND, XOR, NOT).
• 2. التشفير العشوائي (Garbling): يقوم منشئ الدائرة (Garbler) بتوليد مفاتيح عشوائية بطول 128 بت لكل مدخل ومخرج لكل بوابة. يتم تشفير جداول الحقيقة للبوابات بهذه المفاتيح بترتيب عشوائي.
• 3. النقل الغامض (Oblivious Transfer, OT): يحصل مقيم الدائرة (Evaluator) على مفاتيح الإدخال الخاصة به من منشئ الدائرة عبر بروتوكول OT التشفيري. يتعرف Evaluator على المفاتيح الخاصة بمدخلاته الحقيقية فقط دون كشفها للـ Garbler، ودون الحصول على صلاحية الوصول إلى بقية المفاتيح.
• 4. الحساب عنصراً بعنصر: يقوم Evaluator فك تشفير جداول الحقيقة المشفرة من الأسفل إلى الأعلى عبر الدائرة، حاسباً النتيجة دون أي قدرة على معرفة القيم الوسيطة للمتغيرات.

التحسينات الهندسية للبلوكشين

تتطلب Garbled Circuits الخام حجماً هائلاً من الاتصالات الشبكية. ولدمجها في بيئة البلوكشين، يطبق المطورون تحسينين أساسيين:

• تقنية Free-XOR: تتيح تنفيذ بوابات XOR دون الحاجة لتشفير البيانات أو نقلها، مما يقلل العبء على الذاكرة وعرض النطاق الترددي لناقل البيانات بشكل مضاعف.
• Point-and-permute: طريقة لإخفاء البتات تسمح لـ Evaluator بالعثور فوراً على الصف الصحيح في جدول الحقيقة المشفر جميع خيارات فك التشفير بالقوة العمياء (Brute-force).

مقارنة بين حزم تشفير السرية والتخفي

لاختيار حزم التقنيات المناسبة عند تصميم التطبيقات اللامركزية المحمية للبيانات، يتم إجراء مطابقة للمقاييس الرئيسية للبروتوكولات الحديثة.

التطبيق العملي: الافصاح الانتقائي (Selective Disclosure) والعملات المستقرار (Stablecoins)

يتطلب الامتثال التنظيمي الحديث الانتقال من مفهوم "الغموض المطلق" إلى مبدأ الإفصاح الانتقائي (Selective Disclosure). يحتفظ المستخدم بالتحكم الكامل في تاريخ رأس ماله، ولكن عند الحاجة، يمكنه إثبات شرعية الأموال للطرف الآخر، أو الجهة التنظيمية، أو السلطات الضريبية دون الكشف عن رصيد المحفظة بالكامل أو شبكة العلاقات الكاملة مع العناوين الأخرى.

في هندسة Aztec، يتم تطبيق ذلك عبر نظام مفاتيح منفصلة والتنفيذ من جانب العميل داخل بيئة التنفيذ الخاصة (Private Execution Environment - PXE).

هندسة المفاتيح في Aztec

يدير كل مستخدم مجموعة حتمية من المفاتيح المرتبطة بالعقد الذكي للحساب:

• Nullifier Keys ($nhk$): تُستخدم لتوليد إثباتات إنفاق الأموال (nullifiers) دون تسريب أي معلومات حول الرصيد المحدد أو الملاحظة (note) التي يتم إنفاقها.
• Incoming Viewing Keys ($ivsk$): تتيح منح صلاحية التدقيق لمعاملات واردة محددة. يمكنك تمرير مفتاح عرض مشفر إلى الطرف المقابل أو الجهة التنظيمية، مما يتيح لهم رؤية معاملة العملة المستقرة المستهدفة فقط (مثل USDT/USDC المغلفة على L2) مع إبقاء بقية الأصول مخفية تماماً.

مثال عملي: التحويل الخاص للعملات المستقرة باستخدام لغة Noir

فيما يلي مقتطف من كود جاهز للإنتاج (production-ready) مكتوب بلغة Noir (لغة النطاق المخصص الأساسية لكتابة الدوائر في Aztec)، والذي ينفذ التحقق الخاص من الرصيد وتوليد التزام تحويل التوكنات دون نشر المبالغ على السجل العام.

مقتطف الكود

// الاعتمادية في Nargo.toml: poseidon = { tag = "...", git = "https://github.com/noir-lang/poseidon" }
use poseidon::poseidon::bn254::{hash_2, hash_3};
global TREE_DEPTH: u32 = 32;
struct Note {
    owner: Field,
    amount: u64,
    randomness: Field,
}
fn commit(note: Note) -> Field {
    hash_3([note.owner, note.amount as Field, note.randomness])
}
fn merkle_root(leaf: Field, index: u32, path: [Field; TREE_DEPTH]) -> Field {
    let bits: [u1; TREE_DEPTH] = (index as Field).to_le_bits();
    let mut node = leaf;
    for i in 0..TREE_DEPTH {
        node = if bits[i] == 0 {
            hash_2([node, path[i]])
        } else {
            hash_2([path[i], node])
        };
    }
    node
}
fn main(
    // المدخلات العامة: لا توجد معلومات عن المبالغ أو العناوين
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // المدخلات الخاصة
    sender_sk: Field,
    sender_note: Note,
    path: [Field; TREE_DEPTH],
    leaf_index: u32,
    transfer_amount: u64,
    recipient_owner: Field,
    recipient_randomness: Field,
    change_randomness: Field,
) {
    // 1. ملكية الملاحظة (مع علامة النطاق - domain tag)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. الانتماء إلى شجرة ميركل بالنسبة للجذر العام
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. كفاية الأموال (في حال النقص، ستفشل عملية الطرح بـ u64 أيضاً)
    assert(sender_note.amount >= transfer_amount);
    let change_amount = sender_note.amount - transfer_amount;
    // 4. معطل الإنفاق (Nullifier)
    assert(hash_3([sender_commitment, sender_sk, 2]) == nullifier);
    // 5. الملاحظتان الجديدتان مرتبطتان بالتزامات عامة
    assert(commit(Note {
        owner: recipient_owner,
        amount: transfer_amount,
        randomness: recipient_randomness,
    }) == recipient_commitment);
    assert(commit(Note {
        owner: sender_note.owner,
        amount: change_amount,
        randomness: change_randomness,
    }) == change_commitment);
}

ما يبقى خارج الدائرة: تشفير الملاحظات للمستلم، تخزين وتحديث الشجرة على العقد، التحقق من تفرد معطل الإنفاق (nullifier)، ومطابقة merkle_root_pub مع الجذر المعروف.

توصيات التكامل للمطورين

• 1. تجنب توليد الإثباتات على الخادم: لا تثق أبداً في تفويض توليد إثباتات المعرفة الصفرية (ZK-proofs) لخوادم واجهات برمجة التطبيقات (APIs) الخارجية التابعة لجهات خارجية. يجب أن يتم دورة الحساب بالكامل (PXE في Aztec أو نصوص العميل) محلياً على جهاز المستخدم أو في عقدة معزولة.
• 2. إدارة المفاتيح المعزولة للتطبيقات (App-Siloed Keys): استخدم مفاتيح مشتقة ومعزولة لكل تطبيق لامركزي (dApp). يضمن ذلك ألا يؤدي اختراق مفتاح في بروتوكول واحد إلى كشف هوية تاريخ معاملات المستخدم في العقود الذكية الأخرى.
• 3. تدقيق قنوات مفاتيح العرض (View Keys): عند تصميم بوابات المؤسسات أو بوابات الدفع القائمة على الخصوصية القابلة للبرمجة، قم بتضمين منطق لتوليد مفاتيح عرض مؤقتة ذات صلاحية محددة بوقت (time-to-live). يتيح لك ذلك اجتياز متطلبات الامتثال المصرفي والتنظيمي (AML/KYT) دون نشر مفاتيح المحفظة الرئيسية والدائمة.