AlizehAli

@Dusk J’ai parcouru la récente annonce de Dusk concernant sa demande d’ECSP, et les chiffres de marché derrière cette démarche valent vraiment qu’on s’y attarde.

Un ECSP — European Crowdfunding Service Provider (fournisseur européen de services de financement participatif) — est autorisé à mettre en relation des entreprises qui lèvent des fonds avec des investisseurs, en couvrant des offres éligibles comme des prêts et des valeurs mobilières transférables telles que des actions et des obligations. Les propres documents de Dusk citent l’estimation de Statista : les plateformes de crowdfunding ont facilité près de 70 milliards de dollars dans le monde en 2025.

Le contexte régional rend cela encore plus pertinent. L’Europe compte environ 34 millions de PME et la mise à jour de Dusk indique qu’au T2 2026, un pourcentage élevé de ces entreprises a déclaré que les taux de prêts bancaires augmentaient avec un écart de 43 points de pourcentage — un chiffre précis, daté, qui rend les voies de financement alternatives plus pertinentes, selon la présentation de Dusk. $DUSK

Dusk indique qu’elle demande spécifiquement le permis ECSP afin de mettre en relation des entreprises et des investisseurs européens, de distribuer les offres éligibles et d’intégrer les actifs qui en résultent dans l’écosystème Dusk plus large. Trois résultats annoncés : une autre voie de financement pour les entreprises, un accès à des offres réglementées pour les investisseurs, et de nouveaux actifs, utilisateurs, activités et revenus produits pour Dusk elle-même.

Faites le calcul de ce que cela permet de conclure. Ce n’est pas Dusk qui construit une infrastructure DeFi générique en espérant que la finance réglementée l’adopte. C’est Dusk qui poursuit le permis réglementaire réel qui lui permet d’émettre directement les offres réglementées, plutôt que d’attendre que quelqu’un d’autre les mette ensuite on-chain. #dusk

Ce que je n’ai pas encore vu : un calendrier de dépôt de demande effectif ou une date cible d’approbation.

#dusk $DUSK @Dusk

@TermMax ‎J’ai supposé que faire l’exercice d’une option rentable sur TermMax Alpha fonctionnerait toujours de la même manière — le paiement arrive dans votre portefeuille, c’est terminé, comme sur n’importe quelle autre plateforme d’options que j’avais déjà utilisée. $BEAT
‎
‎Cette supposition s’est effondrée quand j’ai lu que TermMax propose en réalité deux parcours d’exercice distincts. Exercise-Net-Settle clôture la position et verse directement le profit net. Exercise-Delivery, lui, règle en transférant l’actif sous-jacent lui-même, et non de l’argent — vous vous retrouvez à détenir réellement le token sur lequel reposait votre position Long ou Short. #TermMax
‎
‎Cela redéfinit ce que signifie ici « gagner » un trade d’options. Sur la plupart des plateformes, exercer revient juste à réaliser un certain montant. Sur TermMax, exercer peut aussi signifier repartir avec l’actif réel, ce qui compte tout particulièrement pour des listings précoces de Binance Alpha où obtenir une exposition réelle au token — pas uniquement à son évolution de prix — pourrait être l’objectif même du trade. $TUT
‎
‎Ce que la documentation ne précise pas, c’est si le choix entre les deux est toujours disponible pour le trader, ou si cela dépend de la configuration du marché au moment du règlement. $ENA
‎
‎Le vrai test pour TMX est de savoir si les traders comprennent réellement que ce choix existe avant d’exercer, ou s’ils se contentent de l’option que l’interface affiche en premier par défaut.
‎
‎Quelqu’un a-t-il déjà utilisé Exercise-Delivery plutôt que Net-Settle, et pourquoi ?
‎

#termmax @TermMax

@Dusk ‎La constitution fondatrice d’un pays existe au moment même où le pays existe — personne ne la fait voter après coup ; elle est simplement là dès le premier jour, et tout le reste se construit en s’y référant.
‎
‎Les contrats de genèse de Dusk fonctionnent de la même manière. L’architecture propre de Dusk décrit deux éléments : le contrat de stake, qui suit quels provisioners mettent des fonds en staking, enregistre les récompenses, et permet les actions de stake, d’unstake et de retrait des récompenses ; et le contrat de transfert, qui gère à la fois les transferts Moonlight (public) et Phoenix (shielded), paie le gas et sert de point d’entrée à l’exécution des transactions directement sur DuskDS.
‎
‎Ce rôle fondationnel s’étend au-delà de DuskDS à lui seul, bien que le mécanisme exact diffère selon la couche. DuskEVM, d’après les propres docs de Dusk, déplace les DUSK pour le gas via son propre pont vers le Dusk L1, avant de régler finalement à nouveau sur DuskDS — un chemin connexe mais distinct du rôle direct du contrat de transfert dans les transactions natives sur DuskDS. Les deux routes ramènent à la même couche de base ; elles ne sont pas des mécanismes identiques. #dusk
‎
‎Auto-critique : l’analogie avec la constitution a une limite réelle qu’il faut nommer. La constitution d’un pays peut être modifiée formellement via un processus défini. Ce que je n’ai pas trouvé documenté, c’est si les contrats de genèse de Dusk suivent un chemin de modification équivalent, clairement spécifié, ou si par « genèse » ici il faut comprendre, fonctionnellement, « permanent par conception » — une vraie question de gouvernance, compte tenu d’à quel point une grande partie de la pile multilayer en expansion de Dusk dépend désormais du fait que ces deux contrats restent corrects. $DUSK
‎
‎DUSK doit être évalué sur le point de savoir si cette ambiguïté est clarifiée avant que ces contrats n’aient jamais besoin d’être mis à jour sous une pression réelle, et non après.
‎
‎
#dusk $DUSK @Dusk

@Dusk ‎Je suis retourné à l’annonce de l’architecture propre à Dusk publiée en juin 2025, et le cadrage a changé depuis le positionnement antérieur de Dusk.
‎
‎Trois couches, selon la documentation actuelle de Dusk : DuskDS à la base, consensus, règlement, disponibilité des données, modèles de transactions natifs. DuskEVM au-dessus, basé sur OP Stack, compatibilité totale avec Solidity. DuskVM aux côtés, des contrats Rust/WASM s’exécutant directement sur L1 pour des cas d’usage à confidentialité native. #dusk
‎
‎Ce qui a changé par rapport à l’annonce d’évolution de 2025 d’origine : à ce moment-là, DuskVM était décrit comme « à venir ». Les documents actuels le décrivent comme une infrastructure en activité, et non comme un élément de feuille de route. Par ailleurs, les mises à jour de Dusk en 2026 décrivent la dApp réglementée de NPEX (NPEX) comme déployée activement sur DuskEVM spécifiquement — je veux être précis : il est question d’un déploiement en cours, et je ne peux pas confirmer qu’il s’agit d’un lancement terminé et pleinement opérationnel pour l’instant. $DUSK
‎
‎Un détail relie concrètement les trois couches, indépendamment de l’état de ce déploiement : un seul token DUSK alimente chaque couche, et un pont natif géré par des validateurs transfère la valeur entre elles, sans actifs enveloppés ni intermédiaires (custodians).
‎
‎C’est toujours un système en évolution, pas un système achevé. La documentation de DuskEVM confirme qu’il fonctionne actuellement en mode sequencer uniquement, sans mempool public pour le moment — une limitation datée et spécifique, située en dessous de tout ce qui est déployé activement au-dessus de cette couche, aujourd’hui.
‎
‎Si quelqu’un a suivi la progression réelle du déploiement de NPEX par rapport à cette architecture dans la pratique, je voudrais comparer nos constats avec ce que j’ai trouvé ici.
‎

#dusk $DUSK @Dusk

@TermMax ‎J’ai passé un certain temps à cartographier les mécanismes des options de TermMax Alpha, en m’attendant au profil de risque habituel des options à choix ouverts.
‎
‎Mais ce n’est pas ce que j’ai trouvé. « Going Long » signifie acheter un call, « Short » signifie acheter un put — tous deux face à une contrepartie que les documents appellent « Dual Investment » — le vendeur de l’option. « Max Cost » est défini de manière précise comme la prime payée, libellée principalement en USDT. Le règlement s’effectue via « Exercise-Net-Settle » ou « Exercise-Delivery », et, dans tous les cas, la perte maximale possible a été verrouillée dès l’ouverture de la position.
‎
‎Aucun de ces termes ne semblait particulièrement important pris isolément. Mais le contexte de lancement m’a fait hésiter. TermMax Alpha a été lancé sur le mainnet de la BNB Chain le 12 novembre 2025, construit par Term Structure Labs, soutenu par Cumberland DRW — une véritable société de trading institutionnelle, pas juste un gadget de “listing de jeton”.
‎
‎Ce soutien compte parce qu’il s’agit de ce que le produit résout réellement. Lorsque Binance Alpha liste un nouveau token, les traders attendent souvent des semaines avant que des contrats perpétuels n’apparaissent quelque part. TermMax Alpha existe précisément pour combler ce manque — une exposition à effet de levier avec un coût plafonné et connu, disponible dès le jour 1 du listing plutôt que des semaines plus tard. #TermMax
‎
‎Ce qui a retenu mon attention, c’est que cela fait de TermMax Alpha une infrastructure réellement sensible au temps — sa pertinence dépend de la rapidité avec laquelle continuent d’arriver de nouveaux listings Binance Alpha, plutôt que d’une fonctionnalité statique qui reste immobile.
‎
‎Je n’ai pas confirmé combien de marchés Alpha sont actuellement actifs, ni à quel point les spreads sont serrés sur les listings les plus récents.
‎

‎
‎ Long ou Short ?
‎
‎

#termmax @TermMax

Fonction de hachage compatible avec le snark conçue par la propre équipe de Dusk, spécifiquement pour le hachage résistant aux collisions à l’intérieur de circuits de connaissance à divulgation nulle.

5 % vont au liquidateur en tant que récompense pour avoir exécuté la liquidation

@Dusk ‎Je me suis demandé ce qui se passe réellement lorsqu’une preuve à connaissance zéro Phoenix échoue à la vérification, car la plupart des explications s’arrêtent à « la preuve est vérifiée ».
‎
‎L’architecture de Dusk confirme que la preuve doit démontrer des propriétés spécifiques à la fois — la propriété de la note dépensée, l’intégrité du solde entre les entrées et les sorties, et l’absence de double dépense — le tout encodé dans la même preuve, sans être vérifié via des contrôles séparés. $DUSK
‎
‎C’est le point qui vaut vraiment d’y réfléchir. Si l’une quelconque de ces propriétés n’est pas respectée, l’ensemble de la preuve échoue en tant qu’unité. Il n’existe aucun chemin permettant d’obtenir une partial credit où les vérifications de solde passent mais où la propriété échoue silencieusement.
‎
‎J’ai tracé ce que cela implique concrètement : une preuve rejetée signifie que la transaction n’est simplement jamais incluse. L’exécution ne tente pas de la “sauver” ni de la traiter partiellement. La transaction n’a tout simplement pas lieu, et rien de la tentative échouée n’est enregistré comme changement d’état. #dusk
‎
‎Ce que je n’ai pas confirmé à partir des documents propres à Dusk, c’est si une preuve échouée laisse une trace dans des journaux de mempool qu’un opérateur de nœud pourrait inspecter a posteriori, ou si elle est simplement écartée sans aucun enregistrement de diagnostic.
‎
‎Prochaine chose que je vérifierais : si les outils actuels du wallet de Dusk affichent une raison précise pour une preuve échouée, ou s’il s’agit juste d’un rejet générique, car cette distinction compte énormément pour quiconque débogue réellement une transaction qui n’est pas passée.

#dusk $DUSK @Dusk

@TermMax ‎J’ai passé un peu de temps à cartographier le système à trois jetons de TermMax, et une phrase dans la documentation a tout remis en perspective pour moi : la valeur de la garantie (Collateral Value) est égale à la valeur GT (GT Value) plus la valeur du prêt lui-même, où la valeur GT est définie comme la garantie moins la valeur de la dette. Les jetons ne sont pas simplement trois objets séparés : ce sont des morceaux d’une seule équation qui doit rester en équilibre.
‎
‎FT est un ERC-20, qui fonctionne comme une obligation à coupon zéro — 110 FT-USDC sont remboursés pour 110 USDC à l’échéance ; ainsi, l’acheter pour 100 USDC verrouille un rendement de 10 % sur une durée d’un an. Mais la documentation précise que ce taux évolue avec la maturité, et ne reste pas constant : un FT de 180 jours, avec le même escompte, annualise à environ 20 %, pas 10 %. XT est aussi défini plus précisément que ce que j’attendais : ce n’est pas seulement « l’autre moitié », c’est spécifiquement la valeur actuelle de l’intérêt que l’emprunteur doit, séparée du principal. GT est l’enveloppe de position — un ERC-721, qui suit la garantie et la dette comme une seule unité, plafonnée par le MLTV.
‎
‎Ce qui m’a marqué, c’est que XT n’est pas du remplissage : c’est un instrument financier distinct qui représente, à lui seul, le risque de taux d’intérêt, et qui est valorisé séparément du risque du principal dans FT. Séparer le principal de l’intérêt au niveau des jetons, c’est ce qui permet à l’équation zéro-somme complète du système de tenir — aucune valeur n’apparaît ni ne disparaît nulle part dans la chaîne. #TermMax
‎
‎La pièce manquante, pour moi, c’est une vraie profondeur de marché secondaire pour XT précisément, puisque sa tarification porte sur quelque chose d’aussi étroit que le risque d’intérêt à court terme, à lui seul.
‎
‎

« Quel jeton compte le plus pour vous ? »

#termmax

@TermMax

@TermMax ‎J’ai supposé que la liquidation sur TermMax signifiait la même chose que partout ailleurs où je l’ai déjà utilisée — franchir la ligne de danger, perdre l’intégralité de la position en une seule fois, sans étape intermédiaire.
‎
‎Cette hypothèse s’est effondrée quand j’ai lu la formule exacte. La liquidation se déclenche de deux façons : le LTV atteint ou dépasse le seuil LLTV du marché, ou l’emprunteur manque le remboursement à échéance fixe, ce qui ouvre une fenêtre de liquidation de deux heures, indépendamment du prix. $ACE
‎
‎Voici le chiffre qui a tout remis en perspective. Si la dette restante dépasse 10 000 $, les liquidateurs sont plafonnés à 50 % de la valeur totale de la dette par événement. Le collatéral maximum liquidable est calculé comme le collatéral total multiplié par la dette liquidée, divisé par la dette totale — un ratio conçu pour que le LTV s’améliore après chaque liquidation au lieu de s’effondrer à zéro. La liquidation intégrale ne se produit que si la dette tombe exactement à zéro, auquel cas le collatéral restant est automatiquement renvoyé à l’emprunteur.
‎
‎La pénalité est de 10 % de la valeur de la dette liquidée, répartie exactement en deux parts — 5 % pour le liquidateur en tant que récompense, 5 % pour le coffre de réserve du protocole.
‎
‎Ce que la documentation ne dit pas, c’est quelle part des positions réelles dépasse effectivement 10 000 $ de dette au lieu de rester en dessous de ce seuil, là où le plafond ne s’appliquerait même pas. $CLO
‎
‎Le vrai test pour TMX, c’est de savoir si ce plafond de 50 % protège réellement les gros emprunteurs de façon significative, ou s’il ne fait que transformer une liquidation en deux plus petites, juste à la suite. $CYS
‎
‎Quelqu’un a-t-il suivi les décomptes de liquidations partielles versus totales sur TermMax pour l’instant ?
‎

#termmax @TermMax

@Dusk ‎J'ai vérifié comment Dusk se présente face à Ethereum précisément, étant donné que la plupart des comparaisons entre chaînes axées sur la confidentialité se rabattent plutôt sur Zcash ou Monero.
‎
‎La page d’accueil actuelle de Dusk énonce clairement la cible : une infrastructure pour des actifs numériques réglementés, confidentielle par défaut, avec des preuves à connaissance nulle et une visibilité contrôlée pour l’audit et la divulgation réglementée. C’est un cadrage nettement plus tranché que la présentation publique antérieure de Dusk, qui mettait davantage l’accent sur la combinaison des transactions publiques de Moonlight avec le modèle de confidentialité de Phoenix pour une finance réglementée au sens large, sans pousser autant le contraste direct avec la transparence d’Ethereum.
‎
‎Ce qui a changé entre ces deux cadrages mérite qu’on s’y attarde. Le défaut d’Ethereum — chaque solde, chaque appel, visible par n’importe qui — fonctionne très bien pour la coordination publique. Le DuskEVM de Dusk exécute une équivalence EVM complète en utilisant les mêmes outils que les développeurs Ethereum connaissent déjà, tout en conservant, en dessous, la posture de Dusk « protégée par défaut ». Le modèle d’exécution n’est pas rejeté. C’est le défaut de visibilité qui l’est. $DUSK
‎
‎Le site même de Dusk liste désormais des partenaires spécifiquement réglementés dans l’UE qui construisent activement à partir de ce positionnement — un fournisseur d’infrastructure de marché agréé dans le cadre du régime DLT Pilot, ainsi qu’une plateforme européenne réglementée explorant l’émission on-chain directement via ce cadrage.
‎
‎Il s’agit d’un véritable mouvement institutionnel, pas seulement de la communication — mais savoir si cela se traduit par une migration significative des développeurs loin des piles orientées Ethereum en particulier à cause de la question de transparence, c’est quelque chose que je n’ai pas trouvé permettant de confirmer via des chiffres d’adoption dans un sens ou dans l’autre. #dusk
‎
‎Si quelqu’un a suivi des données réelles de migration liées précisément à l’argument de la transparence, plutôt qu’à la proposition de conformité plus large de Dusk, je voudrais comparer cela avec ce qui est publiquement nommé dans la liste de partenaires de Dusk.

#dusk $DUSK @Dusk

@Dusk ‎j’avais l’habitude qu’un vérificateur sur Dusk doive voir les détails d’une transaction pour confirmer qu’elle était légitime.
‎
‎Ce n’est pas ce qui se passe avec Phoenix.
‎
‎J’ai suivi ce que le vérificateur reçoit réellement, plutôt que les données brutes. Les documents d’architecture de Dusk confirment que Phoenix utilise des preuves à divulgation nulle de connaissance, précisément pour prouver la propriété des sorties non dépensées et empêcher la double dépense — le vérificateur vérifie la preuve, pas la transaction elle-même.
‎
‎Hmm.
‎
‎Alors qu’y a-t-il concrètement dans cette preuve, mécaniquement ?
‎
‎Je me suis penché là-dessus un moment. Un dépensier prouve qu’il connaît le chemin vers la racine de l’arbre de Merkle, ainsi que qu’il connaît l’ouverture de l’engagement — ce qui signifie que la preuve démontre mathématiquement que le billet existe dans l’arbre et que le dépensier sait réellement ce qu’il contient, sans divulguer ni le contenu du billet ni sa localisation à quiconque regarde.
‎
‎Le fait de dépenser elle-même nécessite une clé secrète connue exclusivement par le propriétaire du billet — de sorte que l’étape de génération de la preuve ne peut pas non plus avoir lieu sans la seule information que personne d’autre n’a.
‎
‎C’est une garantie plus étrange que ce que ça ne sonne au départ. Le vérificateur ne fait pas confiance à la parole de l’expéditeur. Il ne fait pas non plus confiance à un tiers. Il confirme une affirmation mathématique — l’appartenance à l’arbre plus la connaissance de l’engagement — qui est vraie, sans jamais reconstituer ce qui a rendu cela vrai.
‎
‎Je ne dis pas que c’est un contrôle plus faible. Au contraire, refuser de regarder pourrait être le vrai point — le vérificateur ne peut pas être trompé par des données qu’il ne reçoit même pas en premier lieu.
‎
‎Un système conçu pour vérifier l’appartenance à l’arbre et la connaissance de la clé secrète, sans jamais voir les montants, inspire-t-il plus confiance que celui qui vérifie en regardant directement les données ?
‎

@Dusk #dusk $DUSK

@TermMax utilisé pour penser qu’un prêt apparaissait simplement comme un nombre qui s’affiche dans un solde de compte.
‎
‎Plus j’ai regardé comment TermMax structure réellement une position, moins cela tenait.
‎
‎Un emprunteur bloque une garantie. TermMax émet un Gearing Token contre celle-ci, un ERC-721, et non une écriture comptable. Le token de dette, le token de garantie et la date d’échéance sont tous fixés au niveau du marché avant même que ce GT n’existe.
‎
‎Le GT lui-même enregistre exactement deux choses. La quantité de garantie qui y est logée. Le nombre de Fixed-Rate Tokens qui ont été émis en face de cette garantie, plafonné par le LTV maximal du marché. Un MLTV de 0,8, par exemple, transforme 1 ETH en jusqu’à 800 $USDC de dette émettable. #TermMax
‎
‎Aucun pool partagé, aucun netting, aucun nombre fusionné nulle part dans la conception.
‎
‎Relis cette partie sur l’isolation deux fois. TermMax exécute 100+ marchés à sa mise à jour de mars 2026, chacun étant hermétiquement séparé des autres, de sorte qu’un mauvais prix de garantie sur un marché ne touche jamais les GT présents dans les autres. Pas de tenue de comptes. Une frontière.
‎
‎Remboursez directement avec des tokens de dette, ou bien rachetez les FT sur le marché libre et rendez-les à la place. Dans les deux cas, le GT se clôt et la garantie est libérée, mais il n’a jamais fusionné avec les chiffres de quelqu’un d’autre dès le départ.
‎
‎Ainsi, emprunter sur TermMax n’est pas un seul nombre qui augmente ou diminue. c’est autant de GT que vous en avez ouverts, chacun portant sa propre garantie, sa propre dette, sa propre échéance, dans son propre cadre.
‎
‎Le suivi par prêt rend-il le risque plus clair, ou simplement plus difficile à gérer à grande échelle ?
‎
‎@TermMax #termmax

@Dusk pensait que « divulgation sélective » n’était qu’un mot plus doux pour parler de la transparence.

Je me suis attardé sur le vrai design de Citadel, et ce n’est pas ça.

Une transparence totale, le genre contre lequel Dusk construit explicitement, signifie que chaque observateur voit chaque attribut associé à une transaction ou une identité, qu’il en ait besoin ou non. Citadel fait quelque chose de plus restreint, et j’ai retracé les mécanismes réels : trois parties distinctes, pas deux. Un utilisateur demande une licence sur la blockchain à un fournisseur de licences. Une fois émise, cette licence permet à l’utilisateur d’établir une connexion privée, hors chaîne, avec un prestataire de services — qui vérifie l’affirmation en n’utilisant que ce qui est stocké sur la blockchain, sans jamais apprendre l’identité réelle de l’utilisateur.

Hmm.

Alors qu’est-ce que le prestataire de services apprend concrètement quand la vérification passe ?

Juste qu’une seule affirmation est vraie — lieu de résidence, tranche d’âge, accréditation, ou tout ce que couvre la licence. Pas les données sous-jacentes derrière cela, pas un autre attribut que l’utilisateur possède, pas un identifiant persistant reliant cette vérification à une future.

C’est une promesse bien plus étroite que ne le laisse entendre la transparence. Un système entièrement transparent dit tout à tout le monde, de façon permanente, que ce soit pertinent ou non. La structure à trois parties de Citadel fait dire à un seul prestataire de services une seule chose vraie, vérifiée à partir d’un enregistrement on-chain, sans que ce prestataire touche jamais au profil complet de l’utilisateur.

Je ne dis pas que la transparence est mauvaise partout. La coordination publique bénéficie réellement du fait que tout le monde voie le même registre. Mais pour les actions conditionnées par l’identité — prouver son éligibilité sans dévoiler un profil complet — il fallait un protocole avec trois rôles distincts, pas deux, pour que cela fonctionne réellement.

Prouver une seule chose vraie à travers trois rôles séparés constitue-t-il une garantie de confidentialité plus forte que la transparence de « tout le monde voit tout, donc personne ne cache quoi que ce soit » ?

@Dusk #dusk $DUSK

Le propre dépôt de Dusk indique que le nullificateur est calculé spécifiquement de façon à ce qu’un observateur externe ne puisse pas le relier à une note particulière.

@Dusk a supposé que l’éligibilité sur Dusk était quelque chose que vous avez gagné une fois et que vous avez conservé, comme un badge qui reste épinglé.

en réalité, ce sont trois mécanismes distincts qui fonctionnent ensemble, et chacun d’eux peut le retirer.

d’abord : le montant minimum misé. j’ai confirmé qu’un provisioner de Dusk doit avoir 1000 DUSK verrouillés, et en dessous de ce seuil, le reste de la mise n’a plus d’importance.

en second : la maturité. même une mise au-dessus du minimum doit attendre un nombre fixe d’époques avant que la sortition de Dusk ne la prenne en compte. $DUSK

troisièmement, et c’est celui que j’ai presque manqué : la pénalisation. j’ai constaté que des fautes répétées ne coûtent pas seulement des récompenses — chaque suspension consécutive déplace un pourcentage croissant de la mise dans le pool de récompenses revendiquables, en commençant à 10 % et en montant de 10 % à chaque violation suivante.

j’ai retracé ce qui se passe quand cette pénalisation fait passer une mise sous le seuil des 1000 DUSK. elle ne perd pas seulement du poids dans la sortition. j’ai constaté qu’elle se fige purement et simplement — le seul moyen de revenir sur Dusk est de désinvestir la partie restante gelée et de réinvestir du neuf.

ainsi, l’éligibilité n’est pas une seule porte que le provisioner franchit une fois. c’est trois mécanismes distincts — un plancher, une horloge et un calendrier de pénalités — dont n’importe lequel peut discrètement disqualifier un provisioner de Dusk qui pensait encore être actif. #dusk

l’empilement de l’éligibilité sur trois mécanismes indépendants rend-il Dusk plus résistant au “gaming”, ou bien rend-il simplement plus facile pour un provisioner honnête de perdre son statut sans réaliser immédiatement pourquoi ?

#dusk $DUSK @Dusk

Le crépuscule construit autour d’un problème que les blockchains transparentes ne peuvent pas toujours résoudre efficacement.

#dusk $DUSK

DuskVM comparé à DuskEVM sur le réseau DUSK

@Dusk Au départ, je me disais que choisir entre DuskVM et DuskEVM se résumait à une question de langage : Rust et WASM contre Solidity avec les outils EVM que tout le monde utilise déjà. J’y ai passé plus de temps que prévu ce soir, et, à un moment, ça a cessé de ressembler à un choix de langage.

DuskVM se situe tout à la base du réseau : il bénéficie d’un accès direct aux éléments de confidentialité et de preuve à connaissance nulle autour desquels Dusk a réellement été construit. DuskEVM fait tourner des contrats Solidity via des outils EVM standards, mais il finit quand même par régler et publier ses données via la même couche DuskDS, en payant le gaz avec le même token DUSK, dans un sens comme dans l’autre. C’est une symétrie étrange à laquelle je reviens sans cesse : des parcours d’exécution différents, un règlement identique, et le même token en dessous des deux.

Choisir DuskVM, ce n’est pas seulement choisir un langage : c’est choisir la proximité avec les briques de confidentialité elles-mêmes. Choisir DuskEVM, ce n’est pas seulement la familiarité : c’est s’éloigner de ces briques pour des outils dont la plupart des développeurs connaissent déjà l’usage. C’est une friction subtile que beaucoup de comparaisons laissent de côté. #dusk

Il y a une troisième couche sous les deux, et c’est celle vers laquelle je reviens sans cesse. La documentation de Dusk confirme que DuskEVM permet de brancher des portefeuilles EVM, des ponts et des échanges existants avec à peine des changements de code, plus vite qu’une intégration native ne l’exigerait. DuskVM n’offre pas de raccourci équivalent. Les outils doivent être construits pour cela, à partir de rien, à chaque fois. $DUSK

L’équivalence des fonctionnalités entre les deux n’est pas garantie simplement parce qu’ils règlent via la même couche et partagent un token de gaz. Ce qui ressemble à une forme de souplesse à la surface, ce sont en réalité deux paris différents sur l’endroit où le coût réel est payé : en amont, dans la création des outils, ou plus tard, dans un environnement que ce dernier ne peut pas produire.

Dusk offre-t-elle réellement aux builders un choix ici, ou décide-t-elle seulement pour eux là où la friction apparaîtra ? @Dusk