التحدي الجديد لـ Solana: تحسين جودة المعاملات بدلاً من العدد
تشتهر Solana بسرعتها العالية وقدرتها الكبيرة على المعاملات، لكن هل يكفي ذلك؟ عندما نتعمق في تحليل هذه المعاملات، لا يسعنا إلا أن نتساءل: هل جميعها تخلق قيمة فعلية؟
في الواقع، فإن العديد من المعاملات على Solana لا تأتي من طلب حقيقي، بل تأتي من المتداولين عالي التردد الذين يستفيدون من الفارق المعلوماتي على مستوى المللي ثانية للقيام بالتحكيم. هؤلاء ما يُطلق عليهم "المتداولون السامون" يستفيدون من المزايا التقنية، حيث يزيدون من رسوم الغاز عندما يكون صانع السوق على وشك إلغاء الطلب، مما يضمن تنفيذ معاملاتهم أولاً، وبالتالي إتمام التحكيم، مما يتسبب في خسائر لصانع السوق. لتعويض هذه الخسائر، يتعين على صانعي السوق توسيع الفارق بين أسعار الشراء والبيع، مما يؤدي في النهاية إلى تحمل المستخدمين العاديين لهذه التكاليف.
تسعى سولانا منذ زمن لتحقيق دفتر طلبات يمكن أن يحل محل البورصات المركزية على السلسلة، ولكن وجود "تجار سامين" أصبح عقبة أمام تحقيق هذا الهدف. هذه هي التحديات الجديدة التي تواجه سولانا حالياً: حجم التداول لا يساوي السيولة. السوق الصحي الحقيقي يحتاج ليس إلى المزيد من التداولات، بل إلى تداولات ذات جودة أعلى.
كيف تستبعد الصفقات السامة لحماية السيولة بشكل أفضل؟
في النظام الحالي، نظرًا لأن آلية التوافق في Solana تعتمد على المزادات الدورية، فإن المتقدمين في الطلبات يتمتعون فعليًا بأولوية، مما يجعل سلوك MEV (最大可提取价值) الضار يؤثر على عدالة السوق.
في ظل آلية الإجماع الحالية الخاصة بـ Solana، يتم ترتيب المعاملات وفقًا لرسوم الغاز المدفوعة في كل فترة زمنية مدتها 400 مللي ثانية، حيث يتم تنفيذ المعاملات ذات أعلى عرض أولاً. خلال هذه العملية، يحتاج صناع السوق إلى تعديل عروضهم بشكل متكرر، وسحب الطلبات وإعادة تقديمها باستمرار لتناسب تغيرات أسعار السوق. بينما يقوم المتداولون بالتحكيم بمراقبة تفاوت الأسعار، وعند اكتشاف فرصة، يتعاملون على الفور، وغالبًا ما يتم ذلك من خلال دفع رسوم أعلى لإتمام الصفقة قبل سحب صناع السوق للطلبات، مما يؤدي إلى تكبد صناع السوق خسائر متكررة.
في الحالة المثالية، يجب أن يكون ترتيب تنفيذ الصفقات في بورصة اللامركزية (DEX) وفقًا لكتاب الطلبات: مع تقلب الأسعار، يتم تنفيذ جميع الطلبات الملغاة أولاً، ثم الطلبات الجديدة، وأخيرًا الصفقات المنجزة. ومع ذلك، لا يمكن لآلية الإجماع الحالية في Solana تحقيق ذلك على المستوى الدقيق.
وبالمثل، في ما يتعلق بأسعار الأوراق المالية، فإن الوضع المثالي هو تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ الصفقات التي تعتمد على تلك الأسعار. لكن في الفاصل الزمني الحالي البالغ 400 مللي ثانية، قد يؤدي تقلب السوق الشديد إلى تنفيذ الصفقات وفقًا للأسعار الأصلية.
بالنسبة لاتفاقيات الإقراض ، فإن أفضل خيار هو تعزيز الهامش أولاً ثم إجراء التسوية.
لذلك، تحتاج Solana إلى آلية تسمح للبروتوكولات المختلفة بترتيب المعاملات حسب الطلب، وهذا ما أكدت عليه Solana دائمًا وهو التحكم في تنفيذ التطبيقات (ACE).
BAM: حل سولانا
BAM (سوق تجميع الكتل) هو الجواب الذي قدمته Solana لحل هذه المشاكل. إنه يقوم بإنشاء طبقة ترتيب أو طبقة معالجة مسبقة بين تطبيقات سلسلة Solana والشبكة الرئيسية. تستخدم BAM بيئات التنفيذ الموثوقة (TEEs) لبناء صندوق خصوصية، حيث يتم ترتيب المعاملات وفقًا لقواعد محددة مسبقًا أو مبدأ الوارد أولاً (FIFO)، وذلك لخدمة بروتوكولات دفتر الطلبات، وتبادلات العقود الدائمة، وأحواض الظلام بشكل أفضل.
كيفية عمل BAM
في عملية تداول Solana التقليدية، بعد تأكيد المستخدم للمعاملة، يتم إرسال المعاملة إلى عقدة Leader في الفتحة الزمنية الحالية عبر عقدة RPC، حيث تجمع العقدة Leader المعاملات وترتبها وتعبئتها في كتلة للبث، وتقوم العقد الأخرى بالتصويت.
وفي التطبيقات المتصلة بـ BAM، تكون عملية التداول مختلفة قليلاً: يتم إرسال التداول الذي يؤكده المستخدم أولاً إلى شبكة BAM، حيث يتم ترتيبه في بيئة TEE. خلال هذه العملية، قد تضيف العقد معاملات إضافية من خلال المكونات الإضافية، مثل تحديث أسعار الأورacles. يتم تقديم حزمة المعاملات المرتبة إلى عقدة leader في شبكة Solana الرئيسية، ثم يتم تجميعها في كتلة وبثها.
BAM في الواقع يعمل كطبقة معالجة مسبقة اختيارية، ولا يعمل مباشرة على شبكة Solana الرئيسية، بل يتم ترتيب المعاملات "خارج السلسلة" ثم تقديم حزمة المعاملات المرتبة إلى الشبكة الرئيسية.
ثلاثة أوضاع تشغيل BAM
وضع Solana الافتراضي
وضع Block-Engine: الحل الحالي لـ Jito لمشكلة MEV، والجوهر هو آلية المزايدة
وضع BAM: يقوم المدققون بترتيب وفقًا لمبدأ FIFO بدقة
تشمل الميزات الأساسية لنموذج BAM:
استخدام TEE لبناء بيئة خصوصية لترتيب المعاملات، وضمان العدالة
تنفيذ منطق ترتيب المعاملات المعقد من خلال نظام المكونات الإضافية، مما يسمح للتطبيقات بتخصيص قواعد الترتيب.
التطبيقات العملية لـ BAM
حماية تسوية الإقراض: تنفيذ عمليات ضمان إضافية بشكل أولي، ثم إجراء فحص التسوية
مجموعة صفقات بمستوى ذري: أولاً تحديث سعر oracle، ثم تنفيذ الصفقات المعتمدة على هذا السعر، بالنسبة لمبادلات العقود يمكن أيضًا تسوية المشتقات ذات الصلة في نفس الوقت.
حماية تقلبات الأسعار: الكشف عن الطلبات الكبيرة غير العادية وتنفيذها على دفعات، مما يمنح السوق وقتًا للتفاعل، وتجنب التأثيرات السلبية الناتجة عن التصفية المتسلسلة أو套利.
حماية صانعي السوق: في حالة حدوث أحداث طارئة، القدرة على سحب الطلبات بسرعة، تحديث الأسعار وإعادة تقديم الطلبات، للحد من مخاطر التحكيم الضار.
مع نشر BAM، ستتحسن تجربة تداول Solana بشكل ملحوظ، مما يجعل تجربة التطبيقات على الشبكة الرئيسية أقرب إلى تبادل مركزي.
بشكل عام، يوفر BAM قابلية التحقق، وحماية الخصوصية، والبرمجة لعملية معالجة المعاملات في Solana. إنه يمكّن المطورين من إنشاء دفتر أوامر مركزي محدد الأسعار، ومنصات تداول العقود الدائمة، وأحواض مظلمة، وغيرها من البنى التحتية المالية التي تتطلب السيطرة على الترتيب، والتنفيذ الحتمي، وضمان الخصوصية، مما يعزز الابتكار والتطوير في نظام Solana البيئي.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 11
أعجبني
11
4
إعادة النشر
مشاركة
تعليق
0/400
Layer2Arbitrageur
· 08-12 14:13
هههه مجرد يوم آخر من مواجهة ماكسيز مع تدفق سام... كنت أسبق الجميع بفارق 15 نقطة أساس منذ اليوم الأول
Solana أطلقت حل BAM لتحسين جودة المعاملات وإنصافها
التحدي الجديد لـ Solana: تحسين جودة المعاملات بدلاً من العدد
تشتهر Solana بسرعتها العالية وقدرتها الكبيرة على المعاملات، لكن هل يكفي ذلك؟ عندما نتعمق في تحليل هذه المعاملات، لا يسعنا إلا أن نتساءل: هل جميعها تخلق قيمة فعلية؟
في الواقع، فإن العديد من المعاملات على Solana لا تأتي من طلب حقيقي، بل تأتي من المتداولين عالي التردد الذين يستفيدون من الفارق المعلوماتي على مستوى المللي ثانية للقيام بالتحكيم. هؤلاء ما يُطلق عليهم "المتداولون السامون" يستفيدون من المزايا التقنية، حيث يزيدون من رسوم الغاز عندما يكون صانع السوق على وشك إلغاء الطلب، مما يضمن تنفيذ معاملاتهم أولاً، وبالتالي إتمام التحكيم، مما يتسبب في خسائر لصانع السوق. لتعويض هذه الخسائر، يتعين على صانعي السوق توسيع الفارق بين أسعار الشراء والبيع، مما يؤدي في النهاية إلى تحمل المستخدمين العاديين لهذه التكاليف.
تسعى سولانا منذ زمن لتحقيق دفتر طلبات يمكن أن يحل محل البورصات المركزية على السلسلة، ولكن وجود "تجار سامين" أصبح عقبة أمام تحقيق هذا الهدف. هذه هي التحديات الجديدة التي تواجه سولانا حالياً: حجم التداول لا يساوي السيولة. السوق الصحي الحقيقي يحتاج ليس إلى المزيد من التداولات، بل إلى تداولات ذات جودة أعلى.
كيف تستبعد الصفقات السامة لحماية السيولة بشكل أفضل؟
في النظام الحالي، نظرًا لأن آلية التوافق في Solana تعتمد على المزادات الدورية، فإن المتقدمين في الطلبات يتمتعون فعليًا بأولوية، مما يجعل سلوك MEV (最大可提取价值) الضار يؤثر على عدالة السوق.
في ظل آلية الإجماع الحالية الخاصة بـ Solana، يتم ترتيب المعاملات وفقًا لرسوم الغاز المدفوعة في كل فترة زمنية مدتها 400 مللي ثانية، حيث يتم تنفيذ المعاملات ذات أعلى عرض أولاً. خلال هذه العملية، يحتاج صناع السوق إلى تعديل عروضهم بشكل متكرر، وسحب الطلبات وإعادة تقديمها باستمرار لتناسب تغيرات أسعار السوق. بينما يقوم المتداولون بالتحكيم بمراقبة تفاوت الأسعار، وعند اكتشاف فرصة، يتعاملون على الفور، وغالبًا ما يتم ذلك من خلال دفع رسوم أعلى لإتمام الصفقة قبل سحب صناع السوق للطلبات، مما يؤدي إلى تكبد صناع السوق خسائر متكررة.
في الحالة المثالية، يجب أن يكون ترتيب تنفيذ الصفقات في بورصة اللامركزية (DEX) وفقًا لكتاب الطلبات: مع تقلب الأسعار، يتم تنفيذ جميع الطلبات الملغاة أولاً، ثم الطلبات الجديدة، وأخيرًا الصفقات المنجزة. ومع ذلك، لا يمكن لآلية الإجماع الحالية في Solana تحقيق ذلك على المستوى الدقيق.
وبالمثل، في ما يتعلق بأسعار الأوراق المالية، فإن الوضع المثالي هو تحديث أسعار الأوراق المالية أولاً، ثم تنفيذ الصفقات التي تعتمد على تلك الأسعار. لكن في الفاصل الزمني الحالي البالغ 400 مللي ثانية، قد يؤدي تقلب السوق الشديد إلى تنفيذ الصفقات وفقًا للأسعار الأصلية.
بالنسبة لاتفاقيات الإقراض ، فإن أفضل خيار هو تعزيز الهامش أولاً ثم إجراء التسوية.
لذلك، تحتاج Solana إلى آلية تسمح للبروتوكولات المختلفة بترتيب المعاملات حسب الطلب، وهذا ما أكدت عليه Solana دائمًا وهو التحكم في تنفيذ التطبيقات (ACE).
BAM: حل سولانا
BAM (سوق تجميع الكتل) هو الجواب الذي قدمته Solana لحل هذه المشاكل. إنه يقوم بإنشاء طبقة ترتيب أو طبقة معالجة مسبقة بين تطبيقات سلسلة Solana والشبكة الرئيسية. تستخدم BAM بيئات التنفيذ الموثوقة (TEEs) لبناء صندوق خصوصية، حيث يتم ترتيب المعاملات وفقًا لقواعد محددة مسبقًا أو مبدأ الوارد أولاً (FIFO)، وذلك لخدمة بروتوكولات دفتر الطلبات، وتبادلات العقود الدائمة، وأحواض الظلام بشكل أفضل.
كيفية عمل BAM
في عملية تداول Solana التقليدية، بعد تأكيد المستخدم للمعاملة، يتم إرسال المعاملة إلى عقدة Leader في الفتحة الزمنية الحالية عبر عقدة RPC، حيث تجمع العقدة Leader المعاملات وترتبها وتعبئتها في كتلة للبث، وتقوم العقد الأخرى بالتصويت.
وفي التطبيقات المتصلة بـ BAM، تكون عملية التداول مختلفة قليلاً: يتم إرسال التداول الذي يؤكده المستخدم أولاً إلى شبكة BAM، حيث يتم ترتيبه في بيئة TEE. خلال هذه العملية، قد تضيف العقد معاملات إضافية من خلال المكونات الإضافية، مثل تحديث أسعار الأورacles. يتم تقديم حزمة المعاملات المرتبة إلى عقدة leader في شبكة Solana الرئيسية، ثم يتم تجميعها في كتلة وبثها.
BAM في الواقع يعمل كطبقة معالجة مسبقة اختيارية، ولا يعمل مباشرة على شبكة Solana الرئيسية، بل يتم ترتيب المعاملات "خارج السلسلة" ثم تقديم حزمة المعاملات المرتبة إلى الشبكة الرئيسية.
ثلاثة أوضاع تشغيل BAM
تشمل الميزات الأساسية لنموذج BAM:
التطبيقات العملية لـ BAM
مع نشر BAM، ستتحسن تجربة تداول Solana بشكل ملحوظ، مما يجعل تجربة التطبيقات على الشبكة الرئيسية أقرب إلى تبادل مركزي.
بشكل عام، يوفر BAM قابلية التحقق، وحماية الخصوصية، والبرمجة لعملية معالجة المعاملات في Solana. إنه يمكّن المطورين من إنشاء دفتر أوامر مركزي محدد الأسعار، ومنصات تداول العقود الدائمة، وأحواض مظلمة، وغيرها من البنى التحتية المالية التي تتطلب السيطرة على الترتيب، والتنفيذ الحتمي، وضمان الخصوصية، مما يعزز الابتكار والتطوير في نظام Solana البيئي.