Des articles techniques sur les modèles d'exécution, le consensus, les bases de l'EVM et l'IA vérifiable. Chaque analyse rend le Web3 plus clair.
Choix de la rédactionTrois voies matures dépassent l'exécution monothread — la pré-déclaration déterministe de style Sealevel, le contrôle de concurrence optimiste de style Block-STM et les modèles à objets de style Sui. Cet article compare leurs hypothèses, leurs coûts pour les développeurs et leur adéquation avec la compatibilité EVM.
Lire l'article →
Les variables d'état se rangent, dans l'ordre de déclaration, dans des slots de 32 octets : les petits types partagent un slot, les mappings et les tableaux dynamiques dérivent leur position par hachage, et l'ordre d'héritage décale l'ensemble des numéros de slot. Ces règles de placement expliquent pourquoi un proxy de mise à niveau doit contourner les slots que le compilateur allouerait.
Les quatre instructions d'appel ne diffèrent dans le bytecode que par quelques numéros, mais leur sémantique décide dans quel contexte le code s'exécute, quel stockage il écrit et ce que deviennent msg.sender et address(this). En comparant une à une CALL, CALLCODE, DELEGATECALL et STATICCALL, on voit pourquoi les contrats proxy dépendent de DELEGATECALL et pourquoi STATICCALL a été introduit.
En partant du calldata brut, cet article décompose l'ABI : le sélecteur de 4 octets provient de la troncature de la signature canonique, les types statiques occupent directement un mot entier, les types dynamiques reposent sur un adressage à deux niveaux, par décalage et par longueur ; les événements écrivent les paramètres indexed dans les topics, en échange d'une capacité de recherche. L'ABI n'est pas auto-descriptive, ce qui contraint aussi bien le décodage que les mises à niveau.
Le livre jaune d'Ethereum écrit la transition d'état au niveau du bloc sous forme d'appels imbriqués : l'ordre d'évaluation fait donc partie de la spécification. D'où vient la sémantique de la sérialisation transaction par transaction, pourquoi un conflit de read/write set ne peut pas être déterminé à l'avance, ce que le déterminisme et la simplicité de vérification ont permis d'acheter, et à quoi ce point d'origine de conception se heurte aujourd'hui : voilà le fil conducteur de la suite.
Le stateRoot d'un en-tête de bloc ne fait que 32 octets, et pourtant il engage l'ensemble des comptes, des soldes et du stockage des contrats du réseau. Nous démontons ici la structure des nœuds du Merkle Patricia Trie et la conception du trie de stockage rattaché aux comptes, expliquons comment les preuves de Merkle permettent la vérification hors chaîne, et identifions qui supporte le coût du gonflement de l'état.
Le gaz est l'unité de mesure des ressources de l'EVM, tandis que son prix est fixé par le marché des frais ; confondre les deux conduit à mal juger les frontières de la scalabilité et de l'interruption d'exécution. L'article décompose le coût intrinsèque et le coût dynamique, précise ce que remboursent respectivement un out-of-gas et un REVERT, et indique à qui reviennent le base fee et le tip de l'EIP-1559.
Les mêmes 32 octets placés en memory, en storage ou en transient storage peuvent coûter deux ordres de grandeur de gaz, et leur durée de vie n'a rien de commun. L'article distingue les trois types de stockage selon trois axes — appartenance, durée de vie et tarification — et précise où placer respectivement un verrou de réentrance, un tableau temporaire et une variable d'état.
L'EVM est une machine à pile sans registres : mots de 256 bits, profondeur de pile de 1 024 éléments et compteur de programme qui ne peut sauter qu'à un JUMPDEST. Le cycle extraction, décodage, exécution explique pourquoi le sous-débordement et le débordement de pile brûlent tout le gaz, et ce que la machine à pile gagne et ce qu'elle coûte face à une machine à registres.
Prendre Ethereum pour un registre consignant des virements laisse échapper son élément le plus essentiel : les variables librement lisibles et inscriptibles du stockage des comptes. D'après la fonction de transition d'état Υ(σ, T) du Yellow Paper, Ethereum est une machine à états distribuée, et l'EVM est la spécification d'exécution de cette transition d'état. Le rejeu bit à bit par l'ensemble du réseau impose en outre un ensemble de contraintes dures à la sémantique d'exécution.
L'EVM parallèle échoue rarement sur les benchmarks de virements, mais s'effondre souvent sur le trafic d'AMM, de prêt et de mint de NFT. Cet article explique comment se forment les points chauds de conflit, comment la granularité des ensembles lecture/écriture détermine les taux de conflit, et comment le TPS de pointe se dégrade sous des charges réelles.
Un TPS plus élevé s'achète-t-il avec un matériel plus coûteux et moins de validateurs ? Cet article décortique des dimensions vérifiables — exigences des validateurs, géographie et diversité des clients — et examine des réponses d'ingénierie telles que l'agrégation BLS, sans hype. Ceci ne constitue pas un conseil en investissement.
TPS, BPS, latence de confirmation, finalité et taux de conflit sont régulièrement confondus. Cet article fournit des définitions réutilisables, les schémas de mauvais usage courants et la liste des informations à exiger pour tout benchmark — et non un conseil en investissement.
Les développeurs de contrats, les ingénieurs clients et les chercheurs s'intéressent à l'EVM parallèle pour des raisons différentes. Cet article propose trois parcours de lecture qui ne renvoient qu'à des articles déjà publiés sur ce site, afin que chaque public trouve quoi lire — et quoi sauter.
« Compatible EVM » est souvent réduit à un argument marketing. Ce qui détermine réellement le coût de migration, ce sont la sémantique du bytecode, l'ensemble des précompilations, le comportement de JSON-RPC et la question de savoir si Foundry/Hardhat fonctionnent encore sans modification. Cet article sépare ces quatre couches et explique pourquoi le parallélisme rend la compatibilité plus difficile à maintenir.
Choisir un Layer 1 à EVM parallèle optimiste implique des compromis simultanés sur le domaine de règlement, la compatibilité et la stratégie de parallélisme. Cet article énonce ce que Bitroot résout et ne résout pas — des frontières, pas des slogans — et comment ses briques techniques se soutiennent mutuellement.
Le contrôle de concurrence optimiste est né de la recherche sur les bases de données en 1981 et sous-tend aujourd'hui de nombreux EVM parallèles. Cette introduction explique les phases lecture–validation–écriture, oppose l'OCC au verrouillage pessimiste et au MVCC, et nomme les contraintes supplémentaires de déterminisme et de tolérance byzantine qu'ajoutent les chaînes de blocs.
Trois voies matures dépassent l'exécution monothread — la pré-déclaration déterministe de style Sealevel, le contrôle de concurrence optimiste de style Block-STM et les modèles à objets de style Sui. Cet article compare leurs hypothèses, leurs coûts pour les développeurs et leur adéquation avec la compatibilité EVM.
La « scalabilité » est souvent traitée comme un seul problème. Cet article la découpe en consensus, disponibilité des données, exécution et règlement — et place sur cette carte les L2, le sharding, la DA autonome et l'exécution parallèle L1, en indiquant où se situe l'EVM parallèle.
Les grands épisodes de congestion d'Ethereum partagent une même racine de conception — l'EVM exécute les transactions une par une. Cet article explique pourquoi relever la limite de gaz et l'EIP-1559 ne peuvent pas réécrire ce modèle d'exécution, et comment le délai de confirmation amplifie le plafond monothread.
Pourquoi les contributeurs en données, modèles et puissance de calcul perçoivent rarement des paiements automatiques dans l'IA — et ce que les index de métadonnées on-chain, le partage à seuil, l'audit assisté par TEE et la répartition par contrat intelligent résolvent ou ne résolvent pas — ainsi que la manière dont les droits s'appuient sur le règlement et l'informatique de confiance.
