«HFT Layer-1» ليست كريبتو أسرع. إنها دفتر قواعد جديد لبورصة.

كل بضع سنوات، يحاول أحدهم «تسريع الأسواق» عبر تغيير البنية التحتية الأساسية. العرض يكون دائمًا تقنيًا: زمن كمون أقل، سعة أعلى، قفزات أقل، وتجربة مستخدم أفضل.

لكن في اللحظة التي تزيل فيها الطابور العام، أنت لا تسرّع blockchain فحسب. أنت تكتب دفتر قواعد جديدًا لبورصة.

عمليًا، الـ public mempool هو شكل فوضوي وغير مثالي من الشفافية. الجميع يرى غرفة الانتظار، ويمكنهم استنتاج ما قد يحدث لاحقًا. عندما تستبدله بتدفق معاملات streamed وبـ preconfirmation، تنقل سلطة الترتيب إلى أعلى السلسلة، إلى يد من يتحكم بالقبول وبالتسلسل. عندها تصبح تلك الجهة طبقة مطابقة بحكم الواقع، سواء سمّت نفسها validator أو sequencer أو builder أو غير ذلك.

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

هذه المقالة منظور تشغيلي «خالٍ من التقادم» لتصاميم «HFT Layer-1». ليس كاستعراض كريبتو، بل كبنية سوق.

التغيير التقني الذي يتحول إلى تغيير في governance

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

أزِله، وستخلق لا تماثلًا معلوماتيًا مقصودًا. يصبح لديك مدخل خاص، وpreconfirmation وهو عمليًا وعدٌ بشأن ترتيبٍ مستقبلي، وتدفق streamed وهو عمليًا تغذية مميّزة.

عندها، لم يعد المنتج الأساسي «blockspace». المنتج يصبح:

• سياسة الترتيب: من يدخل أولًا وتحت أي قواعد.
• التخصيص: كيف تُباع الأولوية أو تُكتسب أو تُوزّع.
• إدارة النزاعات: ماذا يحدث عندما تتعارض preconfirmation مع الإدراج النهائي.
• المساءلة: من يمكنه إثبات ما حدث لاحقًا، وبأي أدلة.

ولهذا ينبغي تقييم هذه التصاميم كما لو أنك تطلق بورصة، لا كما لو أنك تقارن رسمًا بيانيًا لقياسات الأداء.

عندما يصبح الترتيب خاصًا، تتحول MEV إلى «نموذج العمل»

يميل المشغّلون إلى التعامل مع MEV كأنه خلل. في أنظمة الترتيب الخاص، يكون غالبًا نموذج العمل، حتى لو لم يُسمَّ بذلك.

إذا كانت جهة واحدة تتحكم بالترتيب ويمكنها الالتزام بـ preconfirmation، فهي تتحكم بالفرق بين «رأيت التدفق أولًا» و«تفاعلت أولًا». هذا الفرق هو الـ spread. قد يظهر كرسوم صريحة، أو انزلاق ضمني، أو تسعير أولوية معتم. وفي كل الحالات، هناك من يجمعه.

لا توجد سوى ثلاثة مآلات قابلة للاستدامة:

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

بلغة مجلس الإدارة، السؤال ليس «هل هي سريعة؟» بل «من يملك الترتيب، وما الذي يمنعه من فرض ضريبة على الجميع؟»

الأسواق الأسرع تحتاج ضوابط بمستوى الوساطة، لا المزيد من TPS

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

• حدود مخاطر ما قبل التداول: ليس بعد التنفيذ؛ قبله. الحد الأقصى لحجم الأمر، والحد الأقصى للقيمة الاسمية، والحد الأقصى لمعدل الرسائل، والحد الأقصى للتعرض المفتوح.
• خنّاقات الائتمان: ماذا يحدث عندما يعمل وكيلٌ على رأس مال مفوّض. تحتاج خطوط ائتمان ديناميكية، لا أرصدة ثابتة.
• مفاتيح إيقاف: لكل حساب، ولكل استراتيجية، ولكل API key، وعلى مستوى المنصة. ليس «إيقاف السلسلة». بل زر توقف دقيق. كتبت عن هذا النمط التصميمي في قيمة الذكاء الاصطناعي وزر الإيقاف، وهو ينطبق هنا أيضًا.
• المراقبة: كشف التلاعب، أنماط التسعير المسيئة، سلوك wash، ألعاب ما بين المنصات. إن لم تستطع كشفه فأنت تدعمه ضمنيًا.
• إجراءات إدارة الحوادث: عندما تفشل preconfirmations، أو تنحرف الساعات، أو يسيء sequencer التصرف، أو تحدث تجزئات في الشبكة. «سنصلحها» ليست خطة.

عندما بنيت IBHQ، وهي منصة SaaS لأعمال Introducing-Broker، كان الموضوع المتكرر هو طبقات التحكم. الوسطاء ينجون أو ينهارون وفق بوابات المخاطر، لا وفق واجهات جميلة. قد تكون المنصة سريعة، لكن إن لم تستطع إنفاذ الحدود عند نقطة القبول، فستسلم المفاتيح في النهاية لأكثر التدفقات عدوانية. ثم يدفع الآخرون الثمن عبر انفجارات مخاطرة، أو clawbacks، أو تكاليف خفية.

السرعة بلا بوابات ليست ابتكارًا. إنها رافعة.

عدسة قرار بسيطة: من هو الحكم، وهل يمكننا تدقيق المباراة؟

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

1) ما هي سياسة الترتيب، بلغة مباشرة؟

إذا كانت الإجابة تحتاج whitepaper لفكها، فلديك مشكلة governance. قواعد الترتيب يجب أن تكون قابلة للشرح للجنة مخاطر خلال خمس دقائق.

2) كيف تُخصَّص الأولوية، وهل يمكن التحقق منها؟

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

3) ما هو نموذج النزاع بين preconfirmation وfinality؟

preconfirmation وعد. والوعود تحتاج آليات جبر. ماذا يحدث عندما يُكسر الوعد؟ من يدفع؟ كيف تُنتَج الأدلة؟ إذا كان العلاج الوحيد هو «social consensus»، فأنت تدير ناديًا لا سوقًا.

4) أين تعيش بوابات المخاطر، ومن يتحكم بها؟

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

5) كيف تقيس جودة التنفيذ دون الاعتماد على تقارير ذاتية؟

تحتاج مؤشرات مستقلة، لا مجرد TPS. فكّر في توزيعات الانزلاق، وقابلية التنبؤ بالإدراج، وفاعلية الإلغاء، وسلوك الذيل تحت الضغط.

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

الحقيقة غير المريحة: المشاركون سيقبلون بالمركزية إذا كانت القواعد نظيفة

يفترض كثير من البنّائين أن المستخدمين لا يهتمون إلا باللامركزية كمبدأ. عمليًا، المشاركون الجادون يهتمون بـ:

• جودة التنفيذ.
• قواعد قابلة للتنبؤ.
• مخاطر نزاع منخفضة.
• مسار رجوع واضح عندما تتعطل الأمور.

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

لكن ذلك لا ينجح إلا إذا تعاملت المنصة مع الترتيب وpreconfirmation كسطوح «منظَّمة» تشغيليًا، حتى لو لم يفرض منظم ذلك. بعبارة أخرى: عليك أن تحكم نفسك كبورصة لأنك عمليًا تصبح كذلك.

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

رأيي: صمّم دفتر القواعد أولًا، ثم أطلق السرعة

«HFT Layer-1» ليست ترقية أداء. إنها إعادة تصميم لسوق. الفائزون لن يكونوا الفرق ذات أفضل قصة عن زمن الكمون. سيكونون الفرق القادرة على الإجابة، تشغيليًا، عن: من يتحكم بالترتيب، وكيف تُقيَّد الريوع، وكيف تُدار حالات الفشل.

إذا كنت تبني واحدة، فلا تبدأ بالسعة. ابدأ بـ governance: سياسة ترتيب، وتخصيص قابل للتدقيق، وآليات نزاع، وبوابات مخاطر تعمل تحت الضغط.

إذا كنت تدمج مع واحدة، فلا تبدأ بالاتصال. ابدأ بقياس جودة التنفيذ، وأطر الحدود، وkill switch يمكنك تفعيله بإجراء واحد.

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