Paradigm déploie Solar, un compilateur Solidity plus économique que Solady

Présentation

Paradigm a annoncé la sortie de Solar, un compilateur interne pour le langage Solidity. Selon le communiqué, Solar produit du bytecode sans assembly et dépasse les références de consommation de gaz établies par Solady, bibliothèque largement reconnue pour son optimisation manuelle d’assembly. Solady, depuis plusieurs années, représente le plafond d’efficacité du gaz dans l’écosystème EVM grâce à des routines écrites à la main, ce qui impose aux développeurs de maîtriser l’assembly pour réduire les coûts d’exécution.

Fonctionnement et gains de gaz

Solar génère du bytecode en se passant totalement d’instructions d’assembly explicites. Cette approche repose sur une analyse statique approfondie du code source Solidity, qui identifie les motifs de haut niveau pouvant être traduits en séquences d’opcodes plus courtes. Le résultat, mesuré par les benchmarks publiés par Paradigm, montre une consommation de gaz inférieure à celle de Solady pour les mêmes fonctions contractuelles. Par exemple, une fonction de transfert ERC‑20 optimisée avec Solady consomme X gaz (donnée non fournie), tandis que Solar atteint une réduction de plusieurs pourcents, ce qui se traduit en économies significatives à l’échelle des déploiements massifs.

Le gain provient de deux leviers : d’une part, l’élimination du code d’assembly manuel évite les erreurs de calcul d’opcodes ; d’autre part, le compilateur applique des transformations de code qui exploitent les nouvelles instructions EVM introduites par les hard forks récents (e.g., SHL, SHR) de façon plus systématique que les développeurs humains.

Implications sécuritaires et adoption

Solar intègre également une couche de détection des patterns Solidity jugés insecure. Au lieu de laisser la responsabilité aux audits externes, le compilateur rejette ou réécrit automatiquement les constructions à risque (par exemple, l’utilisation non protégée de call.value ou les boucles non bornées). Cette stratégie déplace les garanties de sécurité du processus d’audit vers la chaîne d’outils, réduisant le nombre de vecteurs d’exploitation liés à des implémentations non standard.

Pour les équipes de développement, l’avantage est double : elles peuvent écrire du Solidity « standard » sans recourir à l’assembly, tout en bénéficiant d’une optimisation comparable voire supérieure à Solady. Cependant, l’adoption dépendra de la confiance accordée à la stabilité du compilateur. Les projets existants devront valider que le bytecode généré par Solar conserve les invariants fonctionnels, notamment en comparant les traces d’exécution avec celles produites par le compilateur officiel solc. De plus, les outils de vérification formelle et les suites de tests devront être ré‑exécutés pour chaque mise à jour de Solar afin d’éviter les régressions.

Perspectives et limites

Si Solar réussit à s’imposer, il pourrait réduire la barrière d’entrée pour les développeurs souhaitant optimiser leurs contrats sans expertise en assembly. Néanmoins, le texte ne précise pas la version exacte du compilateur ni le calendrier de diffusion, ce qui rend difficile d’évaluer l’impact à court terme. De plus, l’absence de données chiffrées détaillées (par ex., pourcentages de réduction de gaz, temps de compilation) limite la capacité à quantifier les économies potentielles. Enfin, la compatibilité avec les versions antérieures de Solidity et les frameworks de build (Hardhat, Foundry) reste à confirmer.