مقدمة

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

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

توفر عناوين الخفاء وسيلة لتوفير الخصوصية التي يتمتع بها المستخدمون دون التفكير فيها في حسابات البنوك الخاصة، وبطريقة سهلة الفهم. وعلاوة على ذلك، فإن الابتكارات حول عناوين الخفاء تعني أنه يمكننا بالتالي القيام بذلك بطريقة تتماشى مع لوائح مكافحة غسل الأموال في العديد من الاختصاصات.

طلب المستخدم للخصوصية

على الرغم من عدم توافر الكثير من الأبحاث حول المواقف تجاه الخصوصية بين مستخدمي الويب والويب3، إلا أن البحوث التالية تم اكتشافها من خلال البحث عبر الويب، والنتائج تتماشى عمومًا، وتوضح وجود رغبة واضحة في الخصوصية التعاملات.

1. تم إجراء استطلاع في عام 2022 ونشره سیمین قاسمی وآخرون في ورقة بعنوان: الخصوصية التي يدركها المستخدم في سلسلة الكتلأوضح أن "نصف المُقابلين حددوا أن خصوصية المعاملات مهمة جدًا بالنسبة لهم". بينما كان هذا البحث أكثر صلة ببيتكوين من إثيريوم، فمن المحتمل أن هناك مواقف مماثلة لمستخدمي إثيريوم أيضًا. كان حجم العينة لهذا البحث صغيرًا إلى حد ما (14 مشاركًا).
2. قطعة أخرى مثيرة للاهتمام من البحث لعام 2022، نُشرت في الحدود، بعنوانمواقف المستخدمين في مجال البلوكشين السياسية والاقتصادية والحكمية، هو أكثر شمولية، حيث تم استطلاع آراء 3,710 مستخدمًا للعملات المشفرة. أظهرت النتائج أن حوالي ربع المشاركين أشاروا إلى أن الخصوصية هي 'الميزة الأكثر أهمية في تقنية البلوكشين والعملات المشفرة'.

1. من حيث المواقف تجاه الخصوصية بشكل عام، كونسينسيسالبحث المنشور بعنوانمسح Web3 والتشفير العالمي 2023، حيث قاموا بمسح 15،158 شخصًا عبر الإنترنت في 15 دولة حول مواضيع مختلفة تتعلق بالويب، وليس فقط العملات المشفرة. وجدت الدراسة أن 83% من المستجيبين يعتقدون أن خصوصية البيانات مهمة، بينما ذكر 45% فقط من المستجيبين أنهم يثقون في كيفية استخدام خدمات الإنترنت الحالية لبياناتهم ومعلوماتهم الشخصية.
2. أحددراسة أجراها نظام تعويض خدمات الخدمات المالية في المملكة المتحدة، التي نُشرت في أبريل 2023 أبرزت أن 9% من المستجيبين استشهدوا بـ "رغبة في ال匿名ية/الخصوصية" كسبب لاستثمارهم في عملة مشفرة.

اعتماد بروتوكولات المعاملات الخفية

ريلجانلديها أرقام مثيرة للإعجاب، حيث يبدو أن استخدام البروتوكول ينمو بشكل مستقر مع مرور الوقت أيضًا، حيث وصل إلى ذروته بأكثر من 70 مليون دولار من القيمة الإجمالية المقفولة و2 مليار دولار من الحجم بحلول نوفمبر 2024.

قيمة التلفزيون (USD) Railgun على الشبكة الرئيسية لإثيريوم - المصدر: ​​ريلجان - ديفيلا ما

أمبراشهدت أيضًا زيادة مستمرة في عدد الأشخاص الذين يستخدمون بروتوكولهم (الأشخاص الذين يقومون بتسجيل عنوان مخفي في ENS الخاص بهم)، حيث بلغ عددهم ما يقرب من 77 ألفًا حتى نوفمبر 2024:

مسجلو Umbra التراكميون (Cross Chain) — المصدر: dune.com

إذا ننظر إلى أشهر بروتوكول للخصوصية في إثيريوم (والمشهور بشكل غير محمود الآن) ، وهو Tornado cash ، يمكننا أن نرى أنه لا يزال يشهد استخدامًا كبيرًا ، على الرغم من حقيقة أن عناوين العقود مدرجة رسميًا في قائمة OFAC's SDN.

الرسم البياني أدناه يظهر قيمة القرض المقترح بشكل متزايد من Tornado Cash مع مرور الوقت. يمكننا ملاحظة أن أول انخفاض رئيسي في قيمة القرض المقترح من ذروتها في أكتوبر 2021 تزامن مع بيع أوسع في الأسواق الرقمية، مع الانخفاض الرئيسي الثاني في أغسطس 2022 المتوافق مع وضع Tornado Cash على قائمة SDN من قبل OFAC، والانخفاض الرئيسي الثالث المتوافق مع إعادة تصميم OFAC في نوفمبر 2022. ومنذ ذلك الحين، إلا أن Tornado Cash شهد نمواً مستقراً، على الرغم من العقوبات، وصلت تقريباً إلى 600 مليون دولار في قيمة القرض المقترح. هذه دليل قوي جداً على أن هناك طلباً للخصوصية الأساسية في المعاملات في إثيريوم.

TVL (USD) Tornado Cash على إثيريوم الرئيسية - المصدر: Tornado Cash — DefiLlama

مناظر عنوان الاختفاء

توصلت هذه الدراسة إلى تحديد 4 حلول رئيسية لسلاسل EVM في الإنتاج حتى اليوم، وهذه هي:

• Fluidkey
• ظل
• متاهة
• ريلجان

كلا من Fluidkey و Umbra مبنيان على معايير إثيريوم، وهي:

• ERC-5564: بروتوكول العنوان الخفي
• ERC-6538: سجل عنوان ميتا ستيلث

المتاهة وريلجان مبنيان على بروتوكول زيروكاش(التيzcash يعتمد أيضا على) ، والذي يستخدم تجمعا محميا يقوم المستخدمون بإيداع الأموال فيه. تستخدم Zerocash مفهوم "الملاحظات" ، والتي هي في الأساس تمثيلات مشفرة للقيمة التي تمكن المعاملات الخاصة. تتضمن كل ملاحظة قيمة مخفية ومفتاح مالك ورقم فريد (مبطل) ، مع استخدام zk-SNARKs للتحقق من الملكية دون الكشف عن التفاصيل ، وبالتالي لنقل القيمة في الملاحظات. عندما يتم إنفاق ملاحظة ، يتم الكشف عن المبطل الخاص بها لمنع الإنفاق المزدوج ، بينما يتم إنشاء ملاحظات جديدة للمستلم (المستلمين) ، مما يشكل نظام UTXO داخل التجمع المحمي.

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

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

كيف تعمل عناوين الخفية

عنوان التخفي الفائق هو ببساطة توصيل 2 مفاتيح عامة مضغوطة، المشار إليها بـ "مفتاح الإنفاق" و "مفتاح العرض". يستخدم عنوان التخفي الفائق تنسيق عنوان محدد للسلسلة EIP-3770، مع إضافة بادئة "st:". فيما يلي مثال على عنوان التخفي الفائق:

st:إثيريوم:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

من أجل البساطة ، يمكن ربط عنوان التخفي هذا بعنوان Ethereum العادي (وبالتالي ENS) ، مما يسهل إرسال الأموال إلى مالك العنوان الخفي. لإرسال الأموال ، سيقوم المرسل بحل العنوان أعلاه ، وباستخدام معيار EIP-5564 ، سينشئ مفتاحا عاما سريع الزوال ، يستمد منه بعد ذلك عنوان التخفي. يرسل المرسل الأموال إلى عنوان التخفي الجديد ، عادة عبر عقد فردي يستمع إليه جميع مستلمي عناوين التخفي للأحداث. يصدر هذا العقد حدث "إعلان" يشترك فيه المستلمون. في كل مرة يتم فيها إصدار حدث إعلان ، سيتحقق المستلمون من المفتاح العام سريع الزوال في الإعلان ، ويدمجونه مع مفتاح العرض الخاص بهم ، ويحددون ما إذا كان لديهم القدرة على إنفاق الأموال المرسلة إلى عنوان التخفي. إذا فعلوا ذلك ، فإن المحفظة / العميل الذي يستخدمونه سيتذكر عنوان التخفي والأموال المعنية ، وإضافته إلى الرصيد المعروض للمستخدم. لإنفاق الأموال فعليا ، يمكنهم توقيع معاملة باستخدام مفتاح الإنفاق الخاص.

يوضح الشكل التالي عملية النهاية إلى النهاية بشكل أكثر وضوحًا قليلاً:

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

ومع ذلك، من أجل أن يعمل هذا في المقام الأول، يجب على المستلم أن يعلم الباحثون عن العنوان الخفي الخاص به. أحد الطرق للقيام بهذا هو استخدامسجل العنوان الفائق EIP-6538. هذا عقد فردي يسمح للمستخدمين بتسجيل عنوان تعريف خفي على عنوان Ethereum عادي ، والذي يمكن للمرسلين البحث عنه بعد ذلك. يسمح هذا للمرسلين بحل العنوان العادي من ENS، ثم البحث عن عنوان التعريف الشفي المرتبط من السجل.

يكسر هذا النظام الارتباط بين المرسل والمستلم، مما يمنحهما الخصوصية من علم العالم بأسره بشؤونهما. هناك بعض الشروط:

• عندما ينتقل المستلم لإنفاق الأموال، فإن أي شخص يتلقى تلك الأموال سيشاهد أنها نشأت من المرسل الأصلي (أي يمكنهم رؤية عنوان تحويل الأموال منه ومن سبق أن أرسل الأموال إلى ذلك العنوان). ما يعني ذلك هو أن سلسلة التحويلات تبقى سليمة وقابلة للتتبع، ولكنها لا ترتبط بالمستلم المعني (ما لم يقوم المستلم بشيء مثل إرسال الأموال إلى أحد عناوينه غير المخفية المعروفة). يرجى ملاحظة أن هذا ينطبق فقط على تطبيقات erc-5564، وليس على Railgun أو Labyrinth.
• أحد الآثار الجانبية الأخرى للمشكلة أعلاه هو أنه من أجل الحفاظ على الخصوصية الأمثل ، فمن المرجح أن يحتاج المستخدم إلى ترك الأموال في العناوين الخفية التي تم إرسالها إليها في الأصل حتى يحتاجها فعلاً ، بدلاً من دمجها معًا تحت عنوان واحد. يمثل هذا تكاليف إضافية لتذكر العناوين ، وبالتالي إنفاق الأموال في تلك العناوين ، حيث سيحتاج إلى الحصول على المبلغ الذي ترغب في نقله من مجموعة من الأموال في عناوين أخرى مختلفة.
• لكي يتمكن المستلم من تحويل الأموال من هذا العنوان، سيحتاج المستلم إلى تمويل العنوان ببعض الإثيريوم لدفع تكاليف الغاز، وهذا قد يؤدي بالمستلم إلى فقدان الاختفاء. هذه مشكلة معروفة في العناوين الخفية، وهي واحدة من الأسباب التي دفعت العديد من التنفيذات إلى دعم EIP-4337 ومدفوعاته.
• أحد عيوب مخطط العنوان الشبح هو أن المستلمين يحتاجون إلى مراقبة blockchain لأحداث الإعلان والتحقق من كل إعلان لتحديد ما إذا كان قد تم إرسال الأموال إليهم. من الواضح أن هذا يمثل عبئا غير عملي لمعظم المستخدمين ، خاصة عندما يتعلق الأمر بتلقي الأموال على شبكات متعددة. من أجل جعل هذه العملية أكثر كفاءة ، يحدد المعيار "علامة عرض" ، وهي تجزئة مقطوعة مشتقة من السر المشترك ، ويمكن استخدامها لتجاهل المعاملات التي ليست مخصصة لها بالتأكيد. من خلال استخدام علامات العرض ، فإن الأداء ليس بهذا السوء على سطح المكتب ، ولكن يمكن أن يكون أكثر وضوحا إلى حد ما على الأجهزة المحمولة. المرة الوحيدة التي تكون فيها ضربة الأداء ملحوظة حقا هي إذا تمت استعادة المحفظة ، وفي هذه الحالة ستحتاج المحفظة إلى مسح كل عنوان منذ نشر العقد على السلسلة ، وهو ما يستغرق وقتا طويلا.
• للتغلب على هذا، يمكن للمستخدمين مشاركة المفتاح الخاص للعرض اختياريًا مع طرف ثالث موثوق به. يمكن لهذه الخدمة الطرفية مراقبة شبكات مختلفة وإخطار المستخدمين عندما يتلقون الأموال. وبالطبع يأتي هذا مع تضحية: على الرغم من أن الطرف الثالث لا يمكنه بالفعل إنفاق أموال المستخدمين (ليس لديهم المفتاح الخاص للإنفاق للقيام بذلك)، يمكنهم رؤية جميع الأموال المُرسلة إلى مستلم معين، مما يعني أن المستخدم يحتاج إلى الثقة بهم بخصوص خصوصيتهم. يقوم Fluidkey بذلك افتراضيًا.
• يتم تصميم بروتوكول عنوان الاختفاء القياسي ، أي ERC-5564 ، لتسهيل التحويلات المحفوظة للخصوصية ، ومع ذلك ، يتطلب حالات الاستخدام غير المالية مثل استدعاء وظائف العقد الذكية التعامل مع هندسة أكثر قليلاً ، وعادة ما تكون محددة للتنفيذ.

مصفوفة المقارنة

هناك طرق مختلفة يمكننا من خلالها مقارنة أربعة تنفيذات لعناوين الاختفاء التي تستكشف هذه المقالة. جميع التنفيذات لها اختلافات طفيفة وتجارب ، ولكن ربما أهم النقاط التي يجب التركيز عليها هي قابلية التتبع وتعتيم القيمة.

بينما يسمح كل من Fluidkey و Umbra بتحويل الأموال إلى عنوان Ethereum قياسي مع كسر أي رابط لهوية المستلم ، إلا أنهما لا يزالان يحتفظان بإمكانية تتبع المعاملة ، مما يعني أن المرسل مرئي لأي شخص يفحص سجل المعاملات لعنوان التخفي. هذا يعني أنه إذا تلقيت أموالا على عنوان خفي ، فإن الشخص الذي تقرر إرسال هذه الأموال إليه سيرى من أين أتت. علاوة على ذلك ، فإن القيمة الفعلية التي يتم نقلها مرئية أيضا. تخفي Railgun و Labyrinth المرسل ، بالإضافة إلى القيمة التي يتم إرسالها ، ولكن مع المفاضلة أن كل هذا يحدث داخل عقد واحد ، وليس كمعاملة عادية لعنوان Ethereum العادي.

الشكل أدناه يوضح كيف تتم مقارنة البروتوكولات التي ننظر إليها في هذا المنشور مع بعضها البعض عبر هذين البعدين الهاميين للمقارنة.

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

1. الخصوصية من النهاية إلى النهاية (يرون الدفعة فقط المرسل والمستلم)
2. سرية الإعلان. إرسال الأموال التي تم استلامها عبر المعاملات الخفية لا يسمح للمستلم الثاني بمعرفة مصدر الأموال.
3. يتبع معايير erc-5564 و erc-6538
4. ينفذ العمارة القابلة للتوسع والمعمارية المودولار التي تسمح بالتكامل مع تطبيقات الأطراف الثالثة
5. هل توفر التنفيذة SDK يمكن للمطورين استخدامها للتكامل؟
6. هل يوفر الحل مستوى من الامتثال من خلال دعم نوع من إلغاء التعريف؟
7. هل يدعم التصميم تشويش المبلغ / القيمة المحولة؟

| بروتوكول | الخصوصية الكاملة للنهاية | سرية المستقبل | المعيار المفتوح | الهندسة المعمارية القابلة للتعديل | أداة تطوير البرمجيات | دعم لإلغاء التعريف | الكميات المخفية |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | قريبًا | ✅ | ⛔️ |

| المتاهة | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

| Railgun | ✅ | ✅ | ⛔️ | ✅ | ✅ | طوعي | ✅ |

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

على سبيل المثال: في Fluidkey: تذهب جميع التحويلات مباشرة إلى عناوين مخفية على السلسلة، مع Umbra: يذهب فقط ETH إلى عناوين مخفية على السلسلة، بينما تذهب الرموز إلى عقد مركزي، ومع Railgun و Labyrinth، تذهب جميع المعاملات إلى عقود النواة، وليس مباشرة إلى عناوين مخفية على السلسلة.

الغوص العميق في تنفيذ عناوين التمويه

Fluidkey

Fluidkeyهو تنفيذ ل erc-5564 الذي يسمح للمستخدمين بإرسال واستقبال وتبديل وربط ETH ورموز erc-20. في وقت الكتابة، يتم نشر Fluidkey على Base وOptimism وArbitrum وPolygon وGnosis وEthereum mainnet.

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

هناك عدة طرق يختلف بها Fluidkey عن التطبيقات الأخرى. إحدى الطرق التي يختلف بها Fluidkey عن التطبيقات الأخرى لعناوين التخفي هي أن المستخدمين يشاركون مفتاح العرض الخاص بهم مع Fluidkey (في الواقع أ بيب-32العقدة المشتقة من المفتاح لتكون محددة). يتيح ذلك لـ Fluidkey إنشاء عناوين مخفية للمستخدم وأيضًا إشعار المستخدم عندما يتلقون مدفوعات لتلك العناوين. ومع ذلك، فإنه يعني أن Fluidkey في وضع يمكنه عرض معاملات المستخدم الواردة والأرصدة، وهو التضحية. ومع ذلك، فإنه لا يزال يبقى ذاتي الحضانة بالكامل.

جانب آخر مثير للاهتمام في تصميم Fluidkey هو أنه ينشئ حساب عقد ذكي لكل عنوان مخفي جديد. يحدث هذا بشكل مضاد فقط عندما يتم إنفاق الأموال من عنوان مخفي. الحساب الذكي هو حساب آمن 1/1، ويسمح بأشياء مثل رعاية الغاز، مما يجعل من السهل إدارة مختلف عناوين الخفاء معًا. هناك تفاصيل شاملة حول هذا في مراجعة تقنية.

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

يتمتع المستخدمون أيضا بحرية تامة إما في تصدير معاملاتهم ، أو مشاركة مفاتيح العرض الخاصة بهم مع أطراف ثالثة (مثل محاسبهم) ، والتي يمكن أن تكون مفيدة للغاية ، خاصة للشركات. ومع ذلك ، تجدر الإشارة إلى أنه مع مواصفات erc-5564 ، فإن مشاركة المفتاح العام هي "كل شيء أو لا شيء" ، مما يعني أنه لا يمكنه الكشف عن المعاملات الفردية المعزولة بمفردها. أيضا ، كما هو الحال مع جميع تطبيقات erc-5564 ، لا يتم كسر إمكانية التتبع - فقط إمكانية الربط بالمستخدم - مما يعني أن سجل المعاملات لكل عنوان خفي مكشوف لمن لديه مفتاح العرض. إحدى الميزات غير المعروفة جيدا ل Fluidkey والتي تساعد على التخفيف من هذه المقايضات هي القدرة على تدوير مفاتيح العرض ، والتي من شأنها أن تسمح للمستخدم باستخدام مفتاح عرض جديد كل شهر ومشاركة الوصول إلى العرض فقط لأشهر محددة مع طرف ثالث.

إحدى الفوائد الجميلة لنهج Fluidkey هو أن العنوان الخفي نفسه لا يتم إنشاؤه من قبل المرسل، بل يتم إنشاؤه بشكل شبه عشوائي من قبل Fluidkey نفسها في كل مرة يتم فيها الاستعلام عن ENS. هذا أمر أسرع بكثير لأن المستخدمين لا يحتاجون إلى المسح من خلال أحداث الإعلان من أجل تحديد المعاملات التي هم المستلم فيها. هذا يعني أيضًا أن المرسل لا يحتاج إلى محفظة عنوان خفي من أجل إنشاء عنوان خفي للمستلم - بل يرسل الأموال إلى عنوان كما يفعل مع أي عنوان آخر وهذا كل شيء. هذا يعني أيضًا أنه لا يوجد عقد سجل متورط، وهو أمر فريد في تصميم Fluidkey وميزة رئيسية.

من الجدير بالذكر أن Fluidkey ملتزمة بأن تكون تمامًا ذاتية الحوزة، وقد قامت بإصدار مكتبة Stealth Account Kit الخاصة بها كشفتها المصدرية، وهناك أيضًا عدة واجهات استرداد مطورة بشكل مستقل متاحة في حالة وجود اختفاء مفاجئ لـ Fluidkey، مما يعني أن الأموال لن تتم تجميدها أو تعليقها أبدًا.

مجردة العنوان

من خلال استخدام حسابات العقود الذكية بشكل مضاد للواقع، يمكن لـ Fluidkey تجريديًا تجريديًا إدارة عناوين الخفاء الفردية تلقائيًا. وهذا يعني أنه إذا كنت ترغب في تحويل مبلغ معين إلى مستلم معين من أرصدتك عبر مختلف عناوين الخفاء، يمكن لـ Fluidkey أن تحدد تلقائيًا التركيبة المناسبة من العناوين لاستخدامها من أجل توفير الأموال للتحويل، معالجة جميع تكاليف الغاز ونشر العقود، كل ذلك خلف الكواليس. كما يُسمح لمستخدمي Fluidkey أيضًا بممارسة بعض التحكم في العناوين المجتمعة باستخدام ميزة رائعة تسمى التسميات، التي تتيح للمستخدم وسم العناوين في فئات مختلفة.

قرار ENS

يتطلب Fluidkey من المستخدمين إنشاء أسماء ENS خاصة ب Fluidkey. تأخذ هذه الأسماء الثابتة أشكال 2: username.fkey.id و username.fkey.eth ، أحدهما عبارة عن عنوان URL لواجهة الويب لإرسال أموال لشخص ما ، والآخر اسم ENS قياسي يمكن استخدامه مع المحافظ.

إعداد ENS يستخدم بوابة محلل ENS غير متصل بالشبكة (aka erc-3668: قراءة CCIPلإرجاع عناوين الخفية. في كل مرة يتم استعلام حل السلسلة الخارجية، يقوم بتوليد وإرجاع عنوان خفي جديد لاسم ENS المعني. هذه ميزة جميلة حيث تسمح للمستخدم بالحصول على اسم ENS بسهولة يمكن قراءته من الإنسان وفي نفس الوقت الاحتفاظ بسرية العناوين الخفية، حيث لا يمكن ربط العناوين الخفية المولدة بالإسم ENS بشكل استرجاعي.

تكلفة

يمكن استخدام Fluidkey مجانًا ولا يفرض رسومًا. هناك تكلفة نشر عقد Safe إلى كل عنوان يحتوي على أموال عندما ترغب في إنفاق تلك الأموال. ومع ذلك ، بينما يكون مكلفًا نسبيًا على mainnet ، فإنه في L2s يكون متناهي الصغر حقًا ، عادة أقل من سنت واحد ، حتى عند دمج عناوين الاختفاء المتعددة في تحويل واحد.

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

نقود الظل

أمبراهو تنفيذ لـ eip-5564 + eip6538 بواسطةScopelift. عندما يقوم المستخدم بتسجيل الدخول إلى تطبيق Umbra ، فإنه يمر بمرحلة الإعداد ، حيث يوقع على رسالة ، والتي يتم اشتقاق مفاتيح الإنفاق والعرض والعنوان التعريفي الخفي المعني. ثم يقومون بتسجيل هذا العنوان التعريفي الخفي إلى عنوان محفظتهم الرئيسي في سجل على السلسلة. هذا هو المكان الذي يختلف فيه التنفيذ عن Fluidkey.

تقترب تنفيذ Umbra لـ erc-5564 أكثر من المواصفات، بحيث ليس لديهم وصول إلى مفاتيح المستخدم. بينما يعني هذا أن Umbra (أو أي شخص آخر) لا يستطيع رؤية أموال المستخدمين، فهذا يعني أنه من الضروري لإرسال الأموال أن يكون لدى المرسل محفظة متوافقة مع erc-5564 (أو تطبيق Umbra) لتوليد عنوانهم الوهمي الخفي.

عندما يريد شخص ما إرسال عندما يحولون الأموال إلى مستخدم، فإنهم عادة ما يستخدمون تطبيق Umbra للقيام بذلك. في الأساس، سيبحث تطبيق Umbra عن العنوان الفي ميتا الخفية المسجل لاسم ENS / عنوان المحفظة ويولد عنوانًا خفيًا. يمكن للمستلمين تسجيل الدخول إلى تطبيق Umbra وفحص أي أموال تم إرسالها إلى عناوين خفية تنتمي إليهم منذ آخر مرة قاموا فيها بتسجيل الدخول. بفضل بعض التخزين المؤقت الذكي، يبدو أن هذا يستغرق فقط 10-15 ثانية لفحص أسبوعي، على الرغم من أن المستخدمين يمكنهم أيضًا تحديد نطاق من الكتل لتضييق الفحص. سيتضمن Umbra v2 استخدام viewtags، والتي ستسرع العملية أكثر.

بوابة

إحدى المشكلات المتعلقة بعناوين الاختفاء التي ذكرناها سابقا هو انه من اجل للمستلم ان ينفق الاموال التي تم ارسالها الى عنوان اختفاء، سيحتاج هذا العنوان ان يحتوي على إثيريوم أو رمز غاز آخر لدفع رسوم المعاملات. في معظم الشبكات، إذا تم إرسال إثيريوم الى عنوان الاختفاء في المقام الأول، فإن هذا عادة ليس مشكلة. ومع ذلك، إذا تم ارسال رمز erc-20 أو NFT الى عنوان الاختفاء، فان عملية تمويل العنوان بإثيريوم لدفع رسوم الغاز يمكن ان تربط العنوان بعناوين المستخدم الأخرى، مما يؤدي الى فقدان خصوصيته.

للتغلب على هذا، يستخدم Umbra بناء ينطوي على جهة إعادة. عندما يتم إرسال أي أصول غير ETH إلى مستخدم Umbra، يتم إرسالها في الواقع إلى عقد خاص بدلاً من إرسالها مباشرة إلى عنوان الخفاء. يمكن للمستخدمين صرف الأموال المرسلة إلى عناوين الخفاء الخاصة بهم عن طريق إرسال عملية فوق السلسلة (من تطبيق Umbra) إلى جهة إعادة Umbra، والتي ستحوّل الأموال من العقد الذكي نيابة عن المستخدم. ستقوم الجهة المعادة بخصم بعض الرموز لتغطية تكاليف رسوم الغاز، وتدعم فقط عدد معين من الرموز في البداية.

تكلفة

يُطبق عقد Umbra أيضًا رسومًا صغيرة عند تحويل الأموال على الشبكات ذات الرسوم المعاملات منخفضة، وذلك لتقليل الرسائل غير المرغوب فيها. والمنطق وراء ذلك هو أن الرسائل غير المرغوب فيها قد تزيد من تكلفة مسح المعاملات لتحديد تلك المتعلقة، ولذلك يُعتبر هذا تضحية مقبولة.

الشبكات المدعومة

يتم نشر Umbra حاليًا على شبكة Ethereum الرئيسية، بالإضافة إلى Optimism وPolygon وGnosis Chain وArbitrum.

عقد سجل Umbra لديه تصميم مثير للاهتمام. طريقة النشر تستخدم create2 ومنشئ create2 القياسي، وعنوان العقد الذكي هو نفسه على أي شبكة. هذا يعني أنه إذا كان العقد موجودًا على شبكة معينة، فإن العميل يمكنه أن يكون متأكدًا من أن هذا هو العقد الصحيح. يمكن تكوين العميل لإضافة الشبكات، ويمكن لأي شخص نشرها على أي شبكة. لقد جعلوا البايت كود القياسية والعقد ليس لديه مالك، مما يسمح بنشر سجل السجلات وعقود الإعلان على أي سلسلة من قِبل أي شخص.

الظل الإصدار 2

تطوير Scopelift حالياًالإصدار 2 من Umbra, الذي يقدم بنية معمارية محددة تسمح بتوسيع العقود الأساسية لدعم معايير الرموز الجديدة أو حالات الاستخدام غير الدفعية. باستخدام هذه البنية المعمارية الجديدة ، يمكن للمطورين الخارجيين بناء وحدات لأي نوع من معايير الرموز ، على سبيل المثال erc-1155 ، erc-7621 ، دعم erc-4337 للمدفوعات أو أي شيء آخر يمكنك التفكير فيه. حاليًا ، تدعم العقد الأساسي لـ Umbra سيناريوهين ، واحد لـ ETH ، وآخر لـ erc-20. ستدعم الإصدارة 2 العديد من السيناريوهات المختلفة.

المتاهة

متاهة هو بروتوكول لا يعتمد على EIP-5564 + EIP6538 ، ولكنه يستخدم بدلا من ذلك إثباتات المعرفة الصفرية لإضافة إخفاء الهوية والخصوصية إلى المعاملات. تصف الورقة البيضاء ل Labyrinth بأنها برامج وسيطة "zkFi": "تقدم zkFi حلا معبأ يعمل كبرنامج وسيط للخصوصية مع امتثال مدمج". يشير الامتثال المدمج إلى "إلغاء إخفاء الهوية الانتقائي" في Labyrinth ، وهو حل متطور يسمح بتجريد بعض المعاملات من الهوية لجهات فاعلة محددة مأذون لها ، أي السلطات القانونية مثل الإنتربول وما إلى ذلك مع الحفاظ على الشفافية والانفتاح.

العقود الذكية الأساسية التي يستخدمها Labyrinth تشمل بركة متعددة المعاملات ومتعددة الأصول تسمح للمستخدم بإجراء معاملات متعددة الأصول في معاملة واحدة. من أجل إنفاق الأصول، يمسح المستخدم الشبكة ويسترجع بيانات الملاحظات المشفرة، ثم يقوم بفك تشفير الملاحظات ويقوم بتصفية الأصول التي يرغب في إنفاقها. فيما بعد، يقوم المستخدم بإنشاء ZKP يتضمن المعاملات وتوقيع من المفتاح التوقيعي المرتبط بالملاحظات التي يرغب في إنفاق المعاملات منها.

تتضمن أجزاء من عقود Labrynth الأساسية عقد محول، الذي يتفاعل مع عقود بروكسي متعددة، وهي في الأساس بروكسيات لعقود خارجية. لذا على سبيل المثال: إذا أراد المستخدم استخدام Labrynth للتفاعل مع Uniswap، سيقوم المستخدم بصياغة معاملة تستخدم عقد المحول لاستدعاء عملية تبادل على بركة Uniswap عبر عقد بروكسي Uniswap.

يستخدم بروتوكول zkFi الخاص ب Labyrinth "ملاحظات" لتتبع الأرصدة والتحويلات. الملاحظة هي في الأساس بنية بيانات تصف قدرا من بعض الأصول والعنوان الذي تنتمي إليه. يقوم العميل بتخزين المعلومات اللازمة لإعادة إنشاء ملاحظة ، ويستخدمها لإنفاق الأصول. يتم تخزين الالتزام بالملاحظة (تجزئة معرف الأصل والمالك والقيمة) في شجرة merkle على السلسلة. في الواقع ، تستخدم Labyrinth شجرتي ميركل ، واحدة للملاحظات والأخرى لعناوين الجذر.

هيكل بيانات الملاحظة يحتوي على ما يلي:

• معرّف الأصل: معرّف للأصل (ETH، WBTC، MATIC، إلخ) الذي يمثل قيمة هذه الملاحظة.
• القيمة: القيمة أو المبلغ الذي يمثله الشيك.
• leafIndex: فهرس الورقة لشجرة ميركل التزام حيث سيتم إدراج هذه الملاحظة.
• الغمازة: عامل غمازة عشوائي.
• عنوان الجذر: عنوان جذر المستخدم الذي لديه السلطة لإنفاقها.
• revoker: نقطة مفتاح العام الخاصة بالملغي المختار.

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

حمام محمي

ما هو مثير حقًا في Labyrinth ، والذي يختلف قليلاً عن بروتوكولات عنوان الاختفاء العادية ، هو أن حوض الأصول في الواقع حوض محمي ، والذي يستخدم مفهوم الملاحظات لإنشاء نوع من حوض UTXO المحمي الذي يوفر سرية إلى الصفقات. تذكر أنه باستخدام تنفيذات eip-5564 ، ستتمكن الكيان الذي ينقل الأموال إليه المستخدم من رؤية مصدر تلك الأموال. بعبارة أخرى ، أليس تدفع لبوب باستخدام عنوان اختفاء ، بوب يدفع لتشارلي ، لذا يمكن لتشارلي الآن رؤية أن بوب استلم الأموال في البداية من أليس ، وهكذا. هذا ليس الحال مع حوض Labyrinth المحمي.

لفهم كيف يعمل هذا البركة المحمية، نحن بحاجة إلى النظر في كيفية نقل الأموال داخل البروتوكول:

أرصدة المستخدم في حوض المحمية هي مجموع الملاحظات للأصول المعنية. من أجل إنفاق تلك الملاحظات ، يحتاج المستخدم إلى الكشف عن "المبطلين" لتلك الملاحظات. المبطل هو فريد لملاحظة ما ، وبمجرد إنفاق تلك الملاحظة ، يتم وضع علامة على المبطل لمنع الإنفاق المزدوج ، ويتم إنشاء ملاحظة جديدة من تلك الملاحظة المنفقة. يمكن تجميع العديد من الملاحظات للأصول نفسها ، ويمكن إنشاء العديد من الملاحظات الجديدة. المبطل هو ببساطة هاش (𝑙,𝑐,𝛿) ، حيث 𝑙 هو فهرس التزام الملاحظة في شجرة ميركل للملاحظات ، و𝑐 هو التزام ، و𝛿 هو عنصر عشوائي يشار إليه أيضًا بعامل العمى.

يحدد مستلم تحويلة معاملة سرية من خلال نفس الوسائل المستخدمة في eip-5564، إذ يستمعون إلى الأحداث التي تم إصدارها من العقود الأساسية ويحددون عناوين الخفاء التي سيتمكنون من إرسال الأموال منها وتسجيلها محليًا. يتم تسريع تحديد صفقات الواردة أيضًا باستخدام علامات المشاهدة وبالتخزين المؤقت المحلي والمزامنة الغير متزامنة للملاحظات خلال فترة حياة التطبيق.

هناك بحث مستمر في جعل عملية اكتشاف الأموال المستلمة أسرع، انظر إلى هذا الاقتراح من أزتيك على سبيل المثال:طلب عروض للمقترحات: بروتوكول اكتشاف الملاحظات - أزتيك.

لإنفاق الأموال ، يتعين أيضًا على المستخدم إنشاء دليل zk ، على عكس تنفيذات erc-6654 ، والتي هي في الأساس عناوين إثيريوم العادية. يتطلب إنشاء الدليل محفظة متوافقة ، والأداء نسبيا جيد ، ويستغرق حوالي 20 ثانية تقريبًا على جهاز Android متوسط ​​المدى.

Bundler و Converter

هناك بعض الميزات الجميلة التي يقدمها Labyrinth والتي تحل بعض نقاط الألم للمعاملات الخفية. يتم إرسال المعاملات المرسلة إلى عقود Labyrinth الأساسية كعمليات مستخدم عبر عمليات تجميع erc-4337. يسمح هذا الإعداد بإنفاق الملاحظات دون ETH أو الحاجة إلى رموز الغاز للمعاملات ، حيث يمكن للمستخدم الاستفادة من erc-4337 لدفع الغاز نيابة عنهم ، مما يضيف طبقة إضافية من الخصوصية. الاستثناء الوحيد هو الإيداع الأولي الذي لا يتم تقديمه ك userop. كما أن استخدام er-4337 لدفع الغاز لديه فائدة إضافية في القدرة على دفع الغاز من خلال الأصول المنقولة ، حتى لو كانت رموز erc-20 ، وبالنسبة لهذه النقطة ، تعرض Labyrinth واجهة برمجة تطبيقات مُعدل أسعار الغاز.

ميزة أخرى لطيفة للغاية تتمتع بها Labyrinth هي بنية معيارية تسمح لعقود المحول بالعمل كوكيل لتطبيقات dapps التابعة لجهات خارجية. يتيح ذلك للمستخدمين ليس فقط تحويل الأموال باستخدام المعاملات الخفية ، ولكن أيضا للتفاعل مع dapps التابعة لجهات خارجية مثل DEXs ، (مثل Uniswap و Aave و Lido وما إلى ذلك). تنفذ عقود "المحول" الوكيل هذه بشكل أساسي وظيفة تأخذ فيها قدرا من الأصل ، ويخرج قدر معين من الأصل ، مع وجود المنطق الأساسي في بعض عقود الطرف الثالث.

حل الامتثال

يضمن Labyrinth الامتثال والالتزام التنظيمي من خلال إطار يسمى الكشف الانتقائي عن عدم التمييز (SeDe).

تذكر أن هيكل بيانات الملاحظة يحتوي على حقل يُسمى "المُلغي". الملغي هو عنوان كيان محدد يمكنه بدء عملية إلغاء التجهيز. يجب على المستخدم اختيار ملغي واحد على الأقل من قائمة محددة مسبقًا. الملغي غير مسؤول بشكل حصري عن تحديد الأنشطة غير القانونية أو الشبه قانونية، ولكنه يمكنه الاستجابة لطلبات الجهات الإنفاذية.

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

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

ريل جان

ريلجننظام الخصوصية للمعاملات الخفية هو نظام نشر على إثيريوم وشبكات أخرى مثل BSC وPolygon وArbitrum. يتشابه البروتوكول في بعض النواحي مع Labyrinth حيث يستند إلى الملاحظات التي تُخزن في شجرة Merkle كالتزامات وتشكل مجموعة UTXO، أي يمكن إنفاق الملاحظات عن طريق إنشاء ملاحظات جديدة للمستلمين الآخرين. لكي يتم إنفاق ملاحظة، يتم إضافة nullifier إلى الحالة الخاصة بتلك الملاحظة، مما يمنع الإنفاق المزدوج. يمكن لمالك الملاحظة فقط حساب nullifier الخاص بها، والذي يعتمد على تجزئة المفتاح المستخدم للإنفاق ومؤشر الملاحظات على شجرة Merkle، وهذا يعني أنه يمكن لمالك الملاحظة فقط إنفاقها (ويمكنه إنفاقها مرة واحدة فقط).

تستخدم عناوين الـ Meta الخفية في Railgun بادئة "0zk"، ومثل eip-5564، فهي تكون تركيبًا لمفتاح العرض العام ومفتاح الإنفاق العام. ومع ذلك، يستخدم Railgun مفاتيح Ed25519 على منحنى BabyJubJub بدلاً من ECDSA و secp256k1. بنفس الطريقة التي في eip-5564، يمر مستخدمو Railgun عبر جميع الأحداث المُطلقة من عقود Railgun ويستخدمون مفتاحهم للعرض لتحديد أي الأحداث تمثل تحويلات إلى محفظتهم.

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

تتمتع ريلغن ببنية وحداتية تتيح لها التفاعل مع العقود الذكية الخارجية، مما يسمح بوظائف تتجاوز بساطة التحويلات. تقوم بذلك عبر عقد AdaptRelay، الذي يحمي ويقوم بإزالة حماية الرموز قبل وبعد التفاعل مع عقد خارجي، على سبيل المثال، إزالة حماية الرمز A، وتبديله بالرمز B على بعض AMM، وإعادة حماية الرمز B إلى المالك الأصلي.

مع الإصدار 3 ، يخطط Railgun للاستفادة من eip-4337 ودعم المعاملات الفرعية التقليدية. وهم يأملون في أنه من خلال الحفاظ على حمولة ميمبول مستخدم eip-4337 مخصصة لـ Railgun ، يمكن لحل المشاكل المستقلة المشاركة كمذيعين. يتعاونون حاليًا مع Umbra في البحث في هذا الأمر ، وتحديد حالات الحافة وكيفية التعامل معها ، انظر القسم Railgun v3 أدناه لمزيد من التفاصيل.

الرسوم

بروتوكول Railgun يأخذ رسومًا قدرها 0.25٪ للإيداعات والسحوبات. يتم إرسال هذه الرسوم إلى خزينة DAO، وتدفع هذه الرسوم عبر الوقت إلى مُحامي الرمز الحاكم RAIL. بالإضافة إلى رسوم الإيداع والسحب بنسبة 0.25٪، يطبق المذيعون عادة رسومهم الخاصة أيضًا، والتي تبلغ عادة حوالي 10٪ من رسوم الغاز للمعاملة الفعلية على السلسلة.

الحوكمة

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

دليل تطوير البرامج وكتاب الطبخ

يقدم Railgun SDK شامل وموثق جيدًا يمكن لمطوري المحافظ أو التطبيقات اللامرئية استخدامه لبناء وظيفة عنوان مخفي عبر دعم لـ Railgun. كما تحتوي Railgun أيضًا على مجتمع محتفظ بهكتاب الطبخبواسطة “الوصفات” التي تتيح لمطوري التطبيقات اللامركزية توفير وحدات لرايلجان التي تسمح للمستخدمين بالتفاعل مع تطبيقهم باستخدام رايلجان. على سبيل المثال، يمكن للمطور كتابة وصفة لتبديل الرموز التي تسمح للمستخدمين الذين لديهم رصيد رموز في رايلجان بتبديل الرموز بشكل خاص.

ريلغان v3

الإصدار القادم لريلغان سيجعل المعاملات أرخص بنسبة حوالي 50% - 60%. التغييرات الأخرى في الإصدار 3 تشمل الانتقال إلى دعم عمليات المستخدم eip-4337 عبر mempool مخصص. بالإضافة إلى ذلك، سيقدم الإصدار 3 دعمًا لبنية النوايا، مما سيسمح لحلول الألغاز بالتنافس من أجل أفضل تنفيذ، على الرغم من أن التفاصيل تكون عالية المستوى جدًا في وقت الكتابة. هم يعملون حاليا معCowSwapعلى هذا وتخطط لاستخدام الخطافات السابقة واللاحقة للسماح للحلول بالوصول إلى الأموال.

ريلجن كونكت

من الممكن أن يكون التغيير الأكثر إثارة للانتباه الذي يُقترح هو شيء يُسمى Railgun Connect ، والذي يُوصف بأنه أداة مماثلة لـ WalletConnect ، حيث يتيح لعناوين 0zk الاتصال بمعظم الواجهات الأمامية للاستخدام الخاص ، دون الحاجة إلى أن يقدم تلك التطبيقات اللامركزية تكاملًا واضحًا مع Railgun عبر وحدات مخصصة.

Railgun Connect هو امتداد للمتصفح ، وما يفعله هو في الواقع تفرع حالة السلسلة محليا باستخدام HardHat تحت الغطاء ، وحقن مزود web3 الخاص به في dapp ، مع نقطة نهاية RPC لإصدار HardHat المحلي من السلسلة. يتيح لك هذا بعد ذلك إجراء التفاعلات مع عقود dapps كما تفعل عادة ، وتسجيل المعاملات ، ثم تجميعها وإنشاء دليل على snark ، وإرسالها إلى عقود Railgun الفعلية على السلسلة الحقيقية. في حين أن هذا الوصف مفرط في التبسيط قليلا ، إلا أنه ينقل الفكرة العامة. ما يفعله هذا هو أنه يسمح لك بالتفاعل بشكل أساسي مع أي dapp تقريبا (مع بعض حالات الحافة ل dapps التي تقوم بمعالجة إضافية خارج السلسلة). التحذير هو أن حفظ حالة السلسلة محليا هو عملية ثقيلة ، ولكن بمجرد الانتهاء من ذلك ، فهذا يعني أنه يمكنك التفاعل مع dapps باستخدام عناوين التخفي في Railgun دون رؤية أي فرق عن استخدام محفظة عادية.

استنتاج

هناك بعض المقترحات المثيرة للاهتمام لتثبيت عناوين الخفاء في بروتوكول إثيريوم. على سبيل المثال، إنكويستخدم فكرة "تغليف" erc-20 ، الذي يلف عقد erc-20 العادي ويشفر جميع الأرصدة. يتم إجراء عمليات التحويل والموافقات على الحالة المشفرة عبر التشفير الكامل المنزلي. تعتمد Inco على الجوانب المسبقة التي توجد حاليًا فقط على الشبكة الخاصة بها ، ولكن قد تصل يومًا ما إلى إثيريوم.

هناك أيضًا اقتراح آخر يسمىEIP-7503: الثقوب الدودية بدون معرفةالتي تعتمد على تصميم يُسمى "دليل الحرق"، على الرغم من أن هذا لا يبدو أنه يحصل على الكثير من الجذب، ربما لأنه يتطلب تحديثًا لـ EVM، دون أن يمكن تنفيذه فعليًا إلا على مستوى الرمز المميز، باستخدام تصميم erc-20 الذي يدعم eip-7503 بشكل خاص (أو إذا قررت L2 إضافة دعم لأوامر EVM الخاصة بها).

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

بالمثل،IntmaxL2 هو Ethereum (بناءً على تصميم Plasma) تركز على الخصوصية ، ولديه أيضًا جانب متوافق مع التنظيم من خلال التحقق من شرعية الأموال الفردية من خلال أدلة AML القائمة على ZKP وفرض حدود على مبالغ المعاملات. يتم تحديد Intmax فيما يتعلق بتوفير الخصوصية لعمليات النقل بينما لا تكون عمليات العقد الذكية لـ EVM خاصة. ومع ذلك ، يمكن كتابة العقود الذكية بلغة Solidity ، والتي قد يفضلها بعض المطورين (اعتمادًا على حالة الاستخدام).

دعم المحفظة

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

• هل سيقدمون دعمًا متحيزًا لتنفيذ واحد فقط، أم سيقومون ببناء وصيانة نوع من المجمع الشامل عبر عدة بروتوكولات؟ قد يكون الأخير مكلفًا للغاية من حيث التطوير والصيانة.
• هل ستكون هناك اعتبارات تنظيمية، وهل سيحتاجون إلى اتخاذ موقف بشأن مدى وآلية إزالة الإلغاء العشوائي (أي مثل Labyrinth)؟
• تتطلب عناوين الوحدة المخفية مكونًا على السلسلة (باستثناء Fluidkey)، وهذا يعني أن كل شبكة EVM يجب أن تكون مدعومة بشكل صريح من قبل المحفظة (على الرغم من أن تصميم Umbra يسهل نشر السجل بدون إذن).
• تجعل عناوين الخفية التكامل الحالي مع مستكشفي الكتل (مثل Etherscan) أكثر تعقيدًا. على سبيل المثال، لن يعمل زر "عرض على المستكشف" لعنوان ميتا مخفي، حيث يظهر المحفظة الرصيد الكلي. قد تكون هذه المشكلة موجودة أيضًا في عمليات النقل. سيتعين التفكير في الحالات الحدية المختلفة مثل هذه.
• اعتمادًا على التنفيذ الأساسي ، سيتمكن المستخدم فقط من استخدام عنوان الاختفاء بشكل فعال مع مجموعة محددة من التطبيقات اللامرئية ، وهي تلك التي يتم دعمها من قبل البروتوكول الأساسي. سيكون هذا ممكنًا مع تنظيم هندسة العناوين اللامرئية القابلة للتوسيع. ومع ذلك ، لن يتم دعم جميع التطبيقات اللامرئية ، وسيتعين على المستخدم تلقي هذا الإعلام بطريقة ما. من النسبة لبروتوكول eip-5506 ، فإن الأمر أسهل بعض الشيء ، ولكن لا يزال لديه تعقيداته الخاصة وحالات حافة، وقد يتسرب ذلك في كثير من الأحيان إلى واجهة المحفظة.

هناك أيضاً فرص لتحسينات في منع سوء نظافة خصوصية المستخدم، انظر إلى هذا الورقة: “تحليل الاستخفافية للمظلة برنامج تحديد المواقع على مخطط إثيريوم” لكيفية نجاح المؤلفين في إزالة التعريف عن 48.5٪ من المعاملات الخفية على الشبكة الرئيسية لإثيريوم. الخوارزميات التي استخدموها للقيام بذلك لم تكن لها علاقة بالبروتوكولات، وكانت أكثر حول النظافة الخصوصية، على سبيل المثال، يقوم المستخدم بإرسال الأموال إلى عنوان خفي يتحكم فيه، ثم يرسل تلك الأموال مرة أخرى إلى العنوان الذي أرسلها منه بالأصل، معتقدًا بالخطأ أن التتبع قد تم كسره. بشكل عام، حدد المؤلفون 6 خوارزميات مختلفة يمكن استخدامها لإزالة التعريف عن معاملات العنوان الخفي، تقريبًا جميعها مبنية على عدم اتباع أفضل الممارسات. ومع ذلك، هذه مشاكل تجربة المستخدم الحرجة التي يجب معالجتها.

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

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

تنصل:

1. تمت إعادة طبع هذه المقالة من [متوسط]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [سايمون براون]. إذا كان هناك اعتراضات على هذا النشر المعاد، يرجى التواصل مع بوابة تعلمالفريق، وسيتولون الأمر على الفور.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك المؤلف ولا تشكل أي نصيحة استثمارية.
3. فريق Gate Learn يقوم بترجمة المقالات إلى لغات أخرى. ما لم يتم ذكره، فإن نسخ أو توزيع أو إسناد المقالات المترجمة بشكل مماثل محظور.