PANews a rapporté le 27 juillet, en réponse aux remarques du développeur d'Ethereum Péter Szilágyi, qu'Ethereum devient de plus en plus « une vérification décentralisée, mais un contrôle centralisé ». Vitalik Buterin peut confirmer que ce point de vue est faux, puisqu'il vient d'assister à l'atelier de recherche EF la semaine dernière, où diverses discussions ont eu lieu sur la manière de minimiser la centralisation. inclure:
Une analyse approfondie des multi-proposants pour voir si le rôle de constructeur peut être complètement éliminé
Maximiser le pouvoir de l'inclusion sur les listes (FOCIL)
Les réflexions sur le choix de Fork dépendent de l'inclusion des transactions
Analyse du SSF Orbit et idées pour accélérer le déploiement du mécanisme Orbit, qui pourrait réduire le dépôt minimum de plus de 10 fois avant de faire le SSF
Construction de blocs distribués pour PeerDAS :
Analyse réseau et optimisation de la bande passante pour PeerDAS et fullDAS
Rendre la récupération après 51 % d'attaques plus automatisée et moins dépendante de la « couche sociale »
Assurez-vous que les listes d'inclusion s'appliquent pleinement aux transactions (i) blob et (ii) d'abstraction de compte natif (par exemple EIP-7560).
Selon des informations précédentes, Péter Szilágyi (karalabe.eth), développeur principal d'Ethereum, a tweeté que la future direction d'Ethereum, PeerDAS, prévoyait d'augmenter la taille des blocs de données à 32 Mo lors de la prochaine mise à niveau, ce qui aurait un impact négatif sur les producteurs de blocs locaux. . Il a souligné que le temps de propagation des blocs d’Ethereum est très strict, avec seulement 4 secondes pour propager le bloc à l’ensemble du réseau. Bien que PeerDAS divise les sous-réseaux, il doit néanmoins diffuser 32 Mo de données en 4 secondes, ce qui constitue une charge insupportable pour les nœuds domestiques.
