لبضعة أشهر، ركز فريق الإجماع بلا دولة على سؤال محدد: في عالم أصبح فيه انعدام الجنسية / انتهاء الدولة واقعا، أين يجد المرء الحالة التي يحتاجها؟

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

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

لذا فإن قابلية التوسع تتعارض مع مقاومة الرقابة: هناك حاجة إلى آلية لتخفيف FOCIL لرفض وصول الإرسال إلى حالة منتهية. لكن لا يمكننا السماح لهذا بأن يكون عذرا لمراقبة المعاملات أيضا.

الاقتراح، الناتج عن نقاش مع @soispoke، هو أنه إذا استطاع البناء إثبات أن TX FOCIL يلامس الحالة "القديمة بما فيه الكفاية"، وإذا لم يتم تمرير شاهد مع المعالج، فمن المقبول رفض ذلك النص. الأمر متروك للمحفظة لتقديم الشاهد.

أليس هذا نقل نفس المشكلة إلى المحفظة؟ ليس كذلك، لأن: 1. يمكن للمحفظة فرض "رسوم إحياء" لإرسال المعاملة، لذا فهي متحفزة للاحتفاظ بالحالة المنتهية. 2. لم يعد الإحياء على المسار الحرج لإنتاج الكتل.

السبب هنا هو أنه إذا لم يلمس المستخدم حسابه خلال السنوات الست الماضية، يمكنه بالتأكيد الانتظار لبضع دقائق أخرى لاستعادة حسابه. إذا لم يستطع المستخدم الانتظار، فعليه أن ينفق بعض الوقود كل بضعة أشهر للحفاظ على "ساخن" الحساب.

لذا هذا يلغي الحاجة إلى الإحياء السريع. كيف نثبت أن قطعة من الدولة منتهية الصلاحية؟ عن طريق إضافة عداد عصر لتلك الحالة. وفقا للتقديرات المبنية على @ngweihan_eth، سنضيف 1GB من البيانات في أسوأ الأحوال، وسنتمكن من حذف 80٪ من الولاية!

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

هناك محافظ أكثر بكثير من البنائين، وهم يجنون أرباحا أكثر. لذا من الصعب حجبها. وإذا لم ترغب المحافظ في لعب هذا الدور، فهناك مجال لشبكات الدولة لتشكيل وتوفير ذلك. لكن هذا أكثر افتراضا.

لاحظ أنه، رغم أن هذا يتطلب تغييرين في البروتوكول، إلا أن صلاحية الحالة نفسها لا تحتاج لأن تكون ضمن البروتوكول.