dvt

# ⚙️ GLAMSTERDAM : Ethereum réécrit sa production de blocs, et la DVT devient une infrastructure critique
Fusaka (déc. 2025) a scalé la data availability avec PeerDAS. Glamsterdam (cible : Q3 2026, fenêtre interne fin août) s'attaque au cœur du réacteur : la construction et l'exécution des blocs. Deux EIPs headliners, et une conséquence directe pour l'architecture des validateurs. Thread technique. 🧵
---
## 1️⃣ EIP-7732 : ePBS (Enshrined Proposer-Builder Separation)
Aujourd'hui, 80-90% des blocs Ethereum passent par des relais externes type MEV-Boost. C'est un point de confiance hors-protocole, donc un vecteur de centralisation.
ePBS enchâsse la séparation proposer/builder dans le protocole :
- Enchères, engagements et paiements des builders deviennent trustless et in-protocol → suppression du middleware de confiance
- La fenêtre de propagation du payload passe de ~2s à ~9s → débloque des payloads beaucoup plus lourds et plus de blobs dans les futurs forks BPO
- Nouveau devoir de validateur : le PTC (Payload Timeliness Committee), qui atteste séparément la timeliness du payload via une logique à double deadline
👉 Point clé : le protocole doit maintenant gérer la non-livraison ou le désaccord entre deux parties séquentielles dans le consensus ("partial blocks"). C'est LA raison pour laquelle Glamsterdam avance plus lentement que Fusaka.
## 2️⃣ EIP-7928 : BALs (Block-Level Access Lists)
L'exécution est aujourd'hui séquentielle : aucun nœud ne sait quels comptes/slots de storage une tx va toucher avant de l'exécuter.
Les BALs attachent à chaque bloc une carte pré-déclarée des accès d'état (comptes + storage keys + valeurs post-exécution) :
- Prefetch d'état en parallèle
- Exécution simultanée des tx non conflictuelles
- Sync "executionless" possible
👉 C'est le levier qui permet de viser une gas limit de 60M → 200M (tests en cours à 150M de référence), avec EIP-8037 qui reprice le coût de création d'état pour contenir le state bloat.
## 3️⃣ Où OBOL entre en jeu
Glamsterdam change le métier de validateur : nouvelle duty d'attestation PTC, contraintes de latence et d'uptime accrues, hardware légèrement plus exigeant (lectures disque parallèles). Chaque milliseconde de disponibilité compte davantage.
C'est exactement le problème que résout la DVT (Distributed Validator Technology) d'Obol :
- Charon : middleware qui splitte la clé BLS d'un validateur via DKG entre plusieurs opérateurs indépendants
- Signature à seuil : le cluster reste opérationnel tant que ≥66% des nœuds sont up (redondance actif/actif, aucune clé complète n'existe au runtime)
- Diversité de clients native → résilience aux bugs de client, critique quand TOUS les CL/EL doivent shipper ePBS en parité
📊 État des lieux : ~600 000 ETH (~$2B) déployés sur des Distributed Validators, ~1,6% du staked ETH, avec un objectif affiché de 10% fin 2026. Adoption : Lido CSM v2 (~70% des candidats ICS via Obol Techne), EtherFi, Bitcoin Suisse, et un premier déploiement souverain (LTIN, Liechtenstein).
## 4️⃣ La thèse
Post-Glamsterdam, un validateur mono-machine qui rate sa fenêtre PTC ou son attestation devient un coût mesurable. Les clusters DV tolérants aux pannes deviennent l'architecture par défaut du staking institutionnel, au moment même où les ETF stakés poussent l'institutionnel vers le yield on-chain.
⚠️ Les risques, sans filtre :
- Timeline : ePBS est complexe, un slip vers Q4 2026 est plausible (la parité cross-client est le goulot)
- Le token OBOL reste un pari sur la capture de valeur future : l'infrastructure est adoptée, mais le lien économique token ↔ TVL (Economic Engine) est encore en construction, et les unlocks 2026 pèsent
- Infrastructure ≠ token. Faites la distinction dans votre sizing.
---
L'upgrade la plus importante depuis The Merge redéfinit qui construit les blocs et comment ils s'exécutent. La question n'est pas de savoir si le staking se décentralise en clusters (c'est déjà en cours), mais qui capture la valeur de cette transition.
DYOR. Pas un conseil financier.
#Ethereum #Glamsterdam #ePBS #DVT $ETH $OBOL