Solana vs Ethereum : pourquoi leurs vitesses de transaction diffèrent-elles ?

Architecture du mécanisme de consensus

1. Solana utilise la preuve d'historique (PoH), une fonction de retard vérifiable qui horodatage cryptographiquement les transactions avant qu'elles n'entrent dans la couche de consensus. Ce pré-séquençage élimine le besoin pour les validateurs de négocier les commandes pendant la production des blocs.

2. Ethereum s'appuie sur la preuve de participation (PoS) avec séparation proposant-constructeur, où les constructeurs de blocs rivalisent pour construire des blocs optimaux et les proposants sélectionnent parmi eux. L'ordre des transactions est déterminé dynamiquement lors de l'exécution du créneau.

3. PoH permet aux validateurs Solana de traiter des milliers de transactions en parallèle sans surcharge de coordination entre validateurs, contribuant directement à une finalité inférieure à la seconde.

4. La conception consensuelle d'Ethereum donne la priorité à la résistance à la censure et à la décentralisation plutôt qu'au débit brut, nécessitant une vérification séquentielle des effets des transactions au sein de chaque bloc.

5. L'absence de verrouillage d'état global dans l'architecture de Solana permet une exécution simultanée sur des ensembles de comptes qui ne se chevauchent pas, tandis que l'EVM d'Ethereum impose une exécution en série stricte par bloc.

Conception du moteur d'exécution

1. Le runtime Sealevel de Solana exécute les transactions en parallèle en analysant les dépendances des comptes de lecture/écriture au niveau des instructions avant la planification.

2. L'EVM d'Ethereum traite les transactions une par une dans une séquence ordonnée, ce qui rend l'exécution intrinsèquement linéaire quelles que soient les capacités matérielles sous-jacentes.

3. Sealevel exige que les développeurs déclarent explicitement les modèles d'accès aux comptes, permettant une détection déterministe des conflits avant le début de l'exécution.

4. EVM n'exige pas de telles déclarations ; les conflits n'apparaissent que pendant l'exécution, forçant la réexécution ou le rejet lorsque des incohérences d'état surviennent.

5. L'exécution parallèle dans Solana réduit la latence moyenne par transaction mais augmente la complexité du développement de contrats intelligents en raison de la gestion explicite de la concurrence.

Contraintes de débit au niveau du réseau

1. Solana vise 65 000 TPS dans des conditions idéales, prises en charge par une vérification de signature accélérée par le matériel à l'aide de GPU et de bibliothèques cryptographiques personnalisées.

2. La capacité actuelle d'Ethereum après Deneb reste plafonnée à près de 100 TPS pour L1, la plupart des activités à volume élevé étant transférées vers des cumuls fonctionnant indépendamment des goulots d'étranglement de la couche de base.

3. L'ensemble de validateurs de Solana fonctionne avec des exigences matérielles strictes (les nœuds doivent prendre en charge une bande passante de 10 Gbit/s et un stockage NVMe) pour maintenir la synchronisation tout au long de sa rotation de leaders haute fréquence.

4. Les validateurs Ethereum fonctionnent sur du matériel de base avec des demandes d'E/S assouplies, échangeant une vitesse brute contre une participation et une tolérance aux pannes plus larges.

5. Le délai de propagation du réseau dans Solana est minimisé grâce à Turbine, un protocole de distribution de blocs qui divise les blocs en paquets plus petits et les diffuse simultanément dans toutes les régions géographiques.

Dynamique des échecs de transaction

1. Solana présente un taux d'échec de transaction d'environ 20 % , en grande partie dû à l'épuisement des ressources, aux violations de timing et aux conflits de verrouillage de compte pendant les pics de charge.

2. Le taux de défaillance d'Ethereum se situe à près de 0,1 % , ce qui reflète des pratiques conservatrices d'estimation du gaz et des garanties d'exécution intégrées héritées de la conception EVM.

3. Les transactions échouées sur Solana consomment le budget de calcul et la bande passante du réseau même lorsqu'elles sont annulées, imposant un coût mesurable aux utilisateurs et aux validateurs.

4. Le mécanisme de gaz d'Ethereum garantit que les transactions échouées ne consomment que le gaz payé pour leur tentative d'exécution, limitant ainsi les dommages collatéraux aux incitations économiques.

5. Les taux d'échec élevés sur Solana sont fortement corrélés aux périodes de congestion du pool de mémoire et aux transitions rapides des leaders, exposant la sensibilité architecturale aux variations du réseau en temps réel.

Comportement de transfert de valeur nulle

1. Environ 7,6 % de toutes les transactions Solana ont une valeur nulle, souvent utilisées pour l'initialisation du compte, les mises à niveau du programme ou l'échafaudage d'invocation CPI.

2. Ethereum n’enregistre que 0,66 % de transferts de valeur nulle, car son modèle de transaction associe étroitement le transfert de valeur à l’intention d’exécution.

3. Le modèle de compte de Solana traite chaque instruction comme une entité de transaction de première classe, permettant des regroupements atomiques multi-instructions sans mouvement de valeur native.

4. Le modèle centré sur les transactions d'Ethereum nécessite un transfert explicite d'ETH ou une approbation ERC-20, même pour de simples mutations d'état, décourageant les modèles d'utilisation à valeur nulle.

5. La prévalence du trafic de valeur nulle sur Solana reflète des différences structurelles plus profondes dans la manière dont les applications s'interfacent avec l'état de la chaîne par rapport à la manière dont les utilisateurs lancent des actions.

Foire aux questions

Q : Le TPS élevé de Solana se fait-il au détriment de la décentralisation ? R : Oui. Les exigences du validateur de Solana, notamment la connectivité à large bande passante, le stockage NVMe à faible latence et l'accélération GPU, excluent les participants à faibles ressources, ce qui se traduit par un ensemble de validateurs nettement plus petit que celui d'Ethereum.

Q : Pourquoi Ethereum ne peut-il pas simplement adopter le PoH pour augmenter la vitesse ? R : PoH suppose des horloges synchronisées et des retards de réseau déterministes, ce qui contredit le principe de conception d'Ethereum consistant à fonctionner de manière fiable dans des conditions de réseau contradictoires et hétérogènes.

Q : Les avantages de l'exécution parallèle de Solana sont-ils accessibles à tous les développeurs ? R : Non. Les développeurs doivent annoter manuellement les modèles d'accès aux comptes et la logique de structure pour éviter les conflits d'exécution, ce qui augmente la barrière à l'entrée par rapport à la compatibilité EVM plug-and-play d'Ethereum.

Q : Comment Ethereum maintient-il la sécurité tout en déléguant l’échelle aux L2 ? R : Ethereum sécurise la disponibilité des données L2 grâce à la publication des données d'appel et à des preuves de fraude/validité, garantissant que les transitions d'état L2 restent ancrées et vérifiables par la couche de règlement L1.