Polymarket V2 تم إطلاقه، هل تم إصلاح الطلبات الوهمية؟

محتوى أصلي | صحيفة Odaily Planet (@OdailyChina)

المؤلف | أشر (__@Asher 0210_)

昨晚，Polymarket 进入维护窗口，暂停交易并清空订单簿，随后正式上线 CLOB V2。

وفقًا للإفصاحات السابقة من قبل الرسميين، يشمل هذا التحديث عقود جديدة، ودفتر أوامر جديد، ورمز ضمان جديد Polymarket USD، وSDK لعميل CLOB الجديد. بالنسبة للمستخدمين، قد لا تكون التغييرات في PUSD، وSDK، وهيكلية الطلب واضحة على الفور. الأمر الحقيقي الذي يستحق الانتباه إليه في الوقت الأول هو مشكلة Ghost Fills التي طالما أزعجت Polymarket، والمعروفة أيضًا باسم “طلبات الأشباح” من قبل المجتمع.

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

عرض الصفقة، لماذا فشلت في النهاية؟

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

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

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

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

مشكلة الإصدار القديم، هي انخفاض تكلفة إلغاء الطلب

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

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

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

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

V2 أجرى إصلاحات، لكنه لم يقض عليها تمامًا

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

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

بشكل عام، توجه V2 واضح: معالجة أكثر النقاط عرضة للاستغلال أولاً، ثم تقليل عائدات الهجمات المماثلة.

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

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

تحديثات أخرى، أكثرها دعمًا لنظام التداول

بالإضافة إلى طلبات الأشباح، قدم V2 تحديثات تتعلق بـ PUSD، وSDK، وتوقيع 1271:

• PUSD هو عملة ضمان مستقرة جديدة، حيث انتقلت Polymarket من USDC.e إلى Polymarket USD المدعوم بنسبة 1:1 من USDC، وهو تغيير غير ملحوظ للمستخدمين العاديين، لكنه يوحد الأصول الأساسية؛
• SDK لعميل CLOB الجديد يركز بشكل رئيسي على صانعي السوق، والروبوتات، والتكاملات النظامية. بعد V2، يتعين على المستخدمين تحديث عملائهم وإعادة توقيع الطلبات باستخدام الهيكلية الجديدة؛
• دعم توقيع 1271، يعني أن محافظ العقود الذكية، والحسابات متعددة التوقيع، والحسابات المؤسسية، والمحافظ المعقدة يمكنها الوصول بشكل أكثر سلاسة إلى Polymarket.

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

V2 ليست النهاية، بل بداية الاستمرار في الإصلاح

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

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

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

المحتوى ذات الصلة

Polymarket المحتجز: الاختبار الحقيقي أمام تدفق المستخدمين يأتي الآن