Solana أصبحت سريعة بما فيه الكفاية، والحجم كبير بما فيه الكفاية. فهل هو حقًا "كافٍ"؟
عندما نتأمل تلك التداولات، هناك سؤال دائم الوجود: هل هذه التداولات تخلق قيمة حقًا؟
إن حجم كبير من التداولات في Solana لا يأتي من طلبات حقيقية للتداول، بل من المتداولين عالي التردد الذين يستغلون الفجوات المعلوماتية التي تبلغ مللي ثانية لتحقيق الأرباح. هؤلاء "المتداولون السامين" (Toxic-takers) يستغلون المزايا التقنية، وعندما يكون صانعي السوق (Maker) على وشك سحب أوامرهم، يزيدون Gas ليجعلوا تداولاتهم تُحزم أولاً، مما يُكمل عملية التحكيم، مما يؤدي إلى تحمل صانعي السوق للخسائر. لتعويض الخسائر، لا يمكن لصانعي السوق إلا توسيع الفارق بين سعر الشراء وسعر البيع.
في النهاية، يدفع المستخدمون العاديون ثمن ذلك. لطالما كانت لدى Solana حلم بتحقيق دفتر الطلبات على السلسلة، ليحل محل CEX. ولكن بهذا، أصبح "المتداولون السامون" عقبة أمام تحقيق الحلم. هذه هي التحدي الجديد الذي تواجهه Solana: الحجم ≠ السيولة. السوق الصحي الحقيقي لا يحتاج إلى المزيد من الصفقات، بل يحتاج إلى صفقات أفضل.
كيف يمكن إزالة المعاملات الضارة بشكل أفضل لحماية السيولة؟
في النظام الحالي، يتمتع آكلو الطلبات (Takers) بأولوية فعلية بسبب آلية مزاد دورات إجماع Solana، مما يتيح لتأثير MEV الضار التأثير على عدالة السوق.
كيف نفهم؟
في إجماع Solana الحالي، يتم ترتيب المعاملات داخل كل فترة زمنية Slot وفقًا لأولوية رسوم الغاز المدفوعة، فمن يقدم عرضًا أعلى يتم تنفيذ معاملته أولاً. هذه المزاد دوري، كل 400 مللي ثانية Slot.
في هذه العملية، يحتاج صناع السوق إلى تعديل الاقتباسات بشكل متكرر، وإلغاء الطلبات، وإعادة إدخال الطلبات. عند تغير سعر السوق، يجب تحديثه على الفور.
والمتناولون (Taker) ، وخاصة المتداولون ذوو التردد العالي ، يراقبون فرق الأسعار ويقومون بإجراء الصفقة فور اكتشاف الفرصة. وبالتالي ، يمكن للمتداولين ذوي التردد العالي أن يتخذوا إجراءً من خلال دفع رسوم أعلى لإتمام الصفقة قبل إلغاء الطلب. مما يؤدي إلى أن يتعرض صانعو السوق في كثير من الأحيان إلى "استهداف" ويتحملون الخسائر.
بالنسبة لدفتر الطلبات DEX، يجب أن يكون الترتيب المثالي هو أنه مع تقلبات الأسعار، يتم تنفيذ جميع عمليات الإلغاء أولاً، ثم يتم تنفيذ الطلبات الجديدة، وأخيرًا يتم تنفيذ الصفقات. وهذا ما لا يمكن أن يحققه إجماع Solana حاليًا على المستوى الجزئي.
وفي مستوى تسعير الأوراق المالية، نفس الشيء ينطبق، حيث أن السيناريو المثالي هو تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ المعاملات التي تعتمد على تلك الأسعار. ولكن في الفاصل الزمني الحالي الذي يبلغ 400 مللي ثانية، قد تؤدي التقلبات الشديدة في السوق إلى تنفيذ الصفقات بسعرها الأصلي.
بالنسبة لاتفاقيات الإقراض، من الأفضل إضافة الهامش أولاً ثم القيام بالتسوية.
لذلك، من الأفضل أن تكون هناك طريقة تسمح لبروتوكولات مختلفة بترتيب المعاملات حسب الطلب، وهو ما تؤكد عليه Solana دائمًا وهو تنفيذ التحكم في التطبيقات (Application-Controlled Execution) .
BAM (Block Assembly Marketplace، سوق تجميع الكتل) هو بالضبط جواب Solana.
BAM على سلسلة Solana أنشأت طبقة ترتيب، أو ما يسمى بطبقة المعالجة المسبقة، بين التطبيقات والشبكة الرئيسية.
استخدام بيئات التنفيذ الموثوقة (Trusted Execution Environments, TEEs) لبناء صناديق الخصوصية، حيث يتم ترتيب المعاملات داخل الصندوق وفقًا لقواعد الترتيب المحددة مسبقًا، أو FIFO (الأول في الدخول، الأول في الخروج).
خدمة أفضل لسجلات الأوامر (CLOBs) و بورصات العقود الآجلة (Perpetual Exchanges) و بروتوكولات البرك المظلمة (Dark Pools).
Solana عادةً ما يتم تجميع الصفقات مقارنةً بنموذج BAM
كيف نفهم أن BAM قد بنى طبقة ترتيب بين تطبيقات Solana والشبكة الرئيسية؟ لنبدأ بمقارنة بديهية.
Solana عملية التداول الطبيعية،
1）يؤكد المستخدم الصفقة داخل المحفظة،
2）إرسال المعاملة إلى عقدة RPC،
3）RPC يرسل إلى عقدة Leader في شبكة Solana الرئيسية خلال فترة Slot الحالية,
4）يقوم الزعيم بجمع معاملات حوض التداول، وترتيبها، وتعبئتها في كتل للبث،
تصويت العقد الأخرى.
إذا كانت هناك تطبيقات تستخدم BAM، فإن عملية التداول تكون كما يلي،
1）يؤكد المستخدم المعاملة في المحفظة,
2）تم إرسال المعاملة إلى عقدة RPC،
نقل المعاملات إلى شبكة BAM وترتيبها في خصوصية TEE. خلال هذه العملية، قد تضيف العقد معاملات إضافية من خلال الملحقات، مثل تحديث أسعار الأوراق المالية، ثم توليد الإثبات.
تم تقديم حزمة بيانات المعاملات إلى عقدة الزعيم في شبكة Solana الرئيسية،
5）عند جمع Leader للمعاملات، يتم جمع حزمة بيانات BAM، ثم يتم تجميعها في كتلة للبث.
تصويت العقد الأخرى.
لذلك، في الواقع، لا يتعارض BAM مع عملية توافق الشبكة الرئيسية الحالية لـ Solana، بل هو بمثابة "اختيار". لا يعمل BAM مباشرة على الشبكة الرئيسية لـ Solana، بل يتم بطريقة ما يسمى "خارج السلسلة"، حيث يتم إتمام ترتيب المعاملات مسبقًا، وتجميع المعاملات، ثم تقديمها إلى الشبكة الرئيسية لـ Solana.
BAM ترتيب حجم المعاملات
يدعم BAM ثلاث أوضاع تشغيل،
1）Solana الوضع الافتراضي؛
وضع Block-Engine؛ الحل الحالي لـ Jito لمشكلة MEV، جوهره هو آلية المزايدة.
نمط BAM، يتبع المدققون ترتيب FIFO الصارم.
نقطة جوهرية في نمط BAM هي ما يلي,
1）بيئات التنفيذ الموثوقة TEEs: الخصوصية والعدالة من خلال استخدام بيئات التنفيذ الموثوقة TEEs، بناء بيئة خصوصية، وترتيب المعاملات. الجانب الآخر من الخصوصية يسمى العدالة.
2）نظام الإضافات Plugin: ترتيب معقد من خلال نظام الإضافات، يسمح BAM للتطبيقات ببناء منطق ترتيب معاملات مخصص. وهذا الترتيب المخصص، ليس كما يريد العقدة أن ترتب، بل يتم ترتيبه وفقًا لقواعد محددة مسبقًا.
تخطط الإضافات لتحقيق ترتيب معقد للصفقات مع الحفاظ على ضمانات الأمان لبيئة TEE. حاليًا، هي في مرحلة التطوير المبكر.
كما ذُكر سابقًا,
بالنسبة لدفتر الطلبات DEX، يجب أن يكون الترتيب المثالي هو تنفيذ جميع عمليات الإلغاء أولاً مع تقلبات الأسعار، ثم تنفيذ الطلبات الجديدة، وأخيرًا تنفيذ الصفقات. وهذا ما لا يمكن أن يفعله إجماع Solana حاليًا على المستوى الدقيق.
وفيما يتعلق بطبقة أسعار الأوراق المالية، فإن الوضع المثالي هو تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ المعاملات المعتمدة على تلك الأسعار. ولكن في الفاصل الزمني الحالي البالغ 400 مللي ثانية، قد تتسبب التقلبات الحادة في إتمام الصفقة بالسعر الأصلي.
بالنسبة لبروتوكول الإقراض، من الأفضل إضافة الضمان أولاً، ثم القيام بالتسوية. هذا في الواقع يحقق وظيفة التحكم في التنفيذ لتطبيق ACE.
لذلك، ماذا حقق BAM بالضبط؟
على سبيل المثال،
1）حماية تسوية الاقتراض
بالنسبة لاتفاقيات الإقراض، بعد اكتشاف مخاطر التصفية، يتم تنفيذ عمليات ضمان إضافية كأولوية، ثم يتم إجراء فحص التصفية.
مجموعة الصفقات على مستوى الذرة
بالنسبة لـ DEX، يجب تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ الصفقات التي تعتمد على تلك الأسعار. إذا كان DEX عقدًا، يمكن أيضًا تسوية المشتقات ذات الصلة. تتم جميع الإجراءات المذكورة أعلاه في نفس نافذة الوقت.
حماية تقلبات السعر
بالنسبة لـ DEX، قم بالكشف عن الطلبات الكبيرة غير العادية، وقم بتقسيم الطلبات الكبيرة إلى كتل صغيرة، وتنفيذها على دفعات، مما يمنح السوق وقتًا للتفاعل، وتجنب عمليات التصفية المتسلسلة أو التحكيم التي تسبب دوامة الموت.
4）حماية صانعي السوق
حدث طارئ، سحب الطلب خلال مللي ثانية، تحديث السعر من قبل الأوراق المالية، إعادة إدخال الطلب من قبل صانعي السوق. تجنب الاستغلال الخبيث وتقليل الفارق السعري.
كان من المقرر أن يتم إطلاق BAM في نهاية يوليو.
وكذلك، مع نشر BAM، ستتحسن تجربة التداول على Solana بشكل ملحوظ. ستجعل BAM تجربة تطبيقات الشبكة الرئيسية لـ Solana أقرب إلى CEX.
بناءً على ما سبق،
يقدم BAM قابلية التحقق وحماية الخصوصية والبرمجة لعملية معالجة المعاملات في Solana، مما يتيح للمطورين بناء دفاتر الأوامر المركزية (CLOBs) ، وأسواق العقود الآجلة (Perpetual Exchanges) ، وأحواض الظلام (Dark Pools) وغيرها من البنى التحتية المالية التي تتطلب التحكم في الترتيب والتنفيذ المحدد وضمان الخصوصية، مما يعزز الابتكار والتطور في نظام Solana البيئي.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تفسير سوق تجميع الكتل BAM في Solana: عندما لا تكون السرعة هي السعي الوحيد بعد الآن
Solana أصبحت سريعة بما فيه الكفاية، والحجم كبير بما فيه الكفاية. فهل هو حقًا "كافٍ"؟
عندما نتأمل تلك التداولات، هناك سؤال دائم الوجود: هل هذه التداولات تخلق قيمة حقًا؟
إن حجم كبير من التداولات في Solana لا يأتي من طلبات حقيقية للتداول، بل من المتداولين عالي التردد الذين يستغلون الفجوات المعلوماتية التي تبلغ مللي ثانية لتحقيق الأرباح. هؤلاء "المتداولون السامين" (Toxic-takers) يستغلون المزايا التقنية، وعندما يكون صانعي السوق (Maker) على وشك سحب أوامرهم، يزيدون Gas ليجعلوا تداولاتهم تُحزم أولاً، مما يُكمل عملية التحكيم، مما يؤدي إلى تحمل صانعي السوق للخسائر. لتعويض الخسائر، لا يمكن لصانعي السوق إلا توسيع الفارق بين سعر الشراء وسعر البيع.
في النهاية، يدفع المستخدمون العاديون ثمن ذلك. لطالما كانت لدى Solana حلم بتحقيق دفتر الطلبات على السلسلة، ليحل محل CEX. ولكن بهذا، أصبح "المتداولون السامون" عقبة أمام تحقيق الحلم. هذه هي التحدي الجديد الذي تواجهه Solana: الحجم ≠ السيولة. السوق الصحي الحقيقي لا يحتاج إلى المزيد من الصفقات، بل يحتاج إلى صفقات أفضل.
كيف يمكن إزالة المعاملات الضارة بشكل أفضل لحماية السيولة؟
في النظام الحالي، يتمتع آكلو الطلبات (Takers) بأولوية فعلية بسبب آلية مزاد دورات إجماع Solana، مما يتيح لتأثير MEV الضار التأثير على عدالة السوق.
كيف نفهم؟
في إجماع Solana الحالي، يتم ترتيب المعاملات داخل كل فترة زمنية Slot وفقًا لأولوية رسوم الغاز المدفوعة، فمن يقدم عرضًا أعلى يتم تنفيذ معاملته أولاً. هذه المزاد دوري، كل 400 مللي ثانية Slot.
في هذه العملية، يحتاج صناع السوق إلى تعديل الاقتباسات بشكل متكرر، وإلغاء الطلبات، وإعادة إدخال الطلبات. عند تغير سعر السوق، يجب تحديثه على الفور.
والمتناولون (Taker) ، وخاصة المتداولون ذوو التردد العالي ، يراقبون فرق الأسعار ويقومون بإجراء الصفقة فور اكتشاف الفرصة. وبالتالي ، يمكن للمتداولين ذوي التردد العالي أن يتخذوا إجراءً من خلال دفع رسوم أعلى لإتمام الصفقة قبل إلغاء الطلب. مما يؤدي إلى أن يتعرض صانعو السوق في كثير من الأحيان إلى "استهداف" ويتحملون الخسائر.
بالنسبة لدفتر الطلبات DEX، يجب أن يكون الترتيب المثالي هو أنه مع تقلبات الأسعار، يتم تنفيذ جميع عمليات الإلغاء أولاً، ثم يتم تنفيذ الطلبات الجديدة، وأخيرًا يتم تنفيذ الصفقات. وهذا ما لا يمكن أن يحققه إجماع Solana حاليًا على المستوى الجزئي.
وفي مستوى تسعير الأوراق المالية، نفس الشيء ينطبق، حيث أن السيناريو المثالي هو تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ المعاملات التي تعتمد على تلك الأسعار. ولكن في الفاصل الزمني الحالي الذي يبلغ 400 مللي ثانية، قد تؤدي التقلبات الشديدة في السوق إلى تنفيذ الصفقات بسعرها الأصلي.
بالنسبة لاتفاقيات الإقراض، من الأفضل إضافة الهامش أولاً ثم القيام بالتسوية.
لذلك، من الأفضل أن تكون هناك طريقة تسمح لبروتوكولات مختلفة بترتيب المعاملات حسب الطلب، وهو ما تؤكد عليه Solana دائمًا وهو تنفيذ التحكم في التطبيقات (Application-Controlled Execution) .
BAM (Block Assembly Marketplace، سوق تجميع الكتل) هو بالضبط جواب Solana.
BAM على سلسلة Solana أنشأت طبقة ترتيب، أو ما يسمى بطبقة المعالجة المسبقة، بين التطبيقات والشبكة الرئيسية.
استخدام بيئات التنفيذ الموثوقة (Trusted Execution Environments, TEEs) لبناء صناديق الخصوصية، حيث يتم ترتيب المعاملات داخل الصندوق وفقًا لقواعد الترتيب المحددة مسبقًا، أو FIFO (الأول في الدخول، الأول في الخروج).
خدمة أفضل لسجلات الأوامر (CLOBs) و بورصات العقود الآجلة (Perpetual Exchanges) و بروتوكولات البرك المظلمة (Dark Pools).
Solana عادةً ما يتم تجميع الصفقات مقارنةً بنموذج BAM
كيف نفهم أن BAM قد بنى طبقة ترتيب بين تطبيقات Solana والشبكة الرئيسية؟ لنبدأ بمقارنة بديهية.
Solana عملية التداول الطبيعية،
1）يؤكد المستخدم الصفقة داخل المحفظة،
2）إرسال المعاملة إلى عقدة RPC،
3）RPC يرسل إلى عقدة Leader في شبكة Solana الرئيسية خلال فترة Slot الحالية,
4）يقوم الزعيم بجمع معاملات حوض التداول، وترتيبها، وتعبئتها في كتل للبث،
إذا كانت هناك تطبيقات تستخدم BAM، فإن عملية التداول تكون كما يلي،
1）يؤكد المستخدم المعاملة في المحفظة,
2）تم إرسال المعاملة إلى عقدة RPC،
نقل المعاملات إلى شبكة BAM وترتيبها في خصوصية TEE. خلال هذه العملية، قد تضيف العقد معاملات إضافية من خلال الملحقات، مثل تحديث أسعار الأوراق المالية، ثم توليد الإثبات.
تم تقديم حزمة بيانات المعاملات إلى عقدة الزعيم في شبكة Solana الرئيسية،
5）عند جمع Leader للمعاملات، يتم جمع حزمة بيانات BAM، ثم يتم تجميعها في كتلة للبث.
لذلك، في الواقع، لا يتعارض BAM مع عملية توافق الشبكة الرئيسية الحالية لـ Solana، بل هو بمثابة "اختيار". لا يعمل BAM مباشرة على الشبكة الرئيسية لـ Solana، بل يتم بطريقة ما يسمى "خارج السلسلة"، حيث يتم إتمام ترتيب المعاملات مسبقًا، وتجميع المعاملات، ثم تقديمها إلى الشبكة الرئيسية لـ Solana.
BAM ترتيب حجم المعاملات
يدعم BAM ثلاث أوضاع تشغيل،
1）Solana الوضع الافتراضي؛
وضع Block-Engine؛ الحل الحالي لـ Jito لمشكلة MEV، جوهره هو آلية المزايدة.
نمط BAM، يتبع المدققون ترتيب FIFO الصارم.
نقطة جوهرية في نمط BAM هي ما يلي,
1）بيئات التنفيذ الموثوقة TEEs: الخصوصية والعدالة من خلال استخدام بيئات التنفيذ الموثوقة TEEs، بناء بيئة خصوصية، وترتيب المعاملات. الجانب الآخر من الخصوصية يسمى العدالة.
2）نظام الإضافات Plugin: ترتيب معقد من خلال نظام الإضافات، يسمح BAM للتطبيقات ببناء منطق ترتيب معاملات مخصص. وهذا الترتيب المخصص، ليس كما يريد العقدة أن ترتب، بل يتم ترتيبه وفقًا لقواعد محددة مسبقًا.
تخطط الإضافات لتحقيق ترتيب معقد للصفقات مع الحفاظ على ضمانات الأمان لبيئة TEE. حاليًا، هي في مرحلة التطوير المبكر.
كما ذُكر سابقًا,
بالنسبة لدفتر الطلبات DEX، يجب أن يكون الترتيب المثالي هو تنفيذ جميع عمليات الإلغاء أولاً مع تقلبات الأسعار، ثم تنفيذ الطلبات الجديدة، وأخيرًا تنفيذ الصفقات. وهذا ما لا يمكن أن يفعله إجماع Solana حاليًا على المستوى الدقيق.
وفيما يتعلق بطبقة أسعار الأوراق المالية، فإن الوضع المثالي هو تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ المعاملات المعتمدة على تلك الأسعار. ولكن في الفاصل الزمني الحالي البالغ 400 مللي ثانية، قد تتسبب التقلبات الحادة في إتمام الصفقة بالسعر الأصلي.
بالنسبة لبروتوكول الإقراض، من الأفضل إضافة الضمان أولاً، ثم القيام بالتسوية. هذا في الواقع يحقق وظيفة التحكم في التنفيذ لتطبيق ACE.
لذلك، ماذا حقق BAM بالضبط؟
على سبيل المثال،
1）حماية تسوية الاقتراض
بالنسبة لاتفاقيات الإقراض، بعد اكتشاف مخاطر التصفية، يتم تنفيذ عمليات ضمان إضافية كأولوية، ثم يتم إجراء فحص التصفية.
بالنسبة لـ DEX، يجب تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ الصفقات التي تعتمد على تلك الأسعار. إذا كان DEX عقدًا، يمكن أيضًا تسوية المشتقات ذات الصلة. تتم جميع الإجراءات المذكورة أعلاه في نفس نافذة الوقت.
بالنسبة لـ DEX، قم بالكشف عن الطلبات الكبيرة غير العادية، وقم بتقسيم الطلبات الكبيرة إلى كتل صغيرة، وتنفيذها على دفعات، مما يمنح السوق وقتًا للتفاعل، وتجنب عمليات التصفية المتسلسلة أو التحكيم التي تسبب دوامة الموت.
4）حماية صانعي السوق
حدث طارئ، سحب الطلب خلال مللي ثانية، تحديث السعر من قبل الأوراق المالية، إعادة إدخال الطلب من قبل صانعي السوق. تجنب الاستغلال الخبيث وتقليل الفارق السعري.
كان من المقرر أن يتم إطلاق BAM في نهاية يوليو.
وكذلك، مع نشر BAM، ستتحسن تجربة التداول على Solana بشكل ملحوظ. ستجعل BAM تجربة تطبيقات الشبكة الرئيسية لـ Solana أقرب إلى CEX.
بناءً على ما سبق،
يقدم BAM قابلية التحقق وحماية الخصوصية والبرمجة لعملية معالجة المعاملات في Solana، مما يتيح للمطورين بناء دفاتر الأوامر المركزية (CLOBs) ، وأسواق العقود الآجلة (Perpetual Exchanges) ، وأحواض الظلام (Dark Pools) وغيرها من البنى التحتية المالية التي تتطلب التحكم في الترتيب والتنفيذ المحدد وضمان الخصوصية، مما يعزز الابتكار والتطور في نظام Solana البيئي.
فوق.