Durante alguns meses, a equipe de consenso sem estado tem se concentrado em uma pergunta específica: em um mundo onde a ausência de estado / expiração de estado é uma realidade, onde se pode encontrar o estado que precisa?

É uma pergunta difícil por si só, mas piora: num mundo com construtores centralizados e FOCIL, o que acontece quando um construtor descarta parte do estado e, em seguida, uma transação FOCIL aciona um acesso a esse estado descartado?

Queremos que o Ethereum escale, e isso significa que o estado que não é necessário é movido para fora do banco de dados de um cliente para garantir um desempenho contínuo. Mecanicamente, isso cria um risco de que um cliente esteja a faltar dados que deveria manter de acordo com o FOCIL.

Portanto, a escalabilidade está em desacordo com a resistência à censura: é necessário um mecanismo para relaxar o FOCIL a fim de rejeitar uma tx que acesse um estado expirado. Mas não podemos permitir que isso seja uma desculpa para censurar transações também.

A proposta, que vem de uma discussão com @soispoke, é que se o construtor puder demonstrar que uma transação FOCIL toca o estado que é "antigo o suficiente", e se nenhum testemunho foi passado com a transação, então é aceitável rejeitar essa transação. Cabe à carteira fornecer o testemunho.

Não é isso mover o mesmo problema para a carteira? Não é, porque: 1. a carteira pode cobrar uma "taxa de ressurreição" para enviar a transação, então está incentivada a manter o estado expirado. 2. A ressurreição já não está no caminho crítico da produção de blocos.

A razão aqui é que, se um utilizador não tocou na sua conta nos últimos 6 anos, ele pode definitivamente esperar mais alguns minutos para recuperar a sua conta. Se o utilizador não pode esperar, então deve gastar algum gás a cada poucos meses para manter a conta "ativa".

Assim, isso elimina a necessidade de uma ressurreição rápida. Como provamos que um pedaço de estado está expirado? Adicionando um contador de época a esse estado. De acordo com estimativas baseadas em @ngweihan_eth, adicionaríamos 1GB de dados no pior cenário e conseguiríamos deletar 80% do estado!

Isso resolve todos os problemas? Não, as carteiras também podem ser censuradas, e os dados são menos redundantes, portanto, podem ser perdidos. Mas isso significa que o FOCIL não pode ser utilizado para prevenir a expiração do estado. Também aborda de certa forma a questão da experiência do usuário levantada pela expiração do estado / ausência de estado.

Existem muitas mais carteiras do que construtores, e eles ganham mais dinheiro. Portanto, são mais difíceis de censurar. E se as carteiras não quiserem desempenhar esse papel, há espaço para que redes estatais se formem e forneçam isso. No entanto, isso é mais hipotético.

Note que, embora isso exija duas alterações de protocolo, a expiração do estado em si não precisa estar no protocolo.