Rubriques tendance
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Bien que je pense que l'ePBS est la mauvaise direction pour le protocole, dans un souci d'exactitude technique, je dois le défendre sur un point.
Bien que l'ePBS ait un problème d'"optionnalité", il n'a pas de problème de "option gratuite", car le paiement du constructeur est inconditionnel. L'optionnalité rend le créneau plus précieux, donc le constructeur devrait enchérir davantage lors de l'enchère.
Cela signifie toujours qu'il y aura des blocs sautés, et cela signifie que plus de MEV est extrait des utilisateurs, mais la valeur de l'option revient au proposeur, pas au constructeur (si la construction est compétitive).
7 août, 14:16
J'ai été surpris d'apprendre que l'ePBS (EIP 7732) est considéré comme susceptible d'être programmé pour Glamsterdam lors de l'appel ACD de demain, et en particulier qu'il est vu comme un substitut à l'exécution différée (comme l'EIP 7886).
Je n'ai jamais entendu de très bonne raison de faire de l'exécution différée au niveau du consensus plutôt qu'au niveau de l'exécution. Contrairement à l'EIP 7886, l'ePBS n'aide pas à simplifier les constructeurs : ils doivent toujours exécuter le bloc complet pour générer la racine d'état.
Comme beaucoup l'ont souligné, le problème d'optionnalité semble mauvais (8 secondes pour qu'un constructeur annule son bloc !). Même lorsque l'option n'est pas exercée, cela pourrait ajouter beaucoup de latence avant que les utilisateurs puissent voir si leur transaction a été incluse.
Mais cela semble aussi être un autre changement complexe qui n'aide pas les utilisateurs, ce que je pensais qu'Ethereum cherchait à dépasser.
9,66K
Meilleurs
Classement
Favoris