تجري حوكمة Uniswap مناقشة مقترح RFC تقدمت به SilentSwap، يهدف إلى إضافة مسار تنفيذ خاص اختياري إلى واجهة Uniswap، باستخدام Uniswap v4 hooks وUniswapX لتقليل تعرّض معلومات المعاملات قبل تنفيذ المبادلة. يقدّم المقترح هذه الميزة كخيار “المبادلة بشكل خاص”، بحيث تظل المبادلات القياسية دون تغيير وتبقى رسوم المجمعات دون تأثر، عبر استخدام zk-SNARKs وفحص الامتثال قبل التنفيذ لمعالجة التداولات بشكل أكثر خصوصية. يتناول RFC مشكلة مستمرة في التمويل اللامركزي: إذ إن شفافية المبادلات على السلسلة تسمح بتسرّب نية المعاملة قبل تنفيذها، ما يمنح البوتات والمتداولين المتقدمين فرصًا للقيام بالسبق أمام التنفيذ (front-run)، أو هجمات التجميع/التحايل (sandwich)، أو استغلال المستخدمين بطرق أخرى.
مقترح SilentSwap يستهدف تعرّض MEV والسبق أمام التنفيذ
يحدد RFC أن وضوح التنفيذ يُعد مشكلة محورية في تداول DeFi. عندما يقدّم المستخدمون معاملات، قد تصبح نواياهم ظاهرة قبل اكتمال المعاملة، ما يسمح للبوتات بمراقبة المعاملات المعلّقة، وتقدير أثر السعر المحتمل، وإدراج تداولاتها الخاصة حول تداول المستخدم. يصف المقترح MEV وهجمات sandwich وتسريب التنفيذ بوصفها مشكلات راسخة في DeFi. استخدم بعض المستخدمين حلولًا لحماية أنفسهم مثل RPCs خاصة، ومجمّعات، وضوابط الانزلاق السعري، أو أدوات توجيه أكثر تطورًا، لكن يشير RFC إلى أن كثيرًا من المستخدمين لم يعتمدوا هذه الحمايات. ستجعل البنية المقترحة الحماية أسهل من مستوى الواجهة، لأن معظم المستخدمين يتفاعلون مع DeFi عبر واجهات أمامية (frontends) وليس مباشرة عبر العقود.
Hooks في Uniswap v4 تمكّن منطق تنفيذ مخصص
يستفيد RFC من Uniswap v4 hooks باعتبارها عنصرًا أساسيًا في البنية المعمارية المقترحة. تتيح الـhooks للمطورين تخصيص سلوك المجمع ومنطق التنفيذ حول المبادلات، بما يدعم أنواعًا جديدة من التوجيه والرسوم ومعالجة الأوامر وميزات مرتبطة بالخصوصية. في هذا المقترح، تأتي hooks الخاصة بالإصدار v4 ضمن البنية المقترحة للتنفيذ الخاص. كما يدمج RFC UniswapX، الذي يتولى بالفعل إدارة تنفيذ مبادلات أكثر مرونة ووجود “معبّئين” خارجيين. ومن شأن الجمع بينهما أن يمنح المستخدمين مسارًا تكون فيه تفاصيل معاملاتهم أقل تعرّضًا قبل التنفيذ، مع الاستمرار في استخدام سيولة Uniswap وواجهته.
يجمع RFC بين بنية الخصوصية وفحص الامتثال قبل التنفيذ
يربط المقترح بين الخصوصية وفحص الامتثال قبل التنفيذ. يصف RFC هذا الربط بأنه يعكس تطور الخصوصية الحالي في DeFi، حيث يريد المستخدمون الحماية من السبق أمام التنفيذ وتسرب البيانات، بينما تسعى الجهات التنظيمية والبروتوكولات إلى تجنب إنشاء أدوات تمكّن من نشاط مُدان أو إساءة الاستخدام. يستخدم المقترح zk-SNARKs وفحص الامتثال لمعالجة التداولات. ويذكر RFC أن هذا النهج يحاول حماية المستخدمين الشرعيين مع السماح بنوع من التحكم في الامتثال.
يظل المقترح قيد مرحلة المناقشة دون موافقة
يُعد RFC مقترح مناقشة وليس منتجًا حيًا أو تغييرًا حوكميًا تمت الموافقة عليه. لا تزال حوكمة Uniswap بحاجة إلى مناقشة ما إذا كان التصميم منطقيًا، وما إذا كان التنفيذ التقني آمنًا، وما إذا كانت افتراضات الامتثال مقبولة، وما إذا كانت تجربة المستخدم واضحة، وما إذا كانت الميزة تخلق أي مخاطر جديدة على البروتوكول أو الواجهة. يعترف RFC بوجود مخاوف محتملة بشأن التعقيد، وافتراضات الثقة، ومقدمي الفحص، والتعرّض القانوني، والتكلفة، وما إذا كان المستخدمون يفهمون معنى “الخصوصي” فعليًا. يستند المقترح إلى RFC حوكمة Uniswap حول خصوصية التنفيذ الأصلية عبر v4 hooks وUniswapX.
الأسئلة الشائعة
ما الذي تقترحه RFC الخاصة بـ Uniswap؟
تقترح RFC التي قدمتها SilentSwap إضافة مسار تنفيذ خاص اختياري إلى واجهة Uniswap باستخدام Uniswap v4 hooks وUniswapX. سيتم عرض الميزة كخيار “المبادلة بشكل خاص”، مع ترك المبادلات القياسية ورسوم المجمعات دون تغيير، مع استخدام zk-SNARKs وفحص الامتثال قبل التنفيذ.
لماذا تتناول RFC خصوصية المبادلة؟
يحدد RFC أن شفافية المبادلات على السلسلة تسمح بتسرّب نية المعاملة قبل التنفيذ، ما يمنح البوتات والمتداولين المتقدمين فرصًا للسبق أمام التنفيذ أو تنفيذ هجمات sandwich أو استغلال المستخدمين بطرق أخرى عبر MEV وتسريب التنفيذ.
ما هي الحالة الحالية للمقترح؟
المقترح هو RFC في مرحلة المناقشة. لا يمثل ميزة حية أو تغييرًا حوكميًا معتمدًا، ولا تزال حوكمة Uniswap بحاجة إلى تقييم التصميم والتنفيذ التقني وافتراضات الامتثال والمخاطر المحتملة.
