Depuis quelques mois, l'équipe du consensus sans état se concentre sur une question spécifique : dans un monde où l'absence d'état / l'expiration de l'état est une réalité, où peut-on trouver l'état dont on a besoin ?

C'est une question difficile en soi, mais cela devient pire : dans un monde avec des constructeurs centralisés et FOCIL, que se passe-t-il lorsqu'un constructeur abandonne une partie de l'état, et qu'ensuite une transaction FOCIL déclenche un accès à cet état abandonné ?

Nous voulons qu'Ethereum se développe, et cela signifie que l'état qui n'est pas nécessaire est déplacé en dehors de la base de données d'un client pour garantir une performance continue. Mécaniquement, cela crée un risque qu'un client manque des données qu'il est censé détenir selon FOCIL.

Ainsi, la scalabilité est en contradiction avec la résistance à la censure : un mécanisme est nécessaire pour assouplir le FOCIL afin de rejeter une tx accédant à un état expiré. Mais nous ne pouvons pas non plus permettre que cela soit une excuse pour censurer les transactions.

La proposition, issue d'une discussion avec @soispoke, est que si le constructeur peut démontrer qu'une transaction FOCIL touche l'état qui est "assez ancien", et si aucun témoin n'a été transmis avec la transaction, alors il est acceptable de rejeter cette transaction. C'est à l'utilisateur du portefeuille de fournir le témoin.

N'est-ce pas déplacer le même problème vers le portefeuille ? Ce n'est pas le cas, car : 1. le portefeuille peut facturer des "frais de résurrection" pour envoyer la transaction, donc il est incité à maintenir l'état expiré. 2. La résurrection n'est plus sur le chemin critique de la production de blocs.

La raison ici est que si un utilisateur n'a pas touché à son compte depuis les 6 dernières années, il peut certainement attendre quelques minutes de plus pour récupérer son compte. Si l'utilisateur ne peut pas attendre, alors il devrait dépenser un peu de gaz tous les quelques mois pour garder le compte "actif".

Cela élimine donc le besoin d'une résurrection rapide. Comment prouvons-nous qu'un morceau d'état est expiré ? En ajoutant un compteur d'époque à cet état. Selon les estimations basées sur @ngweihan_eth, nous ajouterions au pire 1 Go de données, et nous pourrions supprimer 80 % de l'état !

Cela résout-il tous les problèmes ? Non, les portefeuilles peuvent également être censurés, et les données sont moins redondantes, donc elles peuvent être perdues. Mais cela signifie que FOCIL ne peut pas être utilisé pour prévenir l'expiration de l'état. Cela aborde également en partie le problème d'UX posé par l'expiration de l'état / l'absence d'état.

Il y a beaucoup plus de portefeuilles que de créateurs, et ils gagnent plus d'argent. Ils sont donc plus difficiles à censurer. Et si les portefeuilles ne veulent pas jouer ce rôle, il y a de la place pour que des réseaux d'État se forment et fournissent cela. C'est cependant plus hypothétique.

Notez que, bien que cela nécessite deux changements de protocole, l'expiration de l'état elle-même n'a pas besoin d'être dans le protocole.