a16z تتحدث عن مستقبل السوق على السلسلة: لماذا التنبؤ هو الأساس الرئيسي؟

撰文：Pranav Garimidi、Joachim Neu 和 Max Resnick，a16z crypto

编译：Glendon，Techub News

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

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

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

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

الحالة الحالية واحتياجات المستقبل

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

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

ما مدى صعوبة تحقيق القابلية للتنبؤ؟

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

بالنسبة لأي بلوكشين يتعامل مع الأنشطة المالية، يكون الزعيم في وضع متميز. إذا قرر الزعيم الوحيد عدم إدراج معاملة معينة، فإن العلاج الوحيد هو الانتظار حتى يأتي الزعيم التالي الذي يرغب في إدراج تلك المعاملة. في الشبكات غير المصرح بها، يكون لدى الزعيم حافز لتحقيق الربح، مما يُعرف عمومًا بـ 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، يظل توقع كل من Alice وBob لسعر الأصول عند انتهاء المزاد (t=1) مساوياً لـ pt. بعبارة أخرى، في أي لحظة، يتوقع Alice وBob أن السعر عند انتهاء المزاد يساوي السعر الذي يرونه حاليًا. قواعد المزاد بسيطة: الفائز هو من يقدم أعلى عرض بين Alice وBob، ويدفع عرضه.

الحاجة إلى مقاومة الرقابة

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

الحاجة إلى إخفاء المعلومات

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

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

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

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

ما تم وصفه أعلاه يرسم صورة قاتمة لتداولات السلسلة في أي بروتوكول يعتمد على زعيم واحد غير مصرح به. ومع ذلك، لا تزال أحجام التداول على البورصات اللامركزية (DEX) على العديد من البروتوكولات ذات الزعيم الواحد صحية، لماذا؟

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

لم يستغل الزعماء قوتهم الاقتصادية بالكامل، لأن لديهم عادةً مصالح كبيرة في نجاح سلسلة الصناعة الأساسية؛

بنت التطبيقات آليات تجاوز مناسبة لتفادي التأثر بهذه المشكلات.

على الرغم من أن هذين العاملين يسمحان لـ DeFi بالاستمرار، فإنه على المدى الطويل، ليسا كافيين لجعل السوق على السلسلة تتنافس حقًا مع السوق خارج السلسلة.

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

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

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

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

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

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

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

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

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

الشرط الأول: مقاومة الرقابة

نلخص الخاصية الأولى بـ “مقاومة الرقابة قصيرة الأجل”. إذا كان بإمكان بروتوكول ضمان أن أي معاملة تصل إلى عقدة صالحة ستدرج في الكتلة التالية الممكنة، فإن البروتوكول يتمتع بمقاومة رقابة قصيرة الأجل.

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

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

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

المطلب الثاني: الخصوصية

بعد توفر مقاومة الرقابة قصيرة الأجل، فإن الخاصية المهمة التالية التي يحتاج البروتوكول لتقديمها هي نوع من الخصوصية التي نسميها “الخصوصية”.

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

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

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

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

الخاتمة

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

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