jinxfi

Les plus petits détails d’un modèle de transaction peuvent parfois avoir des conséquences plus importantes que les fonctionnalités principales.

Dusk utilise un nonce lié au compte de l’expéditeur, et cette valeur s’incrémente lorsqu’une transaction est exécutée avec succès. Sa tâche, simple, est importante : le réseau peut distinguer une nouvelle transaction d’une transaction déjà utilisée au lieu de traiter des requêtes identiques comme des actions indépendantes.

J’aime à quel point ce mécanisme est ennuyeux.

Une bonne infrastructure de transaction nécessite souvent des règles dont les utilisateurs ne pensent jamais avant qu’un problème ne survienne. Les nonces fournissent une séquence claire de ce que le compte a déjà exécuté.

Mais il y a un autre aspect à cette simplicité.

Lorsque les transactions provenant du même compte dépendent d’une séquence ordonnée de nonces, des actions indépendantes ne peuvent pas toujours se comporter comme si elles étaient totalement sans lien. La règle d’ordonnancement donne une structure à l’exécution, mais elle peut aussi imposer des contraintes sur la manière dont les transactions circulent dans le système.

Alors l’ordonnancement des nonces au niveau du compte donne-t-il à Dusk la bonne discipline de transaction, ou une séquence stricte deviendrait-elle un frein lorsque des applications financières ont besoin d’une exécution plus parallèle ?

#dusk @Dusk $DUSK

I was thinking about what happens when a transaction reaches Dusk.

At first, it feels like there is only one question:

**“Should the network accept this?”**

But looking closer, there are actually two different questions.

First, does the transaction follow the protocol’s rules?

Then, assuming it does, do participants agree on the state that results from it?

That distinction is easy to miss because, from the outside, both steps lead toward the same outcome: an accepted state.

But architecturally, they are different jobs.

If something goes wrong, separating them makes it easier to ask what actually failed. Was the transaction invalid? Or was it valid, but did participants disagree about the resulting state?

I think that separation is a strong design choice.

But it also creates a new question.

Every boundary between responsibilities is another handoff. And every handoff needs to behave correctly when something unexpected happens.

So I keep coming back to this:

**Does separating validity from consensus make Dusk easier to reason about under failure, or does every additional boundary create another place where the system can break?**

#Dusk @Dusk $DUSK

Plus je lis sur la @Dusk _Foundation, plus je me dis que la confidentialité n’est peut-être pas la partie la plus difficile.

Dusk utilise des preuves à divulgation nulle (ZK) pour garder les détails des transactions privés tout en prouvant que la transaction est valide.

Cela semble utile pour la finance réglementée, où vous ne voudriez peut-être pas que chaque détail de transaction soit visible de tous.

Mais alors vient la question plus vaste :

Si les détails sont masqués, qui peut les voir quand c’est nécessaire ?

J’aime que Dusk considère la confidentialité et la capacité d’audit comme des éléments qui peuvent fonctionner ensemble.

Mais plus la visibilité devient sélective, plus les règles d’accès deviennent importantes.

Alors je continue de me demander :

La confidentialité programmable résout-elle vraiment le problème de transparence pour les marchés réglementés, ou est-ce qu’elle déplace simplement la partie difficile vers l’accès et la vérification ?

#dusk @Dusk $DUSK

Something else i keep thinking about with TermMax is transaction ordering.

The protocol can have carefully defined lending and borrowing mechanics, but the transaction still has to make it through a blockchain environment where ordering can matter.

That creates a different kind of risk.

MEV isnt necessarily a failure of the lending design itself. Its a consequence of how transactions are processed around that design, and it can affect execution through things like unfavorable ordering or slippage.

I think thats an important distinction because a protocol can have sound financial mechanics and still expose users to execution-level problems.

So should protocol analysis treat transaction ordering as part of TermMax’s core risk model, or as a separate risk created by the surrounding execution environment??

@TermMax #TermMax

Je me suis dit que « la finalité rapide » concernait surtout le fait d’obtenir un bloc confirmé plus vite, puis j’ai regardé comment Dusk décrit la finalité en continu, et ce n’est pas vraiment la partie la plus intéressante.

Le consensus Succinct Attestation de Dusk ne vise pas seulement à atteindre la finalité en quelques secondes. Le livre blanc décrit la finalité en continu comme un moyen de limiter le nombre d’itérations de consensus nécessaires avant qu’un bloc ne devienne final.

Cette petite distinction compte.

Plutôt que de continuer à utiliser des ressources réseau pour prouver la finalité du même bloc, le processus avance tout en gardant le travail de finalisation borné. J’aime ce design pour l’infrastructure financière, parce que le règlement n’est pas très utile si chaque étape supplémentaire ajoute une couche de temps d’attente et de calcul.

Mais il y a une question en dessous.

Plus il faut peu d’itérations de consensus, plus la finalité devient efficace. En même temps, ces itérations font partie de ce qui donne au réseau la confiance qu’un bloc devrait être final.

Alors où est le bon équilibre ??

Limiter les tours de finalisation rend-il Dusk mieux adapté au règlement financier, ou l’efficacité finit-elle par devenir un compromis avec la quantité de travail de consensus qui est souhaitable ??

@Dusk #dusk $DUSK

Quelque chose dans la structure du coffre-fort de TermMax m’a fait repenser ce que signifie réellement la « gestion de liquidité ».

Un coffre-fort n’est pas simplement un autre endroit où garer du capital. La conception utilise une comptabilité de type ERC-4626 et permet de déployer le capital sur des marchés compatibles, au lieu de considérer chaque position de marché comme totalement isolée.

J’aime cette séparation, car la gestion du capital peut se faire au-dessus du niveau du marché individuel.

Mais c’est aussi là que la question devient plus difficile.

Plus un coffre-fort peut interagir avec de nombreux marchés, plus le capital peut devenir utile, mais la décision quant à l’endroit où ce capital doit se placer devient aussi plus importante.

Le déploiement plus large du capital améliore-t-il réellement l’efficacité, ou bien cela rend-il la gestion des risques plus difficile à interpréter ??

@TermMax #TermMax

I went digging into why Dusk rewards voters for supporting candidates from earlier, failed iterations.

At first, the process looks simple:

Proposal → Validation → Ratification

But the interesting part is what happens when an iteration fails.

Instead of letting the failed block disappear, Dusk gives later committees a reason to bring it back.

What surprised me is that this voter reward was added for a specific reason: to encourage future committees to vote on candidates from previous iterations.

So the protocol added a financial incentive to make recovering a failed block worth doing.

That makes a failed iteration less like a dead end and more like something the network is still willing to recover.

The interesting question is:
iIs Dusk smartly rewarding committees for finishing unfinished work, or does it show that recovery needs a financial push in the first place?

#dusk @Dusk $DUSK

Make it short

J’ai commencé à considérer la gouvernance de TMX différemment dès que j’ai remarqué ce que le staking est censé changer.

Les détenteurs de TMX peuvent participer à la gouvernance, mais le staking peut aussi offrir des droits de gouvernance renforcés concernant des éléments tels que les paramètres de risque de marché et la liste blanche des validateurs.

Cela m’intéresse davantage que le simple fait d’avoir un autre système de vote.

Ces décisions peuvent influencer directement la manière dont les marchés à taux fixe sont gérés, si bien que la gouvernance devient liée à la configuration réelle du protocole plutôt qu’à de simples propositions générales.

Le point positif est évident : les personnes qui s’engagent sur le long terme peuvent avoir davantage d’influence.

Mais cela soulève une question plus difficile. Une prise de décision plus concentrée peut améliorer la responsabilisation, ou bien faire en sorte que la qualité du jugement d’un groupe plus restreint compte beaucoup plus.

La gouvernance renforcée conduit-elle à de meilleures décisions pour le protocole, ou fait-elle simplement que le pouvoir de gouvernance se concentre davantage ?

@TermMax #TermMax

Quelque chose concernant l’émission native sur Dusk me trottait dans la tête.

Je pensais autrefois que tokenisation et émission native étaient fondamentalement la même chose, avec des formulations différentes. Ce n’est pas le cas.

La tokenisation commence avec un actif existant et crée une représentation onchain de cet actif. L’émission native va plus loin : le titre lui-même peut avoir son cycle de vie structuré onchain à partir du moment de l’émission.

La conception de Zedger de Dusk est intéressante ici, car elle ne se limite pas à la détention d’une représentation tokenisée. Le livre blanc décrit la prise en charge de titres qui sont soit tokenisés, soit émis nativement, avec des fonctions de cycle de vie telles que la frappe (minting), la destruction (burning) et les opérations sur le plan corporatif (corporate actions) intégrées au modèle d’actif.

Cela me paraît plus clair.

Mais cela pose aussi une question plus difficile. Si davantage du cycle de vie du titre passe sur la chaîne, davantage de ce cycle de vie doit respecter les règles de l’émetteur, de la plateforme (venue) et de la juridiction. La seule capacité technique ne rend pas l’actif natif dans la pratique.

C’est la partie à laquelle je reviens sans cesse.

Le fait de rapprocher le cycle de vie du titre de la chaîne rend-il vraiment les marchés réglementés davantage natifs, ou bien est-ce que cela ne fait que déplacer plus de complexité réglementaire directement dans l’actif lui-même ?

@Dusk $DUSK #dusk

I keep thinking scalability gets described too narrowly in blockchain.

A chain can process more transactions and still be awkward for financial applications if execution becomes unpredictable as activity grows.

What interested me in Dusk is that scalability is treated as a systems problem rather than just a bigger throughput number. The architecture separates concerns across consensus, networking and execution, which gives each layer a more specific job.

That sounds cleaner than simply chasing a headline TPS figure.

But there’s a question underneath it. Financial applications dont just need capacity when demand is low. They need the system to remain predictable when multiple workflows compete for resources at the same time.

Higher theoretical capacity is useful. Predictable capacity is harder.

So is Dusk's layered approach actually a better path toward scalable financial infrastructure, or does separating the system into more specialized components just create more complexity to manage??

#dusk @Dusk $DUSK

J’ai passé un moment à examiner la couche réseau @Dusk et je me suis surpris à prêter davantage attention à quelque chose que la plupart des utilisateurs ne voient jamais : la manière dont les blocs se déplacent réellement à travers le réseau.

Kadcast utilise une conception pair-à-pair structurée, fondée sur un routage de type Kademlia plutôt que de simplement transmettre chaque message à tous les pairs connectés. L’idée est de rendre la propagation plus ciblée et de réduire la quantité de communications redondantes qui se produisent sur l’ensemble du réseau.

Cela ressemble à un détail côté backend.

Ça ne doit probablement pas l’être.

Pour une chaîne liée à des activités financières, l’efficacité du réseau finit par faire partie de l’expérience utilisateur. Si les nœuds fournissent moins d’efforts pour faire circuler à répétition la même information, le réseau a plus de marge pour accomplir un travail utile plutôt que de s’enliser dans les frais de communication.

La partie dont je suis moins certain, c’est l’arbitrage. Un système de propagation plus structuré peut réduire le gaspillage, mais il implique aussi davantage d’hypothèses sur la façon dont le réseau est organisé et sur la manière dont les nœuds se rejoignent.

Alors, une propagation de blocs plus intelligente améliore-t-elle vraiment la base du règlement financier, ou bien la structure réseau ajoutée crée-t-elle une complexité qui devient plus difficile à gérer à grande échelle ??

#dusk @Dusk $DUSK

Most EVM applications treat transparency as a feature. But in institutional finance, that assumption starts to break down.

DeFi works well with public balances and transactions. Institutions often need something different: proving a trade is valid without exposing the entire portfolio, balance sheet, or counterparties.

That’s where DuskEVM gets interesting.

Dusk keeps the familiar Solidity and EVM environment while using confidential execution, encryption, and zero-knowledge proofs to separate verification from visibility.

The network can verify that the rules were followed without forcing everyone to see the underlying data.

That distinction matters.

Privacy doesn’t have to mean sacrificing verification. It can mean controlling who sees what while keeping the state provable.

The real challenge is making proof generation, performance, integration, and selective disclosure work reliably at scale.

As tokenized assets and institutional blockchain adoption grow, the question may not be whether financial data should be onchain.

It may be how much of that data actually needs to be visible.

The next EVM design problem might not be execution.

It might be controlled visibility.

@Dusk $DUSK #dusk

Je fouillais aujourd’hui dans des documents de consensus @Dusk et ce qui m’a interpellé n’était pas la partie confidentialité.

C’était l’importance que Dusk accorde à ce qui se passe après qu’une transaction a été acceptée.

L’Attestation succincte est conçue pour offrir à Dusk une finalité déterministe une fois qu’un bloc est ratifié. Cela signifie que la transaction ne fait pas que devenir « plus susceptible » de rester en place à mesure que des blocs supplémentaires arrivent : elle atteint un état final défini.

Cela ressemble à un détail technique jusqu’au moment où l’on pense aux actifs financiers.

Si vous traitez un titre tokenisé ou une transaction livraison-contre-paiement, l’incertitude sur le fait que l’état du registre puisse encore changer devient un problème opérationnel.

Alors j’ai commencé à voir Dusk moins comme une chaîne de confidentialité et davantage comme un système de règlement.

La question intéressante pour moi, c’est de savoir si la finalité déterministe devient réellement plus importante que la confidentialité lorsque de vrais actifs financiers commencent à circuler onchain.

Car masquer une transaction est utile.

Mais savoir exactement quand cette transaction est finale peut être tout aussi important.

#dusk $DUSK @Dusk

Spent some time going through Dusk’s transaction docs and the part that made me stop wasn't the ZK proof itself.

It was what happens after the transaction becomes private.

Phoenix hides the amount, sender and specific notes from public observers, but Dusk also supports viewing keys and selective disclosure when an authorized party actually needs evidence.

That creates a more interesting model than “privacy = nobody can see anything.”

A regulator, auditor or issuer may need to see something without the rest of the market seeing it.

So the real design problem isn't hiding the transaction.

It's deciding who gets to see the hidden information, and for what reason.

That's where privacy starts looking less like a binary switch and more like an access-control problem.

Makes me wonder how much institutional privacy ultimately depends on the cryptography itself versus the rules governing disclosure.

#dusk $DUSK @Dusk