Solidity : le langage qui peut te ruiner

Solidity ressemble à du JavaScript. C’est rassurant. C’est aussi un piège.

Le paradoxe, c’est que la moindre erreur peut coûter des millions. Pas parce que le langage est “mauvais”.

C’est parce que ton code devient public. Et il devient exécutable par tout le monde, 24/7.

Dans une app classique, tu patches vite. Dans Ethereum, tu patches parfois tard. Ou jamais.

Si tu comprends Solidity, tu comprends pourquoi les audits existent. Et pourquoi ils ne suffisent pas.

Cadre mental

Référence officielle: Ethereum.org — Développer.

Imagine que ton programme soit un coffre-fort. Chaque ligne est un mécanisme. Chaque bug est une serrure oubliée.

Solidity est un langage orienté smart contracts. Il compile vers du bytecode EVM. C’est ça qui tourne vraiment.

Le cadre mental est simple. Le code est la règle. Et la règle est appliquée sans pitié, même si tu as “mal voulu”.

Tu dois aussi penser en coût. Lire et écrire dans le storage coûte du gas. Boucler coûte du gas. Copier des données coûte du gas.

Enfin, pense en adversaire. N’importe qui peut appeler tes fonctions, dans l’ordre qu’il veut. Il peut aussi combiner tes appels avec d’autres contrats.

Ce cadre te donne une discipline. Tu écris pour un environnement hostile, pas pour un utilisateur poli.

concept principal

Solidity te permet de définir des variables, des fonctions, et des événements. Tout ça vit dans un contrat déployé à une adresse.

Les variables “state” sont stockées dans le storage. Elles survivent entre les transactions. C’est différent d’un serveur classique.

Les fonctions peuvent être view, pure, ou modifier l’état. Si tu modifies l’état, tu consommes du gas et tu touches le consensus.

Un exemple concret. Une fonction transfer dans un ERC-20 modifie deux soldes. Elle émet un event Transfer. L’event est crucial pour les indexeurs.

Un autre exemple. Une fonction approve ne transfère rien. Elle écrit une permission. C’est pour ça que les scams adorent les approvals.

Le langage a aussi des détails dangereux. Le fallback et receive peuvent être appelés lors d’un transfert d’ETH.

Si tu fais des appels externes, tu ouvres la porte à la reentrancy. Tu dois alors structurer l’ordre: checks, effects, interactions.

Depuis Solidity 0.8, les overflows sont gérés par défaut. Avant, c’était une source massive de bugs. Ce détail montre l’évolution du langage.

Enfin, beaucoup de projets utilisent des proxies. Le code “logique” peut changer, mais l’adresse reste. C’est pratique. C’est aussi un risque si l’admin est compromis.

implications et applications

Pour aller plus loin, lis MEV : comprendre le risque.

Pour aller plus loin, lis Smart contracts expliqués.

Pour rendre solidity programming concret, garde une règle simple: tu dois pouvoir expliquer l’action sans jargon. Si tu ne peux pas, tu risques de signer trop vite. Ethereum est permissif. Les erreurs viennent souvent de l’interface et des habitudes. Donc ralentis, lis, puis teste avec un montant faible. C’est comme ça que tu construis une vraie intuition.

Un bon exercice est de comparer l’intention et l’exécution. Ton intention est “je swap”. L’exécution est une série d’appels. Tu peux voir ces appels dans un explorateur. Tu vois alors les approvals, les transferts, et les events. Ce réflexe t’apprend à ne pas dépendre d’un bouton. Et il te rend plus résistant aux clones. Tu comprends le système, pas juste l’app.

Garde aussi des chiffres repères. Ils te donnent une boussole quand tu hésites. Sur Ethereum, un transfert simple a souvent un coût stable en gas. Les actions complexes varient selon l’état, le mempool et la concurrence. Donc l’outil peut te surprendre. Mais le cadre reste simple: tu payes du calcul et du stockage partagés. Tu peux réduire le risque en planifiant, et en testant petit.

Si tu ne peux pas l’expliquer, tu ne le signes pas. C’est une règle simple.

Lis les logs et les events. C’est le reçu de ton action.

Un coût ne doit pas te surprendre. Si ça surprend, tu vérifies.

Quand c’est flou, tu testes plus petit. La clarté vient par étapes.

Compare une action simple et une action DeFi. Tu vois où se cache le risque.

Deux repères suffisent pour débuter. Un transfert simple et une action DeFi.

Le bon réflexe est de ralentir. La vitesse arrive après la compréhension.

Un exemple réel vaut mieux qu’un résumé. Va voir une transaction.

Les repères rendent les décisions plus calmes. Et plus sûres.

Comprendre d’abord, cliquer ensuite. Ça te sauve souvent.

Passe du bouton à la trace. C’est là que tu progresses.

Tu n’as pas besoin d’être précis. Tu as besoin d’une boussole.

Explique l’idée en deux phrases. Si c’est dur, reviens à un exemple concret.

Ouvre une transaction et lis les appels internes. Tu vois l’exécution réelle.

Les ordres de grandeur te protègent. Sans repères, tu paniques et tu surpayes.

Si tu ne peux pas l’expliquer, tu ne le signes pas. C’est une règle simple.

Lis les logs et les events. C’est le reçu de ton action.

Un coût ne doit pas te surprendre. Si ça surprend, tu vérifies.

La première implication est la transparence. Le code peut être vérifié sur un explorateur. Mais beaucoup de contrats ne publient pas leur source.

Donc tu dois distinguer: verified source, bytecode inconnu, proxy. Ce n’est pas du snobisme. C’est ton risque.

Deuxième implication: les patterns. Reentrancy, permissions trop larges, erreurs de visibilité, et mauvaises assumptions sur msg.sender.

Un exemple concret: une fonction “setOwner” mal protégée. Ça ressemble à un outil d’admin. Ça devient un bouton de vol.

Troisième implication: la composabilité. Ton contrat peut être une brique. D’autres peuvent l’appeler, et le combiner avec leur logique.

Quatrième implication: le coût. Une boucle sur un tableau qui grandit peut devenir impossible. Tu crées un DoS économique sans le vouloir.

Cinquième implication: les mises à jour. Immutable est plus prévisible. Upgradeable est plus flexible. Mais il ajoute de la confiance dans l’admin.

Donc ton usage dépend de ta tolérance au risque. Il n’y a pas une réponse universelle.

considérations pratiques

Pour réduire le risque, lis sécuriser ton wallet et reconnaître le phishing.

Une source utile: OpenZeppelin — Contracts.

Une source utile: Etherscan — Verified contracts.

Si tu apprends, commence par lire du code simple. Un ERC-20 minimal. Un contrat de vault. Puis un AMM basique.

Ensuite, entraîne-toi à lire les permissions. Qui est owner. Quels rôles existent. Qui peut upgrader. Qui peut pauser.

Évite les appels externes avant d’avoir compris la reentrancy. Si tu dois faire un call, applique checks-effects-interactions.

Teste sur un testnet, puis sur mainnet avec un petit montant. Tu veux voir le comportement réel, pas une idée.

Si tu déploies, documente la version de compilation, l’optimiseur, et les paramètres. Un détail peut casser la vérification.

Enfin, ne confonds pas “copier” et “comprendre”. Beaucoup de hacks viennent d’un fork rapide sans lecture des invariants.

Disclaimer. Je ne te conseille pas d’acheter un token lié à un projet Solidity. Fais ton propre research (DYOR). Les risques sont réels, mentionnés ci-dessus. Test en petit d’abord avant scaling. Les gains ne sont jamais garantis. Et les choses bougent vite, cet article peut dater.

Dans Solidity : le langage qui peut te ruiner, la composabilité alimente la DeFi, un DEX et un AMM comme Uniswap. Mais elle crée des risques: reentrancy, vulnerability et exploit, malgré un security audit. Et côté utilisateur, le danger reste: phishing, fausse dapp, mauvaise interface, ou mauvais lien. Quand tu doutes, teste petit et vérifie.

Sur Ethereum, les smart contracts tournent dans l’EVM. Tu payes du gas en gwei, compté en wei. Un token ERC-20 utilise approve, allowance et transferFrom, puis touche le storage. Tu verras aussi bytecode, opcodes, ABI, bytecode verified, proxy et upgrade quand tu lis un contrat. Quand tu doutes, teste petit et vérifie.

Si tu connais Bitcoin, garde les piliers: blockchain, transaction, mempool et consensus. La sécurité vient du Proof of Work, du mining et des mineurs. Tu croises hash, SHA-256, Merkle et signature ECDSA. Et tu entends UTXO, halving, difficulté, timestamp, SegWit, Taproot, Lightning et fork quand tu creuses. Quand tu doutes, teste petit et vérifie.

Repère rapide: ta clé privée est la clé. Ta seed phrase est le double. Ton wallet est l’outil, pas la promesse. Un hot wallet est pratique. Un cold wallet est plus sûr. Et un exchange peut aider, mais te retire du contrôle. Quand tu doutes, teste petit et vérifie.

Conclusion avec action

Solidity est simple en surface, mais brutal en production. Le code devient une règle publique et parfois irréversible.

Ta prochaine étape: lis un ERC-20 minimal, puis repère transfer, approve, et les events.

Fais ton propre research (DYOR). Test en petit d’abord. Et privilégie la sécurité avant la vitesse.