Quelque chose à propos de la couche d’adaptation de DuskEVM me rend curieux cette semaine, et c’est beaucoup plus intéressant que le pitch habituel « on supporte Solidity » que la plupart des chaînes EVM mettent en avant.
Voici le problème concret. La chaîne native de Dusk parle GraphQL et quelque chose appelé RUES pour les événements et l’état. Les outils Ethereum ne savent rien de tout ça. Chaque explorer, wallet et indexeur s’attend à des blocs, des receipts, des logs et des preuves dans une forme très spécifique « à la manière d’Ethereum ». Donc il faut forcément quelque chose qui se place entre l’état natif de Dusk et cette forme attendue, et qui traduise correctement le tout à chaque fois. Un champ incohérent et toute la pile en aval se brise silencieusement, sans que personne ne s’en rende compte tout de suite.
Quelques discordances rendent cela plus concret. Dusk exprime la valeur en LUX à la couche de base, alors que les outils EVM s’attendent à des wei : chaque réponse RPC nécessite donc une conversion réelle, pas juste un changement d’étiquette. Les dépôts qui passent du Dusk L1 vers DuskEVM utilisent un aliasage d’adresses de style OP, parce qu’il n’existe aucun moyen natif d’identifier quel contrat a réellement déclenché un bridge ou la récupération d’une valeur ; il faut donc du messaging inter-domaines pour retrouver qui l’a vraiment envoyé (tx.origin). Et comme le règlement finalise sur DuskDS au lieu d’Ethereum, les « dispute games » et les preuves de faute empruntées à l’OP Stack ont dû être retravaillées en fonction du consensus propre à Dusk, plutôt qu’à celui d’Ethereum.
C’est ça qui m’a fait tilt. Forker l’OP Stack n’est pas la partie difficile. Le séquenceur et la production des blocs restent reconnaissables comme op-geth. Mais le règlement des preuves et la sémantique de la valeur ont dû être reconstruits côté natif Dusk. Déterminer où se situe cette frontière, c’est le vrai travail d’ingénierie.
#dusk $DUSK @Dusk
$ETH
Voici le problème concret. La chaîne native de Dusk parle GraphQL et quelque chose appelé RUES pour les événements et l’état. Les outils Ethereum ne savent rien de tout ça. Chaque explorer, wallet et indexeur s’attend à des blocs, des receipts, des logs et des preuves dans une forme très spécifique « à la manière d’Ethereum ». Donc il faut forcément quelque chose qui se place entre l’état natif de Dusk et cette forme attendue, et qui traduise correctement le tout à chaque fois. Un champ incohérent et toute la pile en aval se brise silencieusement, sans que personne ne s’en rende compte tout de suite.
Quelques discordances rendent cela plus concret. Dusk exprime la valeur en LUX à la couche de base, alors que les outils EVM s’attendent à des wei : chaque réponse RPC nécessite donc une conversion réelle, pas juste un changement d’étiquette. Les dépôts qui passent du Dusk L1 vers DuskEVM utilisent un aliasage d’adresses de style OP, parce qu’il n’existe aucun moyen natif d’identifier quel contrat a réellement déclenché un bridge ou la récupération d’une valeur ; il faut donc du messaging inter-domaines pour retrouver qui l’a vraiment envoyé (tx.origin). Et comme le règlement finalise sur DuskDS au lieu d’Ethereum, les « dispute games » et les preuves de faute empruntées à l’OP Stack ont dû être retravaillées en fonction du consensus propre à Dusk, plutôt qu’à celui d’Ethereum.
C’est ça qui m’a fait tilt. Forker l’OP Stack n’est pas la partie difficile. Le séquenceur et la production des blocs restent reconnaissables comme op-geth. Mais le règlement des preuves et la sémantique de la valeur ont dû être reconstruits côté natif Dusk. Déterminer où se situe cette frontière, c’est le vrai travail d’ingénierie.
#dusk $DUSK @Dusk
$ETH
