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

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

مقدمة: حمامات مظلمة في التمويل التقليدي

على الرغم من أنه يبدو مرعبًا وغير قانوني ، إلا أن حمامات الظلام في الواقع هي جزء طويل الأمد من نظام التمويل التقليدي (المنظم بشكل كبير). فيما يلي تعريف لحوض ظلامي من Investopedia:

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

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

دفتر الطلبات في سوق الأوامر المحدودة المركزية (CLOB) هو علني.مصدر)

فلنفترض أن أليس تضع أمرًا لبيع 500 سهم تسلا على بورصة. إن هذا أمر صغير لن يكون له تأثير يذكر على سعر أسهم تسلا المعروضة في البورصة. ومع ذلك، فإن أليس تضع أمرًا لبيع 10 مليون سهم من أسهم تسلا هو أمر مختلف تمامًا.

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

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

التداول الأمامي

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

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

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

تلاشي الاقتباسات

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

لتجنب شراء الأسهم بقيمة 200 دولار فقط لمشاهدة قيمتها تنخفض، يقوم صانع السوق بإلغاء أو تعديل أمر الشراء بسرعة. هذا الإجراء، المعروف باسم تلاشي الإقتباس، يزيل السيولة بشكل فعال من السوق. عندما ينفذ أمر البيع الخاص بأليس أخيراً، يكون هناك أقل عدد من المشترين المتبقين، وعليها أن تتسوق بسعر أقل - ربما 195 دولار بدلاً من 200 دولار.

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

لماذا البرك المظلمة؟

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

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

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

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

يمكننا رؤية كيف تحمي التداول عبر حوض السوق المظلم مصالح أليس وتزيد من جودة التنفيذ ويقين سعر التسوية:

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

اليوم، هناك العشرات من حمامات السباحة في التشغيل وتقديرات تشير إلى أن 40 في المئة من التجارات الإلكترونية تتم عبر حمامات السباحة الداكنة. تزامن شعبية حمامات الظلام المتزايدة مع تنظيم متزايد، خاصةً في ضوء وصول مشغلي حوض إلى معلومات امتيازية حول الطلبات المعلقة (تم تغريم Credit Suisse و Barclays مبلغ 150 مليون دولار في عام 2016 بتهمة تسريب معلومات حول تداولات حوض الظلام لأطراف خارجية).

برك الظل في DeFi

(مصدر)

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

• يمكن للعقد المؤرشف الاستعلام عن سلسلة الكتل للحصول على معلومات حول المعاملات التاريخية التفاعلية مع بركة AMM ومقارنتها بالأنشطة المرتبطة بعنوان معين على السلسلة. يجعل هذا الأمر بسيطًا لأي شخص نسخ استراتيجيات التداول التي يعتمدها المتداولون ألفا.
• يعتبر مسلسل الذاكرة الذي يخزن المعلومات حول المعاملات المعلقة عامًا ومتاحًا لأي شخص متصل بعقد كامل. وهذا ما يجعل مستخدمي DEX عُرضة لمشكلة تلاشي الاقتباس حيث يلغي الناس أوامر الشراء / البيع ردًا على تداول كبير قادر على تحريك السوق ويؤدي إلى تنفيذ أسوأ الأسعار للتجار.
• يمكن حساب حالة ما بعد DEX بشكل تافه من قبل أي شخص يراقب mempool ، مما يفتح الباب أمام استخراج MEV الضار (القيمة القصوى القابلة للاستخراج) بواسطة المدققين وروبوتات MEV. يمكن لهذه الجهات الفاعلة مراقبة تأثير التجارة على مجمع DEX وتقرر إجراء المعاملة مسبقا أو شطيرة إذا كشفت محاكاة تغييرات الحالة عن أرباح محتملة. (أن يرسل المستخدمون المعاملات "بشكل واضح" لإدراجها في كتلة يضاعف المشكلة.)
• قد تفشل عملية تداول DEX إذا قام منتج الكتلة برقابة عمدًا على معاملة المستخدم. نظرًا لأن معلومات الحساب متاحة للجميع، يمكن للمحققين بناء ملفات تعريفية لعناوين محددة والاختيار في التمييز ضد تلك المقابلات عند معالجة المعاملات.
• قد يرى المحققون معلومات حول صفقة ويقررون استبعادها من الكتلة التالية. لا يمكن للمستخدمين تشويش تفاصيل الصفقة عن المحققين أو تجنب الكشف عن النية في شراء/بيع الرموز.

(مصدر)

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

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

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

كيف تعمل حمامات السوائل المظلمة؟

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

الحساب متعدد الأطراف (MPC) ، وبراهين المعرفة الصفرية ، وتشفير العتبة ، والتشفير المتماثل بالكامل (FHE) ، وبيئات التنفيذ الموثوقة (TEEs) هي بعض الأوليات المتاحة لمصممي الآليات الذين يعملون على تجمعات مظلمة أصلية مشفرة. الهدف في كل حالة هو الحفاظ على الضمانات حول الخصوصية التجارية دون زيادة افتراضات الثقة أو جعل النظام عرضة للتلاعب.

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

Renegade: تسريع DeFi الخاص بتقنية التشفير الحديثة

Renegade عبارة عن تجمع مظلم لامركزي يحافظ على الخصوصية مصمم لمعالجة العيوب الحرجة في المشهد التجاري الحالي للتمويل اللامركزي (DeFi). من خلال الاستفادة من تقنيات التشفير المتقدمة مثل إثباتات المعرفة الصفرية (ZKPs) والحساب متعدد الأطراف (MPC) ، يسمح Renegade للمستخدمين بوضع الأوامر ومطابقتها وتسويتها بأمان دون الكشف عن أرصدتهم أو نوايا التداول أو الاستراتيجيات لأطراف ثالثة. على عكس DEXes التقليدية ، التي تعرض بيانات دفتر الطلبات للتدقيق العام ، يقوم Renegade بتشفير جميع معلومات المحفظة والطلبات ، مما يضمن حدوث الصفقات بشكل خاص ومقاومة للتلاعب.

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

معالجة مشاكل أنظمة DeFi الحالية

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

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

القيمة الاستخراجية القصوى (MEV)

متوسط أرباح MEV الإجمالية (مجموعة بيانات 30 يومًا) وفقًا لـ EigenPhi

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

شفافية التداول

شفافية دفاتر الأوامر القائمة على تقنية البلوكشين تعرض المتداولين لمخاطر قبل التداول وبعده:

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

من خلال دمج هذه في فئة أوسع واحدة، يعالج Renegade دورة حياة قضايا شفافية التداول بحلول تشفيرية تضمن الخصوصية قبل التداول وتسوية مشاركة ما بعد التداول.

تحليل البيانات الأساسية للعناوين

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

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

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

لحل هذه المشكلات ، يستبدل Renegade الشفافية بالخصوصية المسيطرة من خلال الاستخدام المشترك للأدلة بدون معرفة (ZKPs) والحساب متعدد الأطراف (MPC). تضمن ZKPs أن المعاملات صالحة والأرصدة كافية وقواعد البروتوكول مفروضة دون الكشف عن محتويات المحفظة أو تفاصيل العملية. في الوقت نفسه ، يمكن لـ MPC تمكين مطابقة الأوامر الآمنة ، حيث يتعاون عدة أطراف لإيجاد تطابقات تجارية دون الكشف عن أي مدخلات أو تسريب معلومات حساسة.

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

بفهم واضح للمشاكل التي يحلها Renegade ونهجه في الخصوصية، دعنا نتعمق في كيفية عمل النظام لتوفير تداول آمن وخاص وعادل.

كيف يعمل رينيجيد تحت الغطاء؟

يعيد رينيجاد التفكير في التداول اللامركزي من خلال دمج تقنيات التشفير المتقدمة التي تعيد تعريف حدود الشفافية والخصوصية والعدالة في DeFi. من خلال معالجة القيود الموجودة في التبادلات اللامركزية التقليدية ، يقدم رينيجاد نهجًا مبتكرًا يجمع بين تقنيات الحفاظ على الخصوصية مع التداول اللامركزي والمعتمد على الثقة.

تقدم هذا القسم نظرة أقرب على المكونات المعمارية الفريدة التي تدعم Renegade. سنستكشف:

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

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

محافظ Renegade وشجرة الالتزام

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

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

مقارنة: المحافظ كميني-روبس

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

تعمل المحافظ المتمردة بطريقة مشابهة لافتة للنظر:

• التنفيذ خارج السلسلة: تحدث جميع عمليات المحفظة - مثل وضع الأوامر وتحديث الرصيد وتنفيذ التجارة - خارج السلسلة. يتم تعكس هذه التحديثات في الحالة الخاصة للمحفظة، والتي لا يمكن الوصول إليها من قبل المراقبين الخارجيين، بما في ذلك Ethereum.
• التزام على السلسلة: بعد تحديث حالة المحفظة ، يتم إضافة التزامها الجديد إلى شجرة الالتزام. يعمل هذا الالتزام كملخص تشفيري لأرصدة المحفظة الجديدة ، والطلبات ، وأي تغييرات تم إجراؤها خلال عملية التحديث. يتم مرافقة التحديث بـ ZKP ، مما يضمن أن الانتقال من حالة المحفظة القديمة إلى الجديدة صالح.

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

نظام الكشف والتأكيد لتحديثات المحفظة

يتبع كل عملية على محفظة في Renegade نظام commit-reveal، مما يضمن الخصوصية والصحة طوال عملية التحديث. يتيح هذا الآلية للمستخدمين تعديل محافظهم مع الحفاظ على سلامة النظام.

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

يتم تقديم العوامل المبطلة إلى جانب التزام المحفظة الجديدة لضمان عدم إمكانية إعادة استخدام المحفظة القديمة.

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

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

(المصدر: توثيق رينيغيد)

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

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

نظام التسلسل الهرمي للمفاتيح والمحول

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

كيف يعمل تسلسل المفاتيح

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

• زوج مفاتيح الجذر: زوج مفاتيح الجذر هو زوج مفاتيح ECDSA (منحنى secp256k1)، مماثل لمفتاح خاص Ethereum القياسي. إنه الرئيسي بشكل كبير ويمنح حجزاً كاملاً على المحفظة. تتطلب جميع العمليات التي تعدل حالة المحفظة—مثل الإيداعات، والسحب، ووضع الطلبات، أو الإلغاءات—توقيعًا من المفتاح السري الجذري. لضمان أقصى درجات الأمان، يُحتفظ بمفتاح الجذر على النحو الأكثر صرامة على الجانب الخاص للعميل ولا يتم مشاركته مع أي جهة خارجية، بما في ذلك الوسطاء.
• المباراة المجزأة: المباراة المجزأة هي قيمة مجزأة سرية محددة على منحنى bn254 وتعمل كآلية يتم بموجبها تخويل المشغلين بإرسال مباريات للتسوية إلى العقد الذكي أو الطبقة الأساسية. على عكس أزواج المفاتيح اللاسيمترية التقليدية ، فإن المباراة المجزأة هي قيمة سرية واحدة يستخدمها المشغلون لإنشاء الأدلة الصفرية المعرفة (ZKPs) ، وتثبت معرفتهم لصورة مسبقة للمباراة تحت تجزئة Poseidon. يضمن هذا أن المشغلين يمكنهم فقط تسوية المباريات التي تم تخويلها صراحة بواسطة تكوين المحفظة. بالإضافة إلى ذلك ، يتم إقران المباراة المجزأة برسوم محددة مسبقًا في المحفظة ، مما يتيح للمستخدمين تحديد الرسوم الدقيقة التي يمكن للمشغلين تطبيقها على خدماتهم.
• مفتاح واجهة برمجة التطبيقات المتماثل: مفتاح واجهة برمجة التطبيقات المتماثل هو أداة خارج بروتوكولية تُستخدم للمصادقة على التفاعلات بين المستخدم والموفر. يتيح للموفرين بث تحديثات فورية ، مثل تغييرات المحفظة أو حالات الطلب ، إلى المستخدم دون المساس بأمان المحفظة أو سلامة التشفير الخاصة بها. على الرغم من عدم الارتباط المباشر بعمليات المحفظة ، يُسهّل هذا المفتاح التواصل السلس ويحسن تجربة التداول العامة.
• البذور العمياء والمشتركة: البذور العمياء والمشتركة هي مكونات أساسية تتيح للوسطاء فك تشفير ومعالجة معلومات المحفظة بشكل آمن. تعمل هذه البذور كمفاتيح عرض، مما يمنح الوسطاء القدرة على الوصول إلى الحالة الخاصة للمحفظة. ومع ذلك، كبذور، فإنها تتم مجزأتها بشكل ديناميكي إلى قيم تتغير مع كل عملية. وهذا يضمن أن قيم البذور العمياء والمشتركة محددة للعملية الحالية، مما يمنع أي إعادة استخدام أو وصول غير مقصود.

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

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

كيف تعمل الوسطاء في رينيجيد

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

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

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

تقدم Relayers أيضًا راحة كبيرة لعملية التداول من خلال التعامل مع التعقيد الحسابي لمطابقة الطلبات باستخدام محرك المطابقة MPC وضمان صحة هذه المطابقات من خلال SNARKs التعاونية. يسمح لهذا الآلية للمحللين بتخفيف العبء التقني عن المستخدمين بينما يحتفظ بضمانات الخصوصية الصارمة لـ Renegade قبل التداول وبعده. من خلال إدارة هذه العمليات بشكل آمن، لا تحمي Relayers فقط تفاصيل المحفظة الحساسة أثناء مطابقة الطلب والتسوية ولكن أيضًا تخفف العديد من التحديات التي تترتب عادة على أنظمة الحفاظ على الخصوصية. تعزز قدرتهم على تقديم تحديثات في الوقت الحقيقي من خلال مفتاح واجهة برمجة التطبيقات المتماثل أيضًا تجربة المستخدم، مما يضمن أن يظل المستخدمون على علم بصفقاتهم وحالة المحفظة دون المساس بالأمان.

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

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

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

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

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

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

كيف يتم تطابق الطلبات في رينيجيد

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

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

يقوم المستخدم بإنشاء طلب

تبدأ رحلة مطابقة الطلبات في Renegade بتفاعل المستخدم مع الواجهة لإنشاء طلب. يتضمن ذلك تحديد المعلمات الرئيسية مثل زوج التداول (على سبيل المثال ، WETH / USDC) والكمية التي يرغبون في تداولها. على عكس الأنظمة التقليدية ، لا يدعم Renegade أوامر الحد - نظرا لأن Renegade ليس دفتر أوامر حد مركزي (CLOB) ويهدف إلى تجنب التعقيد غير الضروري - بدلا من ذلك ، يتم ربط كل أمر بنقطة المنتصف ، مما يعني أن التجارة تنفذ عند منتصف السبريد السائد في البورصات الرئيسية مثل Binance و Coinbase و OKX و Kraken. بمجرد تحديد السعر باستخدام بيانات من أماكن متعددة ، يؤكد المستخدمون تفاصيل طلباتهم ، ويقوم برنامج المحفظة بتحديث الحالة بسلاسة لتعكس الطلب الجديد مع الالتزام ببنية Renegade التي تحافظ على الخصوصية.

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

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

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

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

يعالج الريليه الأمر

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

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

بعد الوصول إلى حالة المحفظة، يقوم الوسيط ببناء توجيهة للتواصل الآمن مع شبكة Renegade. تحتوي هذه التوجيهة على:

• التزامات تشفيرية لتفاصيل الطلب (على سبيل المثال، زوج الرمز، الكمية، السعر).
• جملة بدون اكتشاف، تثبت تشفيريا أن الطلب صالح بموجب قواعد البروتوكول دون كشف تفاصيل حساسة مثل أرصدة المحفظة أو تفاصيل الطلب.
• البيانات الوصفية الإضافية المطلوبة لفحص التوافق مثل الرسوم وتفضيلات التسوية.

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

(مصدر: توثيق المتمرد)

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

مطابقة الطلبات

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

(المصدر: وثائق المتمرد)

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

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

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

(المصدر: توثيق رينيجاد)

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

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

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

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

بمجرد التحقق من البرهان التعاوني SNARK وفتح تعميمة المباراة المشفرة، يتم الانتقال إلى مرحلة التسوية. في هذه النقطة، يتم التحقق بالكامل من الأوامر المطابقة وجاهزيتها للتسوية، مع تجميع تفاصيل التجارة بشكل آمن والتحقق منها. هذا التكامل السلس لـ MPC و Collaborative SNARKs يضمن أن عملية المطابقة في Renegade ليست فقط خاصة وآمنة ولكنها أيضًا غير معتمدة على الثقة ومحمية من التلاعب، مما يضع معيارًا جديدًا للتداول اللامركزي.

تأكيد التجارة

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

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

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

الأداء والقابلية للتوسعة

يتناول هذا القسم تحديين أساسيين ينشأان من خيارات تصميم رينيغيد المبتكرة:

• تكاليف الحوسبة لـ MPC و SNARKs: تنازلات في الكفاءة ومطالب الموارد المقدمة من قبل هذه التقنيات التشفيرية المتقدمة.
• قابلية التوسع لشبكة الشخص الوسيط: كيف تدير البنية التحتية للنظير إلى النظير لـ Renegade مستويات تداول عالية وتتكيف مع احتياجات المستخدمين المتغيرة.

دعونا استكشف كل واحدة من هذه بالتفصيل.

تكاليف الحوسبة لـ MPC و SNARKs

تعتمد هندسة Renegade بشكل كبير على محرك MPC ودليل SNARK التعاوني لتوفير خصوصية وأمان لا مثيل لهما. ومع ذلك، تأتي هذه التقنيات الكريبتوجرافية المتقدمة مع مطالبات حسابية كبيرة. يتطلب عملية MPC من الوسطاء أن يؤدوا حسابات مشفرة على المدخلات المشاركة بشكل سري، والتي تنطوي على جولات متعددة من الاتصالات والحسابات الآمنة لتقييم توافق الطلبات. هذا يتسبب في تكاليف كبيرة مقارنة بالأنظمة التي تعتمد على نظام التوافق التقليدي، خاصة عند معالجة الصفقات المعقدة أو عالية الحجم.

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

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

قابلية التوسع لشبكة المرسل

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

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

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

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

(المصدر: وثائق Renegade)

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

استنتاج

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

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

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

تنصل:

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