DuskEVM tourne sur l’OP Stack, ce qui m’a pris par surprise pendant que je fouillais les docs $DUSK , pensant que #Dusk @Dusk avait construit sa couche EVM depuis zéro vu l’importance que la fondation @DuskFoundation accorde à des outils de confidentialité sur mesure. #DuskEVM Au lieu de ça, ils ont choisi un framework de rollup existant et y ont greffé l’étape de règlement sur DuskDS, leur couche séparée d’availability des données. Ce qui me trotte encore en tête, c’est le pont : il est décrit comme natif et trustless, sans actifs tokenisés, sans dépositaire au milieu pendant que DUSK passe de DuskDS à DuskEVM. Les validateurs se contentent de lancer la nouvelle version et les soldes sont conservés automatiquement. C’est une affirmation plus forte que ce qu’elle paraît : dans ce secteur, la plupart des « ponts natifs » s’appuient encore, en pratique, sur un certain schéma de multisig ou sur un relai dès qu’on regarde de près. Je n’ai pas encore trouvé le code réel du contrat de pont pour vérifier comment les hypothèses de confiance sont appliquées on-chain ; je n’ai que la documentation décrivant le comportement. Est-ce que quelqu’un ici exécute réellement un nœud validateurs sur la mise à niveau de DuskEVM, et a effectivement observé ce que fait le pont de bout en bout sur un transfert ? Curieux de savoir si le « trustless » tient dans des conditions réelles, ou s’il y a une étape de quorum quelque part, enfouie dans le client.