Ethereum vs Solana : quelles sont les principales différences ?

Modèle d'exécution et ordre des transactions

1. Ethereum traite les transactions de manière séquentielle au sein de chaque bloc à l'aide de la machine virtuelle Ethereum (EVM), appliquant un ordre strict basé sur les offres de prix du gaz.

2. Ce modèle séquentiel crée des chemins d'exécution prévisibles, mais permet également d'importantes opportunités de valeur extractible par les mineurs (MEV) grâce à la réorganisation des transactions.

3. Solana utilise Sealevel, un environnement d'exécution parallèle qui identifie les modèles d'accès aux comptes non conflictuels entre les transactions pour les exécuter simultanément.

4. L'exécution parallèle permet à Solana d'atteindre un débit plus élevé mais oblige les développeurs à déclarer explicitement les dépendances de compte dans les métadonnées d'instruction.

5. Une seule transaction Solana peut contenir plusieurs instructions ciblant des comptes distincts, et le runtime valide l'atomicité uniquement au niveau de la transaction.

Architecture d'État et conception de contrats

1. Ethereum maintient l’état au niveau de l’adresse du contrat intelligent, où toutes les variables et emplacements de stockage appartiennent à un espace de noms de contrat isolé.

2. Chaque déploiement de contrat génère une nouvelle adresse avec son propre espace de stockage persistant, simplifiant ainsi la composabilité entre les contrats via des appels directs.

3. Solana utilise un modèle d'état basé sur un compte dans lequel les programmes sont apatrides et les données résident dans des comptes distincts et indépendants.

4. Les développeurs doivent pré-attribuer et initialiser les comptes de données avant utilisation, et chaque appel de programme doit répertorier explicitement tous les comptes requis.

5. Les invocations inter-programmes dans Solana se produisent via CPI (Cross-Program Invocation), qui applique des contrôles stricts de propriété et d'autorisation du compte.

Mécanismes économiques et structures tarifaires

1. Le marché des frais d'Ethereum fonctionne de manière dynamique : les utilisateurs enchérissent sur l'ETH pour la priorité d'inclusion, les frais de base s'ajustant par bloc et les pourboires étant attribués aux validateurs.

2. Solana met en œuvre un modèle de coût de calcul fixe dans lequel les frais dépendent du nombre d'instructions, des accès au compte et des unités de calcul consommées.

3. Les validateurs Solana facturent des frais de calcul de l'ordre de la microseconde ainsi que des frais de loyer pour le maintien du stockage du compte en chaîne.

4. La volatilité des frais de gaz d'Ethereum rend difficile la prévision précise des coûts en cas de congestion du réseau, alors que Solana offre des prix plus prévisibles sous une charge normale.

5. Les deux chaînes imposent des pénalités en cas d'échec des transactions, bien que Solana déduise des frais même lorsque les instructions sont annulées en raison de violations des contraintes de compte.

Caractéristiques du consensus et de la finalité

1. Ethereum utilise un consensus hybride de preuve de participation avec les règles de choix de fork LMD-GHOST/FFG, atteignant une finalité probabiliste après environ 12 à 15 minutes.

2. Solana combine la preuve d'historique (PoH) avec la preuve d'enjeu pour générer des horodatages vérifiables pour les événements avant la participation par consensus.

3. PoH permet aux nœuds Solana de se mettre d'accord sur l'ordre des événements sans diffuser d'horodatages, ce qui réduit considérablement les frais de communication.

4. Solana atteint une finalité déterministe en moins de 2 secondes dans des conditions de réseau saines, soutenues par Tower BFT et une rotation des dirigeants pondérée par les votes.

5. Les garanties de finalité d'Ethereum se renforcent au fil du temps à mesure que les attestations s'accumulent, tandis que la finalité de Solana est immédiate dès la confirmation de la grande majorité des validateurs pondérés en fonction des enjeux.

Modèles de mise en œuvre du protocole DeFi

1. Les protocoles Ethereum DeFi s'appuient fortement sur des flux Oracle externes pour la découverte des prix, étant donné le manque d'infrastructure native du carnet de commandes.

2. Solana héberge des carnets d'ordres limités (CLOB) entièrement en chaîne comme ceux utilisés par Raydium et Orca, permettant une correspondance en temps réel sans coordination hors chaîne.

3. Les prêts flash sur Ethereum s'exécutent de manière atomique dans un seul contexte de transaction, permettant une logique complexe d'arbitrage ou de liquidation sans garantie.

4. Les prêts flash Solana nécessitent une orchestration de l'IPC en plusieurs étapes entre les programmes de prêt et d'emprunteur, ce qui augmente la complexité et la surface d'échec.

5. La composabilité d'Ethereum permet aux positions Uniswap v3 d'être intégrées directement dans les stratégies de coffre-fort Yearn, tandis que Solana impose le partage de compte explicite et la délégation de signature.

Foire aux questions

Q : Solana prend-il en charge les mises à niveau des contrats intelligents sans redéploiement ? Oui. Les programmes Solana peuvent être mis à niveau sur place par les signataires autorisés, préservant ainsi les données de compte et les adresses de programme entre les versions.

Q : Les contrats Ethereum peuvent-ils lire le stockage arbitraire à partir d’autres contrats ? Non. Ethereum applique une isolation stricte du stockage ; les contrats ne peuvent accéder à l’état externe que via des interfaces publiques définies ou des fonctions de secours.

Q : Comment Solana empêche-t-il le front-running dans les implémentations CLOB ? L'ordre déterministe des transactions de Solana dans un créneau et les fenêtres de planification serrées des leaders réduisent les écarts de synchronisation exploitables, bien que les relais boostés par MEV de Jito ajoutent des couches de protection supplémentaires.

Q : Les opcodes Ethereum EVM sont-ils compatibles avec le runtime de Solana ? Non. Solana exécute des programmes compilés avec le bytecode Berkeley Packet Filter (BPF), nécessitant une réécriture ou une transpilation complète de la logique EVM.