Je ne peux pas décider si c'est hilarant ou déprimant 🤷 Il n'y a aucune raison qu'un lit appelle sans cesse à la maison pour réguler le confort. Une unité de contrôle de cette taille peut facilement héberger un GPU pour exécuter un modèle local. Cette chose coûte 3 fois un iPad Pro. Et personne n'a pensé aux modes de défaillance. Folie!

Ethereum doit s'efforcer d'atteindre zéro ressource inoccupée, à tout moment. CPU inactif, bande passante réseau, mémoire == potentiel gaspillé. À court terme : - Assurez-vous qu'Ethereum utilise tout le métal qui lui est alloué de manière productive, à chaque seconde. - L'ingénierie de performance doit être une priorité de premier ordre pour nous. - Combler rapidement l'écart d'optimisation. Je suis convaincu que nous pouvons réduire de moitié les temps de slot juste en optimisant les clients. À long terme : - La conception du protocole doit continuellement respecter le principe de sympathie mécanique. - Le consensus doit être conscient du réseau, et les couches réseau doivent s'optimiser pour les spécificités du protocole Eth. Floutez les lignes. - EL et CL doivent se synchroniser comme des horloges, afin de maximiser le bon débit, en tenant compte de l'architecture des slots, sans risquer le chemin critique pour chacun.

Les attestations sont sur le point de décoller sur Ethereum 🏎️💨 L'ingénierie de performance a révélé un goulot d'étranglement de propagation dans Prysm, lié à la logique de regroupement des signatures BLS. Après avoir ajusté les paramètres, nous avons atteint l'optimalité : impact CPU négligeable et une réduction remarquable de 6x de la latence de propagation par saut (30ms => 5ms). Le PR a déjà été fusionné 🚀 Un grand merci à @BharathVedarth1 pour l'analyse approfondie, et à l'équipe Prysm pour une correction incroyablement rapide !