Commit-Boost prend en charge Stader : configurez vos relays MEV sans lister manuellement vos validateurs
Les opérateurs de nœuds Stader qui utilisent Commit-Boost peuvent désormais charger automatiquement les clés publiques de leurs validateurs depuis les registres onchain du protocole.
Chez Stakely, nous avons contribué cette fonctionnalité au client open source Commit-Boost afin d'ajouter une prise en charge native des registres de validateurs de Stader. Elle est disponible à partir de la pre-release v0.10.0-rc4 et évite de devoir copier et maintenir manuellement une liste de pubkeys dans le fichier de configuration.
L'objectif est simple : les validateurs Stader doivent utiliser la configuration de relays MEV qui leur est attribuée, y compris lorsque l'opérateur ajoute de nouveaux validateurs.
Qu'est-ce que Commit-Boost ?
Lorsqu'un validateur Ethereum propose un bloc, il peut utiliser des relays MEV afin de recevoir des blocs construits par des builders spécialisés. Ce flux est appelé Proposer-Builder Separation, ou PBS. Le logiciel qui relie le validateur à ces relays est le sidecar MEV, historiquement MEV-Boost.
Commit-Boost est un sidecar open source pour les validateurs Ethereum, compatible avec la Builder API utilisée par MEV-Boost. Il permet de connecter les validateurs à des relays MEV et d'intégrer d'autres modules liés aux commitments du proposer, comme les preconfirmations.
Pour un opérateur, il peut être utilisé dans le flux traditionnellement couvert par MEV-Boost. Le beacon node communique avec Commit-Boost via la même interface standard, tandis que le client gère les demandes de headers et de payloads auprès des relays configurés.
L'une de ses fonctions les plus utiles est le multiplexer, ou mux. Il permet d'appliquer différentes configurations de relays à des groupes précis de validateurs au sein d'une même instance.
Cela est utile lorsqu'un opérateur combine ses propres validateurs avec des validateurs d'un protocole comme Stader, car chaque groupe peut nécessiter une politique de relays distincte. Le choix des relays doit toujours respecter les exigences du protocole et les politiques opérationnelles de l'opérateur.
Le problème des listes de clés maintenues à la main
Pour appliquer une configuration de relays à un groupe de validateurs, le mux doit identifier les clés publiques qui composent ce groupe.
Jusqu'à présent, un opérateur Stader disposait de deux options :
- ajouter manuellement les pubkeys dans
config.toml, viavalidator_pubkeys, ou dans un fichier JSON ; - maintenir un endpoint HTTP dédié qui fournit cette liste de clés.
Ces deux options dépendent d'une liste constamment à jour. Si un validateur Stader est ajouté sans être intégré à la configuration de Commit-Boost, il continuera à utiliser la configuration de relays par défaut, au lieu de celle qui correspond à son groupe.
Commit-Boost permettait déjà de charger des validateurs depuis les registres onchain d'autres protocoles. Avec la contribution de Stakely, il peut maintenant aussi le faire pour Stader.
La solution : charger automatiquement le registre de Stader
Stader maintient des registres de validateurs par opérateur pour ses pools permissionless et permissioned.
Le nouveau loader stader permet à Commit-Boost d'interroger le registre approprié au démarrage. Pour cela, il utilise le node_operator_id de l'opérateur et le pool Stader concerné.
Le flux fonctionne ainsi :
- Il identifie le contrat de registre du pool sélectionné.
- Il interroge le nombre de clés enregistrées pour l'opérateur.
- Il récupère les pubkeys par lots via RPC.
- Il attribue ces clés au mux et aux relays définis pour ce groupe.
Lorsque enable_refreshing est activé, Commit-Boost consulte à nouveau le registre périodiquement. Les validateurs ajoutés par la suite peuvent donc être inclus dans la configuration sans maintenir de listes de clés à la main.
Comment configurer le loader Stader
Vous aurez besoin de Commit-Boost v0.10.0-rc4, ou d'une version ultérieure qui comprend cette fonctionnalité, ainsi que d'un accès à un endpoint RPC Ethereum mainnet.
Le loader Stader est actuellement disponible sur mainnet. Si vous n'avez pas encore installé Commit-Boost, consultez d'abord son guide d'installation officiel.
1. Définir la configuration PBS de base
Dans config.toml, configurez rpc_url dans la section [pbs]. Commit-Boost utilisera cet endpoint pour interroger le registre onchain de Stader.
chain = "Mainnet"
[pbs]
port = 18550
rpc_url = "http://VOTRE_EXECUTION_CLIENT:8545"
# Default relays for validators NOT included in any mux
[[relays]]
url = "https://[email protected]"
L'endpoint peut être votre propre execution client ou un fournisseur RPC compatible.
2. Ajouter un mux avec le loader Stader
Définissez ensuite le mux et indiquez votre ID d'opérateur ainsi que le pool dans lequel vous opérez, permissionless ou permissioned :
[[mux]]
id = "stader-validators"
loader = { registry = "stader", node_operator_id = 42, stader_pool = "permissionless", enable_refreshing = true }
[[mux.relays]]
id = "relay-1"
url = "https://[email protected]"
[[mux.relays]]
id = "relay-2"
url = "https://[email protected]"
Les champs du loader sont les suivants :
| Champ | Obligatoire | Description |
|---|---|---|
registry |
Oui | Utilisez "stader" pour charger le registre de Stader. |
node_operator_id |
Oui | L'identifiant numérique de l'opérateur dans le registre Stader. |
stader_pool |
Oui | "permissionless" ou "permissioned", selon le pool dans lequel le nœud opère. |
enable_refreshing |
Non | Lorsque ce paramètre est défini sur true, il actualise périodiquement la liste de clés. |
Vous ne connaissez pas votre
node_operator_id? Vous pouvez le consulter dans le tableau de bord opérateur de Stader ou dans le contrat de registre concerné.
3. Redémarrer et vérifier les logs
Après avoir appliqué la configuration, redémarrez Commit-Boost et vérifiez les logs du module PBS. Vous devriez voir le chargement des clés depuis le registre de Stader.
Deux erreurs fréquentes permettent d'identifier une configuration incomplète :
Stader registry requires RPC URL to be set in the PBS config:rpc_urlest absent de[pbs].Stader registry requires stader_pool to be set in the mux config:stader_poolest absent de la configuration du loader.
Vérifiez que le nombre de clés chargées dans le mux correspond aux validateurs enregistrés pour votre opérateur. À partir de ce moment, les propositions de blocs de ce groupe utiliseront les relays définis dans le mux.
Notes et ressources
- Mainnet uniquement, pour le moment : les contrats de registre configurés correspondent à Ethereum mainnet. Cette version ne prend pas en charge les testnets.
- Pre-release : la fonctionnalité est incluse dans
v0.10.0-rc4et fera partie de la prochaine release stablev0.10.0. Si vous préférez attendre la version stable, la configuration sera exactement la même. - Relays par défaut : les validateurs qui n'appartiennent à aucun mux continueront à utiliser les relays de la section globale
[[relays]]. Vous pouvez donc combiner les validateurs Stader avec d'autres groupes de validateurs dans la même instance.
Ressources
- Documentation de Commit-Boost
- Documentation pour les opérateurs de nœuds Stader
- Release v0.10.0-rc4 de Commit-Boost
Une contribution issue de l'opération quotidienne
Chez Stakely, en plus d'opérer des validateurs sur des dizaines de réseaux, nous opérons des validateurs Ethereum, notamment en tant qu'opérateur Stader, et utilisons Commit-Boost en production.
Cette contribution est née d'un besoin opérationnel concret : éviter qu'une liste de clés maintenue manuellement devienne une source de maintenance et d'erreurs. En contribuant le loader upstream, tout opérateur Stader peut adopter le même flux.
Vous pouvez consulter la contribution et suivre l'évolution du projet dans le repository de Commit-Boost. Si vous opérez des nœuds Stader et avez des questions sur la configuration, contactez-nous. Nous serons ravis de vous aider.
