a16z كريبتو أحدث الأبحاث: ما هو المفتاح لتطبيقات DeFi على نطاق واسع؟

المؤلفون: @PGarimidi، jneu_net، @MaxResnic

الترجمة: جياوان، ChainCatcher

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

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

تتمثل المعضلة الرئيسية التي يواجهها صانع السوق في: تقليل فروق الشراء والبيع قدر الإمكان، وفي الوقت نفسه تجنب الوقوع في خطر “الاختيار العكسي” نتيجة انحراف عروض الأسعار عن ظروف السوق. ولهذا، يجب على صانع السوق تحديث أوامره باستمرار لتعكس حالة العالم الحقيقي. على سبيل المثال، إذا تسببت تصريحات مجلس الاحتياطي الفيدرالي في قفزة مفاجئة في سعر الأصل، سيحتاج صانع السوق إلى الاستجابة فورًا وتحديث أوامره إلى السعر الجديد. في هذه الحالة، إذا لم تستقر/تُعالج معاملة تحديث أوامره على الفور، فقد يتكبد صانع السوق خسارة لأن المتحكّمين (arbitrageurs) سينفذون أوامره بسعر قديم. عندها سيتعين على صانع السوق توسيع فروق الأسعار لتقليل تعرضه للمخاطر في مثل هذه الأحداث، وهذا بدوره يخفض القدرة التنافسية لمرافق التداول على السلسلة.

التجميع القابل للتنبؤ للمعاملات يمنح صناع السوق ضمانًا قويًا يمكنهم من الاستجابة بسرعة للأحداث خارج السلسلة، والحفاظ على كفاءة السوق على السلسلة.

ما الذي نملكه وما الذي نحتاجه

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

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

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

أين تكمن صعوبة تحقيق القابلية للتنبؤ بالفعل؟

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

في الشبكات غير المرخّصة، لدى القادة حافز لعصر القيمة، ويُعرف ذلك اختصارًا باسم MEV. يتجاوز MEV بكثير نطاق هجمات “الالتفاف” حول معاملات AMM. حتى إذا كان القائد قادرًا فقط على تأخير تجميع المعاملات لِبضعة عشرات من الملي ثوانٍ، فقد يجني أرباحًا كبيرة ويقلل كفاءة التطبيقات الأساسية. سيجعل دفتر الأوامر الذي يعطي أولوية لجزء فقط من المتعاملين الآخرين في بيئة منافسة غير عادلة. وفي أسوأ الحالات، قد يصبح القائد عدائيًا إلى درجة أن المتداولين يغادرون المنصة بالكامل.

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

المطلبان الأساسيان

في مواجهة هذه المزايا، يصبح المشاركة النشطة من صناع السوق غير مجدية اقتصاديًا؛ فبمجرد تقلب الأسعار، يمكنهم أن يكونوا في الطرف الخاسر. ينحصر جوهر المشكلة في أن القادة يمتلكون صلاحيات مفرطة في نقطتين حاسمتين: 1) يمكن للقائد فحص معاملات أي شخص آخر، و2) يمكن للقائد رؤية معاملات الآخرين ومن ثم تقديم معاملاته الخاصة كرد فعل. إن أي واحدة من هاتين المشكلتين قد تُثبت أنها كارثية.

مثال

يمكننا تحديد موضع المشكلة بدقة من خلال المثال التالي. لنفترض مزادًا له منافسان: Alice و Bob، حيث يكون Bob أيضًا هو القائد لعقدة البلوك الذي يحدث فيه المزاد. (إن وجود منافسين فقط يهدف لتبسيط الفكرة؛ وبغض النظر عن عدد المنافسين، تنطبق نفس الحجة.)

يقبل المزاد تقديم العروض خلال الفترة الزمنية اللازمة لتوليد البلوك، ولنفرض أنها من الوقت t=0 إلى t=1. تقدم Alice عرضها bA عند الزمن tA، بينما يقدم Bob عرضًا bB عند الزمن tB > tA. وبما أن Bob هو قائد هذا البلوك، فإنه يمكنه دائمًا ضمان أن يكون إجراءه الأخير. لدى Alice و Bob أيضًا مصدر “حقيقة” مستمر لأسعار الأصل يمكن قراءته (مثل السعر المتوسط في بورصة مركزية). عند الزمن t، نفترض أن هذا السعر هو pt. ونفترض أنه في أي لحظة t، تكون توقعات السوق لسعر الأصل عند انتهاء المزاد (t=1) مساوية دائمًا للسعر الفعلي الحالي pt. قواعد المزاد بسيطة: يفوز من بين Alice و Bob صاحب العرض الأعلى ويدفع مبلغ عرضه.

مطلب مقاومة المراقبة/التحقق (anti-censorship)

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

مطلب الإخفاء (hidden)

الحالة الأكثر تعقيدًا هي ماذا لو لم يستطع Bob فحص/مراجعة عروض Alice مباشرة، لكنه مع ذلك يستطيع رؤية عروض Alice قبل تقديم عرضه. في هذه الحالة، لدى Bob استراتيجية بسيطة. عند تقديم عرضه، يحتاج فقط إلى التحقق مما إذا كان ptB > bA. إذا كانت الإجابة نعم، فإن عرض Bob يكون أعلى بقليل من bA؛ وإذا لم تكن الإجابة نعم، فلن يقدم Bob أي عرض.

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

النقطة المحورية في هذا المثال هي أن مدة استمرار المزاد ليست مهمة. طالما أن Bob يستطيع فحص عرض Alice، أو رؤية عرض Alice قبل تقديم عرضه، فإن هذا المزاد محكوم عليه بالفشل.

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

كيف تظهر هذه المشكلات في الممارسة اليوم؟

القصة السابقة ترسم صورة قاتمة للمعاملات على السلسلة في بروتوكولات القائد الفردي غير المرخصة. ومع ذلك، لماذا لا يزال حجم التداول في العديد من DEXs (بورصات لامركزية) على بروتوكولات القائد الفردي يحافظ على صحة جيدة؟ في الواقع، هناك قوتان تعملان معًا لتعويض المشكلات المذكورة:

• لا يستغل القائد سلطته الاقتصادية على نحو كافٍ، لأن القائمين أنفسهم غالبًا ما يكونون مستثمرين بقوة في نجاح سلسلة الكتل الأساسية؛
• قامت التطبيقات بالفعل ببناء حلول/بدائل للتعامل مع هذه المشكلات، بحيث لا تكون هشة أمامها.

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

للوصول إلى صفة القائد على بلوك تشين تمتلك نشاطًا اقتصاديًا فعليًا، تحتاج إلى كمية كبيرة من الضمانات/الرهانات (staked collateral). لذلك، إما أن يمتلك القائد نفسه رهانات كبيرة، أو أن يملك سمعة كافية تجعل حاملي الرموز الآخرين يوكّلون له الرهان. وفي كلتا الحالتين، غالبًا ما تكون الجهات التي تُشغّل العقد الكبيرة كيانات معروفة تكون سمعتها في خطر. وبصرف النظر عن السمعة، فإن الرهان يعني أيضًا أن لدى هؤلاء المشغلين دافعًا ماليًا لتشغيل بلوك تشين تعمل بشكل جيد. لذلك، لم نرَ حتى الآن—بقدر كبير—أن يستغل القادة قوتهم السوقية بالطريقة التي وصفناها أعلاه. لكن هذا لا يعني أن هذه المشكلات غير موجودة.

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

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

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

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

عامل آخر يحافظ على استمرار DeFi هو أن التطبيقات تنقل منطقًا مهمًا إلى خارج السلسلة (off-chain)، وتنشر النتيجة فقط على السلسلة. على سبيل المثال، أي بروتوكول يحتاج إلى إجراء مزادات بسرعة ينفذ ذلك خارج السلسلة. عادةً ما تعمل هذه التطبيقات على مجموعة من عقد مرخصة لتجنب مواجهة مشاكل القائد الخبيث. على سبيل المثال، يقوم UniswapX بتشغيل مزاد هولندي (Dutch auction) خارج شبكة الإيثيريوم الرئيسية لإتمام الصفقة، وبالمثل يقوم CowSwap بتشغيل مزادات دفعات (batch auctions) خارج السلسلة.

رغم أن ذلك قد يعمل مع التطبيقات، فإنه يضع الحجة الأساسية لقيمة الطبقة الأساسية والإنشاء على السلسلة في وضع هش. في عالم يكون فيه تنفيذ منطق التطبيقات خارج السلسلة، تتحول الطبقة الأساسية حرفيًا إلى طبقة تسوية فقط (settlement layer). واحدة من أقوى نقاط البيع لـ DeFi هي قابلية التركيب/التكامل (composability). عندما تحدث كل عمليات التنفيذ في عالم خارج السلسلة، تعيش هذه التطبيقات في بيئات منعزلة فعليًا. كما أن الاعتماد على التنفيذ خارج السلسلة يضيف افتراضات جديدة إلى نموذج الثقة لهذه التطبيقات. لم يعد تشغيل التطبيقات يعتمد فقط على نشاط السلسلة الأساسية؛ بل يجب أن تعمل أيضًا هذه البنية التحتية خارج السلسلة بشكل صحيح.

كيف نحقق القابلية للتنبؤ؟

للتعامل مع هذه المشكلات، نحتاج إلى أن تتوفر في البروتوكولات خاصيتان: قواعد تجميع وترتيب متسقة للمعاملات، وخصوصية للمعاملات قبل تأكيدها (للتعريفات الدقيقة لهذه الخصائص والمناقشات الموسعة، راجع هذه الورقة).

المطلب الأساسي 1: مقاومة المراقبة/التحقق (Anti-censorship)

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

مقاومة المراقبة على المدى القصير: أي معاملة صالحة تصل في وقتها إلى أي عقدة صادقة، لا بد أن تُدرج في البلوك التالي الممكن.

بشكل أدق، نفترض أن البروتوكول يعمل على ساعة ثابتة، حيث يتم توليد كل بلوك في وقت محدد—مثلاً كل 100 ملي ثانية. عندها ما نحتاج إلى ضمانه هو أنه إذا وصلت معاملة إلى عقدة صادقة عند t=250ms، فسيتم إدراجها في البلوك الذي يُولَّد عند t=300ms. ولا ينبغي أن يكون لدى الخصم أي حق في الاختيار بشكل انتقائي بتجميع بعض المعاملات التي سمع بها وترك غيرها.

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

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

وبما أن البروتوكول قادر على ضمان التجميع، فإن الترتيب يصبح—إلى حد ما—أمرًا طبيعيًا. يمكن للبروتوكول استخدام أي قواعد ترتيب حتمية يختارها لضمان ترتيب متسق. أبسط حل هو الفرز حسب رسوم الأولوية (priority fees)، أو قد يسمح للتطبيقات بمرونة في ترتيب المعاملات التي تتفاعل مع حالتها. ما هو أفضل طريقة لترتيب المعاملات لا يزال مجالًا نشطًا للبحث، لكن—على أي حال—لا معنى لقواعد الترتيب إلا عندما يكون الترتيب ضروريًا لتوجيه وصول المعاملات إلى التنفيذ.

المطلب الأساسي 2: الإخفاء (Hidden)

بعد مقاومة المراقبة على المدى القصير، تأتي الخاصية التالية الأكثر أهمية: أن يوفر البروتوكول نوعًا من الخصوصية نسمّيه “الإخفاء”.

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

قد تسمح بروتوكولات تمتلك خاصية “الإخفاء” للعقد بأن تشاهد جميع المعاملات التي تصل إليها بشكل نص واضح (plaintext)، لكن تشترط أن يبقى بقية البروتوكول في حالة عمياء (blind) حتى يتم الوصول إلى التوافق (consensus) ويتم تحديد ترتيب المعاملات في السجل النهائي. على سبيل المثال، قد يستخدم البروتوكول تشفيرًا باستخدام أقفال زمنية (time lock encryption) لإخفاء محتوى الكتل بالكامل حتى تاريخ نهائي محدد؛ أو قد يستخدم تشفيرًا بمشاركة عتبية (threshold encryption) بحيث يتم فك تشفير تلك الكتلة فورًا بعد أن يوافق المجلس/اللجنة على تأكيدها بشكل غير قابل للعكس.

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

نحن نتخلى عن استخدام مفهوم أقوى حيث لا يعرف المستخدم أي معلومات إلا قبل تأكيد المعاملة (مثلًا داخل مجمع ذاكرة مشفر/مشفر بالكامل encrypted mempool)، لأن البروتوكول يحتاج إلى اتخاذ بعض الخطوات كفلاتر للمعاملات المزعجة (garbage). إذا كان محتوى المعاملات مخفيًا بالكامل عن الشبكة، فلن تتمكن الشبكة من فصل المعاملات المزعجة عن المعاملات ذات المعنى. الطريقة الوحيدة لحل هذه المشكلة هي كشف بعض البيانات الوصفية (metadata) غير المخفية كجزء من المعاملة، مثل عنوان مُدفع الرسوم (fee payer address) التي سيتم تحصيلها بغض النظر عما إذا كانت المعاملة صالحة أم لا.

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

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

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

لكي تنافس البلوك تشين البنية التحتية المالية الحالية—بل وتتجاوزها—فإن ما نحتاج إلى حله ليس مجرد مشكلة السعة (throughput).