Durante unos meses, el equipo de consenso apátrida se ha centrado en una cuestión específica: en un mundo donde la apatridia / la expiración del estado son una realidad, ¿dónde se encuentra el estado que se necesita?

Es una pregunta difícil en sí misma, pero empeora: en un mundo con constructores centralizados y FOCIL, ¿qué ocurre cuando un constructor pierde parte del estado y luego una transacción FOCIL activa el acceso a ese estado perdido?

Queremos que Ethereum escale, y esto significa que el estado que no se necesita se mueve fuera de la base de datos del cliente para asegurar un rendimiento continuo. Mecánicamente, esto crea el riesgo de que un cliente pierda datos que debería almacenar según FOCIL.

Así que la escalabilidad va en conflicto con la resistencia a la censura: se necesita un mecanismo para relajar el FOCIL y así rechazar un tx accediendo al estado caducado. Pero tampoco podemos permitir que esto sirva de excusa para censurar las transacciones.

La propuesta, que viene de una conversación con @soispoke, es que si el constructor puede demostrar que un traslado FOCIL toca el estado que es "lo suficientemente antiguo", y si no se ha aprobado ningún testigo con el traslado, entonces está bien rechazarlo. Depende de la cartera proporcionar al testigo.

¿No es esto mover el mismo problema a la cartera? No lo es, porque: 1. La cartera puede cobrar una "comisión de resurrección" para enviar la transacción, por lo que se incentiva a conservar el estado caducado. 2. La resurrección ya no está en el camino crítico de la producción de bloques.

La razón aquí es que si un usuario no ha tocado su cuenta en los últimos 6 años, definitivamente puede esperar unos minutos más para recuperarla. Si el usuario no puede esperar, entonces debería gastar algo de gasolina cada pocos meses para mantener la cuenta "caliente".

Así que esto elimina la necesidad de una resurrección rápida. ¿Cómo demostramos que un trozo de estado está caducado? Añadiendo un contador de época a ese estado. Según estimaciones basadas en @ngweihan_eth, añadiríamos 1GB de datos en el peor de los casos y podríamos eliminar el 80% del estado.

¿Esto resuelve todos los problemas? No, las carteras también pueden ser censuradas, y los datos son menos redundantes, por lo que pueden perderse. Pero esto significa que el FOCIL no puede aprovecharse para evitar la caducidad del estado. También aborda en parte el problema de experiencia de usuario que plantea la caducidad estatal o la apatridia.

Hay muchas más carteras que constructores, y ellos ganan más dinero. Así que son más difíciles de censurar. Y si las carteras no quieren desempeñar este papel, hay espacio para que se formen redes estatales y lo proporcionen. Esto es más bien hipotético.

Ten en cuenta que, aunque esto requiere dos cambios de protocolo, la expiración de estado en sí no necesita estar dentro del protocolo.