💻 computer science

HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

إن HFIPay هو بروتوكول دفع عبر السلاسل (cross-chain) غير وصائي يحافظ على الخصوصية، يتيح عمليات التحويل إلى معرفات صديقة للبشر من خلال الجمع بين حل الترحيل خارج السلسلة (off-chain relay resolution) وبراهين المعرفة الصفرية لضمان الربط القابل للتحقق من قبل المرسل وإخفاء هوية المستلم دون الكشف عن سجلات المعاملات.

المؤلفون الأصليون: Jian Sheng Wang

نُشر 2026-03-31

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Jian Sheng Wang

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك تريد إرسال هدية لصديق، ولكن بدلاً من إعطائه عنواناً مادياً، تكتفي بإعطائه عنوان بريده الإلكتروني. في عالم الخدمات المصرفية التقليدية، هذا أمر سهل: تكتب "alice@email.com"، والبنك يعرف تماماً أين يرسل المال.

ولكن في عالم العملات الرقمية، الأمر حالياً بمثابة كابوس. يتعين عليك نسخ سلسلة طويلة ومخيفة من الحروف والأرقام (مثل 0x4f3...a9b)، والتأكد من اختيار الشبكة الصحيحة، ودفع رسوم لمجرد الإرسال. وإذا أخطأت، سيضيع المال للأبد.

HFIPay هو نظام جديد صُمم لإصلاح هذا الخلل. فهو يتيح لك إرسال العملات الرقمية إلى بريد إلكتروني أو رقم هاتف تماماً مثل التحويل البنكي، ولكن مع قوة خارقة: وهي الحفاظ على خصوصية حياتك المالية بالكامل.

إليك كيف يعمل ذلك، مشروحاً من خلال قصة بسيطة.

المشكلة: "البيت الزجاجي"

في الوقت الحالي، إذا أرسلت عملات رقمية لصديق باستخدام طريقة قياسية، فأنت تقوم فعلياً بكتابة اسمه على بيت زجاجي.

الطريقة الساذجة: إذا أرسلت مالاً إلى alice@email.com، فقد يحول النظام هذا البريد الإلكتروني إلى عنوان عام. أي شخص يعرف بريد أليس الإلكتروني يمكنه النظر إلى "البلوكشين" (سلسلة الكتل)، ورؤية عنوانها، ومعرفة التالي فوراً: "أوه، أليس لديها 50 بيتكوين، وقد اشترت سيارة يوم الثلاثاء الماضي، وهي تتداول مع بوب".
المخاطرة: هذا أمر خطير. إذا عرف مخترق بريدك الإلكتروني، يمكنه تتبع تاريخك المالي بالكامل.

الحل: نظام "العميل السري" (HFIPay)

يقدم HFIPay وسيطاً يسمى الـ Relay (تخيله كخدمة توصيل خفية ومدربة تدريباً عالياً) ويستخدم بعض الرياضيات السحرية (براهين المعرفة الصفرية - Zero-Knowledge Proofs) لحل مشكلة الخصوصية.

إليك العملية خطوة بخقول باستخدام تشبيه "الطرد السري":

1. الطلب (أنت)

تريد إرسال 100 دولار لصديقتك أليس باستخدام بريدها الإلكتروني alice@example.com. لست بحاجة لمعرفة عنوان العملات الرقمية الخاص بها. فقط أخبر الـ Relay: "أرسل 100 دولار إلى أليس".

2. خدعة الـ Relay السحرية (التعتيم)

الـ Relay يعرف عنوان العملات الرقمية السري الخاص بأليس، لكنه لا يخبرك به. بدلاً من ذلك، يقوم بشيء ذكي:

ينشئ صندوقاً عشوائياً فريداً (يسمى Intent) لهذه المعاملة تحديداً. لنسمِّه "الصندوق رقم 999".
يضع ملصقاً معتماً ومختوماً على الصندوق. يقول الملصق: "هذا الصندوق يخص الشخص الذي يملك المفتاح السري لبريد أليس الإلكتروني"، لكن الملصق نفسه لا يكشف شيئاً عن هوية أليس.
يضع الـ Relay هذا "الصندوق رقم 999" والملصق على البلوكشين العام.
نقطة جوهرية: بالنسبة لبقية العالم، يبدو "الصندوق رقم 999" كضجيج عشوائي. لا يمكن لأحد معرفة أنه يخص أليس. حتى لو عرفوا بريدها الإلكتروني، فلن يتمكنوا من العثيد على صندوقها.

3. فحص الأمان (الاقتباس الموثق)

قبل أن ترسل مالك، يعطيك الـ Relay إيصالاً (يسمى "Quote").

في وضع "التحقق" (Verified mode)، يكون هذا الإيصال برهاناً رياضياً. إنه يثبت: "أعد بأن الصندوق رقم 999 يخص أليس بالتأكيد، وأنني لم أستبدلها بشخص مزيف".
أنت تتحقق من هذا الإيصال. إذا بدا جيداً، ترسل الـ 100 دولار الخاصة بك إلى الصندوق رقم 999.
الـ Relay لا يمكنه سرقة المال. الرياضيات تثبت أن الشخص الوحيد الذي يمكنه فتح هذا الصندوق لاحقاً هو مالك المفتاح السري لبريد أليس الإلكتروني.

4. المطالبة (أليس تفتح الصندوق)

تتلقى أليس إشعاراً (عبر البريد الإلكتروني) بأن هناك صندوقاً ينتظرها. هي لا تحتاج لمعرفة رقم الصندوق؛ تطبيقها يتولى الأمر.

تستخدم أليس هاتفها لإنشاء برهان معرفة صفرية (Zero-Knowledge Proof). فكر في هذا كتعويذة سحرية تقول: "أنا مالكة المفتاح السري لبريد أليس الإلكتروني، وأنا أثبت أنني أستطيع فتح الصندوق رقم 999".
تعرض هذه التعويذة على البلوكشين.
يتحقق البلوكشين من التعويذة. يرى: "نعم، هذه التعويذة تطابق الملصق المختوم على الصندوق رقم 999".
يقوم البلوكشين بتحرير الـ 100 دولار إلى محفظة أليس.

السحر: أثبتت أليس أنها تملك الصندوق دون أن تكشف أبداً عن بريدها الإلكتروني أو مفتاحها السري للعامة.

لماذا يعد هذا أمراً هاماً؟

لا مزيد من "البيوت الزجاجية": قبل أن تطالب أليس بالمال، لا يمكن لأحد ربط "الصندوق رقم 999" ببريد أليس الإلكتروني. حتى لو عرف مخترق بريدها، لا يمكنه العثيد على معاملاتها.
لا مزيد من "نسخ العناوين": أنت فقط تكتب بريداً إلكترونياً. لا مزيد من سلاسل 0x... الطويلة.
سحر عبر السلاسل (Cross-Chain): تذكر الورقة البحثية أن هذا يعمل عبر سلاسل بلوكشين مختلفة (مثل إرسال بيتكوين إلى محفظة إيثيريوم). الـ Relay يتولى عمليات التبديل المعقدة، لكن قواعد الخصوصية تظل كما هي.
الـ Relay لا يمكنه السرقة: في السابق، إذا استخدمت خدمة "الإرسال إلى البريد الإلكتروني"، فقد كانوا يمسكون بمالك ويمكنهم الهروب به. في HFIPay، الـ Relay مجرد رسول. بمجرد إغلاق الصندوق على البلوكشين، أليس وحدها هي من يمكنها فتحه. لا يمكن للـ Relay إعادة توجيه الأموال لنفسه.

توازن "الثقة"

تميز الورقة بين طريقتين لاستخدام النظام:

الوضع الأساسي (Basic Mode): أنت تثق في أن الـ Relay يقول الحقيقة بشأن هوية أليس.
وضع التحقق (Verified Mode): يمنحك الـ Relay إيصالاً رياضياً يثبت أنهم لا يكذبون. ليس عليك الثقة بهم؛ عليك فقط الثقة في الرياضيات.

الملخص

HFIPay يشبه إرسال رسالة عبر ساعي بريد آمن ومجهول الهوية.

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

إنه يجعل العملات الرقمية سهلة الاستخدام مثل البريد الإلكتروني، مع الحفاظ على أسرارك المالية آمنة من الأعين المتطفلة.

إليك ملخص تقني مفصل لورقة البحث بعنوان: "HFIPay: مدفوعات العملات المشفرة عبر السلاسل إلى معرفات صديقة للبشر مع الحفاظ على الخصوصية."

١. بيان المشكلة

يعيق تبني العملات المشفرة سوء تجربة المستخدم (UX)، وتحديداً اشتراط إدارة المستخدمين لعناوين سداسية عشرية غامضة، واختيار الشبكات الصحيحة، والاحتفاظ بالرموز الأصلية (native tokens) لرسوم الغاز. وبينما تقدم "المعرفات الصديقة للبشر" (مثل رسائل البريد الإلكتروني، أرقام الهواتف، أو المعرفات الاجتماعية) حلاً لهذه المشكلة، فإن التنفيذات الساذجة التي تربط هذه المعرفات مباشرة بعناوين البلوكشين (على سبيل المثال: address = Hash(email)) تخلق ثغرات حرجة في الخصوصية:

الافتقار إلى مقاومة التعداد (Enumeration Resistance): أي طرف ثالث يعرف معرف المستخدم يمكنه استنتاج عنوانه على السلسلة وفحص تاريخ معاملاته بالكامل، وأرصدته، وعلاقاته مع الأطراف الأخرى.
الافتقار إلى عدم القابلية للربط (Unlinkability): إنشاء خرائط حتمية (deterministic mapping) لعدة مدفوعات لنفس المعرف يخلق وسماً عاماً قابلاً لإعادة الاستخدام، مما يسمح للمراقبين بربط جميع المعاملات بمستخدم واحد.
مقايضة الثقة مقابل الخصوصية: تعتمد حلول "الإرسال إلى البريد الإلكتروني" الحالية غالباً على أمناء حفظ مركزيين (centralized custodians)، مما يؤدي إلى مخاطر الطرف المقابل ويفتقر إلى قابلية التحقق على السلسلة (on-chain verifiability).

٢. المنهجية: بروتوكول HFIPay

يقترح HFIPay بنية تحتية تعتمد على وسيط (Relay) وغير احتجازية (non-custodial)، تفصل بين توجيه المعرف، وربط المستلم، وتحقق المرسل، وتفويض المطالبة. ويعتمد البروتوكول على ثلاثة مكونات أساسية: ZK-ACE (تفويض المعرفة الصفرية لتنفيذ السلسلة) لإثباتات المطالبة، و Va-Dar لاستعادة الهوية الخاصة، و خدمة الوسيط (Relay Service) للحل خارج السلسلة (off-chain resolution).

الآلية الجوهرية

يعمل البروتوكول عبر خمس مراحل:

١. إعداد المستلم والربط:

يقوم المستلم بتوليد جذر هوية حتمي ( $REVB$ ) ويستنتج التزام هوية ($IDcomB$).
يستنتج مقبض ربط ( $u_{B,e}$ ) والتزام مفتاح الربط ( $K_{B,e}$ ) لحقبة زمنية محددة ( $e$ ).
يقوم دليل خاص (الوسيط/Relay) بربط المعرف المعياري (مثل البريد الإلكتروني) بهذه الالتزامات. في وضع الاقتباس المتحقق منه (Verified-Quote)، يصدر طبقة الربط (Binding Layer) إشهاداً ( $\tau_B$ ) يثبت الصلة بين المعرف و $K_{B,e}$ .

٢. توليد الاقتباس وإنشاء النية:

يطلب المرسل عملية دفع إلى معرف ما.
يقوم الوسيط بتوليد intentId عشوائي وعنوان إيداع لمرة واحدة واحدة ( $\alpha$ ).
يحسب الوسيط ربطاً معتماً ( $\rho_i$ ) باستخدام هاش للمقبض المخفي للمستلم و intentId: $\rho_i = H("hfipay:bind" \parallel u_{B,e} \parallel intentId)$ .
وضع الاقتباس المتحقق منه: يوفر الوسيط إثباتاً خارج السلسلة يمكن للمرسل التحقق منه ( $\pi_{quote}$ ) يربط $\rho_i$ بـ $K_{B,e}$ المصدق عليه. وهذا يسمح للمرسل بالتحقق من أن الربط المعتم يتوافق مع المستلم المقصود قبل إرسال الأموال، مما يمنع استبدال المستلم.

٣. التمويل:

يتحقق المرسل من الاقتباس (في الوضع المتحقق منه) ومن تسجيل النية على السلسلة.
يقوم المرسل بتحويل الأصول إلى العنوان الحتمي $\alpha$ . يخزن العقد على السلسلة الثلاثية $(\rho_i, asset, amount, epoch)$ .

٤. تفويض المطالبة (المعرفة الصفرية):

يسترجع المستلم الـ intentId والحقبة الزمنية.
باستخدام جذر هويته الخاص، يعيد المستلم استنتاج المقبض $u_{B,e}$ ويولد إثبات ZK-ACE ( $\pi_i$ ).
يثبت الإثبات ما يلي:
- امتلاك جذر الهوية المقابل لـ $IDcomB$.
- أن $u_{B,e}$ يولد الربط المعتم المحدد $\rho_i$ المخزن على السلسلة.
- التفويض لتحرير الأموال إلى وجهة مختارة $\beta$ .
يقوم العقد على السلسلة بالتحقق من الإثبات وتحرير الأموال. لا يرى الوسيط المفتاح الخاص أو جذر الهوية الكامل أبداً.

٥. التسوية عبر السلاسل (n-Vm):

من خلال التكامل مع بيئة تشغيل n-Vm (طبقة هوية موحدة عبر عدة بيئات تشغيل افتراضية)، تسمح نفس آلية المطالبة بإيداع الأموال على السلسلة (أ) والمطالبة بها على السلسلة (ب). يسمح إثبات المطالبة بتحرير الأصول المغلفة على السلسلة الوجهة دون الحاجة إلى نموذج ثقة منفصل للجسر (bridge) بالنسبة للمستلم.

أهداف الخصوصية

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

٣. المساهمات الرئيسية

تصميم البروتوكول: بنية مبتكرة تفصل بين حل المعرف خارج السلسة وتفويض المطالبة على السلسلة، باستخدام الروابط المعتمة والاقتباسات القابلة للتحقق من قبل المرسل لمنع تلاعب الوسيط.
تركيب التفويض: دمج ZK-ACE لتفويض المطالبة من جانب المستلم، و Va-Dar لاستعادة الهوية عبر الأجهزة بشكل خاص دون سجل عام.
التحليل الرسمي للخصوصية: تعريفات وإثباتات رسمية لـ مقاومة التعداد و عدم القابلية للربط قبل المطالبة، مما يوضح أن البيانات على السلسلة لا تكشف أي معلومات عن هوية المستلم أو الرابط بين عدة نيات.
تمايز نموذج الثقة:
- الوضع الأساسي: يُعتبر الوسيط موثوقاً لضمان صحة الربط.
- وضع الاقتباس المتحقق منه: يتحقق المرسل من الربط عبر إثباتات خارج السلسلة، مما يزيل قدرة الوسيط على استبدال المستلم قبل التمويل.
التوسع عبر السلاسل: آلية لتوسيع المدفوعات القائمة على المعرف عبر بلوكشينات مختلفة (مثل BTC إلى ETH) باستخدام طبقة هوية موحدة (n-Vm) دون المساس بنموذج الخصوصية.

٤. النتائج والتحليل

الخصوصية: نجح النظام في إخفاء الرابط بين المعرفات البشرية والمعاملات على السلسلة. لا يمكن للمراقب الذي يعرف عنوان بريد إلكتروني تحديد أي النيات على السلسلة تنتمي لهذا البريد، كما لا يمكنه ربط نيتين منفصلتين قبل المطالبة بنفس المستخدم.
الأمان: يتميز البروتوكول بمقاومة هجمات استبدال المستلم في وضع الاقتباس المتحقق منه. بمجرد أن يتحقق المرسل من الاقتباس ويمول النية، لا يمكن للوسيط إعادة توجيه الأموال إلى عنوان مختلف دون كسر الربط التشفيري أو نظام إثبات ZK.
نموذج التهديد: يفترض النظام إمكانية اختراق دليل الوسيط الخاص. في هذه الحالة، يمكن للمهاجم إعادة بناء الرسم البياني (البريد الإلكتروني-النية). ومع ذلك، يخفف البروتوكول من ذلك عبر:
- تدوير حقبات الربط (epochs).
- ضمان عدم قدرة الوسيط على إعادة توجيه الأمونة من جانب واحد بعد الالتزام على الس la سلسلة.
- الاعتماد على إثباتات ZK للمطالبة النهائية، مما يعني أن الوسيط المخترق لا يمكنه المطالبة بالأموال نيابة عن المستخدم دون جذر الهوية الخاص به.
التنفيذ: توضح الورقة عمليات تنفيذ قابلة للتطبيق على EVM (باستخدام CREATE2 لعناوين حتمية) و Solana (باستخدام عناوين مشتقة من البرامج - PDAs)، مما يظهر التوافق مع قدرات السلاسل القياسية.

٥. الأهمية

يمثل HFIPay خطوة مهمة نحو جعل العملات المشفرة متاحة للمستخدمين غير التقنيين مع الحفاظ على ضمانات خصوصية قوية.

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

باخت-صار، يقدم HFIPay طبقة توجيه قوية تحافظ على الخصوصية وتفصل بين الهوية البشرية والنشاط على السلسلة، مما يتيح مدفوعات عبر السلاسل سهلة الاستخدام وآمنة ومبنية على هوية بشرية.