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 →
TOKEN2049 Singapore s'est tenu du 7 au 8 octobre. Juan José, CEO de Bitroot, est monté sur la scène principale pour présenter la blockchain d'IA parallélisée et l'économie des machines ; sur le stand et lors d'une rencontre communautaire, l'équipe a échangé avec des institutions, des plateformes d'échange, des projets, des développeurs et des KOL, et a présenté les orientations de sa prochaine phase autour de Pipeline BFT, de l'EVM parallélisée, de l'IA décentralisée et de l'IA physique.
Du 29 au 30 septembre, la GWDC 2026 KOREA s'est tenue à l'aT Center de Séoul. Juan José, CEO de Bitroot, est monté sur la scène principale pour une intervention intitulée « The Parallel AI Blockchain for the Machine Economy », tandis que l'équipe échangeait avec des développeurs, des projets et des institutions du monde entier sur le stand C08, afin de poursuivre l'élargissement de ses coopérations en Corée et à l'international autour de l'EVM parallélisée et de l'infrastructure d'IA.
Le client d'exécution traite l'EVM comme un exécuteur remplaçable, séparé par une couche d'accès à l'état. L'interpréteur intégré de go-ethereum, evmone et revm occupent des positionnements différents ; la cohérence entre implémentations repose sur les vecteurs de test issus de la spécification, et l'espace d'optimisation de l'interpréteur se concentre sur la distribution, la facturation du gaz et la gestion de la mémoire.
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.
