🧠 Smart Contracts : Solidity & Rust

Cycle de Vie d'un Smart Contract (sur EVM)

1. 1. Écriture (Writing) : Le développeur écrit le code dans un langage de haut niveau (ex: **Solidity**).
2. 2. Compilation (Compiling) : Le code Solidity (`.sol`) est compilé en deux artefacts cruciaux :
   • Bytecode : Le code machine (bas niveau) qui sera réellement exécuté par l'EVM (Ethereum Virtual Machine). C'est une longue suite d'instructions hexadécimales.
   • ABI (Application Binary Interface) : Un fichier JSON qui sert de "mode d'emploi" pour le contrat. Il décrit les fonctions (noms, arguments, types de retour) pour que les applications (frontends, autres contrats) sachent comment "parler" au bytecode.
3. 3. Déploiement (Deploying) :
   • Le développeur (depuis un EOA) envoie une **transaction spéciale** à la blockchain.
   • Cette transaction n'a pas de destinataire (adresse `to:` est `null` ou `0x0`).
   • Le champ "data" de la transaction contient l'intégralité du **Bytecode** compilé.
   • Le réseau facture des frais de Gas énormes pour cela, car le déploiement implique d'écrire du code dans l'état de la blockchain (l'opération `SSTORE` la plus chère).
   • Le réseau exécute le code, crée le contrat et lui assigne une nouvelle adresse permanente (ex: `0x1f98...`).
4. 4. Exécution (Executing) :
   • Des utilisateurs (EOA) ou d'autres contrats (CA) peuvent maintenant "appeler" le contrat en envoyant des transactions à son adresse (`0x1f98...`).
   • La transaction inclut des "data" spécifiant quelle fonction appeler et avec quels arguments (conformément à l'ABI).
   • L'EVM exécute le code correspondant et met à jour l'état du contrat (ex: `balances[msg.sender] -= 100`).
5. 5. Mise à Jour (Upgrading) - Le Piège :
   • Par défaut, c'est **impossible** (Immuabilité).
   • Contournement (Proxy Pattern) : Les développeurs avancés utilisent un "Proxy". L'utilisateur interagit avec un contrat A (le "Proxy"), qui ne contient aucune logique. Ce Proxy *délègue* tous les appels à un contrat B (la "Logique"). Pour mettre à jour, les développeurs déploient un contrat C (nouvelle logique) et disent au Proxy A de pointer vers C au lieu de B. C'est complexe et introduit des risques de centralisation.

Variables Globales : Le Contexte d'Exécution

Solidity fournit des variables "magiques" (globales) qui donnent au contrat le contexte de la transaction qui l'appelle. C'est le pilier de la sécurité et de la logique business.

Exemple : ERC-20 Simplifié (MyToken)

Voici comment les mappings, msg.sender et les événements s'articulent pour créer un token.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

contract MySimpleToken {

    // Variable d'état : associe chaque adresse à son solde
    mapping(address => uint256) public balances;
    
    // Variable d'état : l'adresse qui a déployé le contrat
    address public owner;
    
    // Événement : pour informer le frontend d'un transfert
    event Transfer(address indexed from, address indexed to, uint256 amount);

    // Constructeur : exécuté UNE SEULE FOIS lors du déploiement
    constructor(uint256 initialSupply) {
        // Celui qui déploie...
        owner = msg.sender;
        // ...reçoit l'offre initiale.
        balances[msg.sender] = initialSupply;
    }

    // Fonction de transfert
    function transfer(address to, uint256 amount) public {
        // 1. Vérifier si l'appelant (msg.sender) a assez de fonds
        require(balances[msg.sender] >= amount, "Solde insuffisant");

        // 2. Mettre à jour les soldes (Protection contre réentrance depuis 0.8.0)
        balances[msg.sender] -= amount;
        balances[to] += amount;

        // 3. Émettre l'événement
        emit Transfer(msg.sender, to, amount);
    }

    // Fonction "view" (lecture seule, gratuite off-chain)
    function getBalance(address account) public view returns (uint256) {
        return balances[account];
    }
}

Différences Architecturales (Rust vs Solidity)

1. Performance & Parallélisme (Solana)

L'EVM (Solidity) est **mono-thread**. Il exécute les transactions les unes après les autres (séquentiellement). C'est le goulot d'étranglement de la scalabilité d'Ethereum.

Solana (Rust) est conçu pour le **parallélisme**. Le modèle de Rust (le Borrow Checker) permet de définir *explicitement* quelles parties de l'état (quels "comptes") une transaction va lire ou écrire. Le runtime de Solana peut alors voir que la Transaction A (touchant aux comptes X,Y) et la Transaction B (touchant aux comptes P,Q) sont indépendantes et les exécuter en parallèle sur différents cœurs de processeur. C'est impossible en Solidity où tout peut potentiellement affecter tout.

2. Gestion de l'État

Solidity : L'état (storage) est implicitement lié au contrat. `uint256 myVar;` vit *dans* le contrat.

Rust (Solana/Near) : L'état est souvent explicite et séparé. Sur Solana, un "programme" (smart contract) est lui-même **sans état (stateless)**. L'état (ex: le solde d'un token) est stocké dans des "comptes" séparés que le programme doit explicitement demander comme arguments d'entrée/sortie.

3. Syntaxe (Exemple : Solana)

L'écriture d'un contrat Rust (ici avec le framework "Anchor" de Solana) est très différente. Elle sépare la logique, la définition des comptes et la validation.

use anchor_lang::prelude::*;

declare_id!("Fg6PaF...your_program_id");

#[program]
pub mod my_first_program {
    use super::*;
    
    // Notre logique de contrat
    pub fn initialize(ctx: Context) -> Result<()> {
        let my_account = &mut ctx.accounts.my_account;
        my_account.data = 0;
        Ok(())
    }

    pub fn update(ctx: Context, data: u64) -> Result<()> {
        let my_account = &mut ctx.accounts.my_account;
        my_account.data = data;
        Ok(())
    }
}

// 1. Définition de l'état (le "compte" de données)
#[account]
pub struct MyAccount {
    pub data: u64,
}

// 2. Définition du contexte (Quels comptes la fonction "initialize" utilise-t-elle ?)
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user, space = 8 + 8)] // Initialise un compte
    pub my_account: Account<'info, MyAccount>,
    #[account(mut)]
    pub user: Signer<'info>, // L'utilisateur (msg.sender)
    pub system_program: Program<'info, System>,
}

// 3. Contexte pour "update"
#[derive(Accounts)]
pub struct Update<'info> {
    #[account(mut)] // Il doit être mutable
    pub my_account: Account<'info, MyAccount>,
}