Comment fonctionne Velas : Proof of History, EVM et staking délégué

Pour comprendre Velas, il faut trois briques : un moyen d’ordonner vite les événements, un moyen pour les validateurs de se mettre d’accord, et un moteur pour exécuter des smart contracts. Velas reprend les deux premières de Solana et y ajoute une couche d’exécution compatible Ethereum. Voyons comment tout cela s’assemble.

Proof of History : une horloge pour le réseau

La plupart des blockchains perdent du temps parce que les nœuds doivent débattre de ce qui s’est passé en premier. La réponse de Solana s’appelle Proof of History : une chaîne de hachages où chaque étape prouve qu’un peu de temps s’est écoulé depuis la précédente. Imaginez un chronomètre partagé, fabriqué avec des mathématiques. Comme chaque nœud peut vérifier l’ordre au lieu de le négocier, les blocs sortent en une fraction de seconde. Velas a hérité de cette conception, d’où des temps de bloc courts. Vous pouvez suivre la hauteur de bloc et l’activité sur l’explorateur natif.

Tower BFT et vote des validateurs

Ordonner n’est pas s’accorder. Les validateurs doivent encore voter pour savoir quelle branche fait foi. Tower BFT est ce protocole de vote, une variante de la tolérance aux pannes byzantines qui s’appuie sur l’horloge de Proof of History pour rendre chaque vote de plus en plus coûteux à renier. Chaque vote engage le validateur sur une branche pour une durée croissante : changer de camp devient cher. Une transaction est d’autant plus sûre que de nombreux votes pondérés par le stake s’empilent au-dessus de son bloc.

Delegated proof of stake

Un validateur doit disposer de stake pour participer, mais vous n’avez pas besoin de gérer un serveur pour toucher une part des récompenses. Les détenteurs de VLX délèguent leurs jetons à un validateur de confiance. Celui-ci vote avec ce poids et garde une commission ; le reste revient aux délégants. Déléguer ne transfère pas la propriété : vos VLX restent dans votre compte de stake et vous pouvez redéléguer plus tard. Le site officiel affiche le nombre de validateurs et le total staké ; un réseau sain compte beaucoup de validateurs sans qu’aucun n’en domine le jeu. Notre page sur les validateurs explique comment les évaluer, et le guide du staking détaille la marche à suivre.

L’EVM intégrée

L’Ethereum Virtual Machine est l’environnement qui exécute le bytecode Solidity. Velas en embarque une à côté de son moteur natif. Une transaction envoyée à une adresse EVM est traitée par ce côté, avec les mêmes méthodes JSON-RPC que celles attendues par les outils Ethereum, par exemple eth_getBalance. C’est pourquoi un wallet comme MetaMask peut se connecter avec une simple configuration de réseau. Le RPC public de la partie EVM est ouvert, et notre suivi de transactions l’interroge directement depuis votre navigateur. Voir la compatibilité EVM pour la procédure.

Deux mondes d’adresses

Cette dualité est à la fois l’atout et la courbe d’apprentissage. Si vous n’utilisez que le côté EVM, le réseau se comporte comme n’importe quelle autre chaîne compatible Ethereum. Les utilisateurs avancés et les validateurs, eux, interagissent avec le côté natif.

Un exemple concret

Vous envoyez des VLX depuis un wallet EVM vers un ami : la transaction part en JSON-RPC, est ordonnée par l’horloge Proof of History, votée par les validateurs, puis apparaît sur l’explorateur EVM avec un hash en 0x. Pour un stake, en revanche, vous créez un compte de stake côté natif, lié à un validateur. Même pièce, deux portes d’entrée.

Que dit-on de l’IA ?

La documentation Velas parle d’un delegated proof of stake « amélioré par l’IA ». Elle le présente comme une aide d’apprentissage automatique côté consensus, par exemple pour évaluer le comportement des validateurs, et non comme un chatbot logé dans la chaîne. Nous détaillons ce qui est vérifiable dans l’article sur l’IA.

Ce que « vitesse » veut vraiment dire

« Jusqu’à 75 000 TPS » figure sur le site officiel. C’est un plafond de conception dans des conditions idéales, pas la charge moyenne. Pour l’utilisateur, deux mesures comptent : le délai de confirmation et le coût. Les deux sont bons sur Velas en temps normal. Les chiffres sont dans frais et vitesse, et la comparaison directe dans Velas contre Solana.

Limites à garder en tête

Un code forké doit suivre les améliorations de l’amont, et Solana a beaucoup évolué depuis la bifurcation. L’équipe Velas maintient sa propre version : fonctionnalités et correctifs de sécurité arrivent à son rythme. La disponibilité du réseau dépend de validateurs qui restent en ligne. Ce ne sont pas des signaux d’alarme en soi, mais autant de raisons de consulter la documentation et la page actualités avant de dépendre du projet.

Ce que cela change dans la pratique

Toute cette mécanique n’a de valeur que si elle se traduit par une expérience utilisable. Pour l’utilisateur, cela veut dire une transaction confirmée rapidement et des frais bas, du moins dans les conditions décrites par la documentation. Pour le développeur, cela signifie qu’il peut réutiliser ses compétences Solidity sans apprendre un nouveau langage.

Gardez en tête que les performances annoncées, notamment le plafond théorique de 75 000 transactions par seconde, sont des maxima de conception et non des mesures quotidiennes. Pour juger l’activité réelle, le mieux reste d’observer les blocs et les transactions sur les explorateurs publics. Une architecture élégante ne garantit ni l’adoption ni la liquidité : ce sont deux sujets distincts, que nous traitons dans d’autres pages.

Enfin, la coexistence de deux univers, le réseau natif et la couche EVM, a une conséquence concrète : deux familles d’adresses et deux explorateurs. Beaucoup de confusions de débutants viennent de là, d’où l’intérêt de savoir dans quel monde se trouve la transaction que vous suivez.