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

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

@MaxResnick1 أيضا لا أفهم سبب تكرارك أنه أسرع تماما من حيث الحالة النهائية. من حيث الكمون ، من الواضح أنه كذلك ولم يكن الهدف من رسالتي