Durante unos meses, el equipo de consenso sin estado se ha centrado en una pregunta específica: en un mundo donde la falta de estado / la expiración del estado es una realidad, ¿dónde se puede encontrar el estado que se necesita?

Es una pregunta difícil en sí misma, pero se complica: en un mundo con constructores centralizados y FOCIL, ¿qué sucede cuando un constructor elimina parte del estado y luego una transacción FOCIL activa un acceso a ese estado eliminado?

Queremos que Ethereum escale, y esto significa que el estado que no se necesita se mueve fuera de la base de datos de un cliente para asegurar un rendimiento continuo. Mecánicamente, esto crea un riesgo de que un cliente esté faltando datos que se supone que debe mantener según FOCIL.

Así que la escalabilidad está en conflicto con la resistencia a la censura: se necesita un mecanismo para relajar FOCIL con el fin de rechazar una tx que accede a un estado expirado. Pero no podemos permitir que esto sea una excusa para censurar transacciones tampoco.

La propuesta, que surge de una discusión con @soispoke, es que si el constructor puede demostrar que una transacción FOCIL toca el estado que es "suficientemente antiguo", y si no se pasó ningún testigo con la transacción, entonces está bien rechazar esa transacción. Depende de la billetera proporcionar el testigo.

¿No es esto mover el mismo problema a la billetera? No lo es, porque: 1. la billetera puede cobrar una "tarifa de resurrección" para enviar la transacción, por lo que está incentivada a mantener el estado expirado. 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 recuperar su cuenta. Si el usuario no puede esperar, entonces debería gastar algo de gas cada pocos meses para mantener la cuenta "activa".

Así que esto elimina la necesidad de una resurrección rápida. ¿Cómo probamos que un fragmento de estado ha expirado? 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 billeteras también pueden ser censuradas, y los datos son menos redundantes, por lo que pueden perderse. Pero esto significa que FOCIL no puede ser aprovechado para prevenir la expiración del estado. También aborda de alguna manera el problema de la experiencia del usuario planteado por la expiración del estado / la falta de estado.

Hay muchas más carteras que constructores, y ellos ganan más dinero. Por lo tanto, 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 proporcionen esto. Sin embargo, esto es más hipotético.

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