一只瓢虫

天涯共此时：在BSC上，和世界一起过中秋
今年，是我与加密一起度过的第4个中秋。第一次买BNB时，我以为加密只是屏幕上的涨跌；后来走进币安、跨过BSC，才发现它更像一张没有时区的网。中秋讲团圆，而链上也在团圆——把不同大陆、不同语言、不同时区的人，连到同一个市场里。
以前，交易有“时差”：纽约收盘，东京未醒，亚洲投资者常要熬夜。如今，币安与BNB Chain让7×24小时不再是口号。凌晨三点，我在BSC上完成一笔转账，Gas用BNB支付，几秒确认；同一时刻，地球另一端的伙伴正在币安看盘、参与Launchpool、讨论生态。月亮照着我，也照着他，区块像月光下的驿站，把跨地域的参与者接进同一场流动。
我畅想未来：全球市场不再是割裂的孤岛，股票、黄金、债券、RWA都能在链上24/7交易；币安是那座不关门的“全球金融码头”，BSC是连接资产与用户的桥。交易无时差，不只是K线永不停歇，更是普通人也能共同参与全球金融的机会。无论身在哪个时区，打开币安、连接BSC，就能和世界同步。
天涯共此时。今年第4个中秋，我在链上抬头，看见的不只是月亮，还有无数节点共同闪烁。愿下一个中秋，我们仍在BNB Chain上碰杯，在币安见证全球市场一起跳动。
#币安中秋故事

bAprès l’ouverture du nantissement des actions, comment mieux parvenir à « revitaliser les positions » tout en maîtrisant les risques ? Par exemple, si l’on utilise les fonds empruntés pour allouer à d’autres actifs, y a-t-il des recommandations de positions plus sûres ou de stratégies de couverture ?

Ouh là là, 333166 HYPE$HYPE

Waouh, 45 millions de dollars américains pour acheter $PONS et $CASHCAT

Le BTC vient juste de passer sous les 78 000 dollars, et sur 24 heures il continue de monter ; franchement, cette tendance laisse vraiment perplexe 😂$BTC

Waouh, le BTC ($BTC ) est passé sous les 78 000 dollars

Waouh, 1 040 000 $ pour acheter 20 310 201 tonnes de MEME$MEME

Un immense baleinier a retiré 1,1 million de USDT de Binance, puis a aussitôt acheté 9,53 millions de $牛 à un prix moyen de 0,1155 $ — c’est pour faire monter directement le prix du taureau ?$USDC

Waouh, 110万枚$USDC

Waouh, un milliard de dollars ! $SOL

À chaque tour de consensus, il faut ajouter un nouveau bloc, mais le livre blanc indique que ce tour n’est pas un processus unique terminé d’un seul coup : il se déroule en plusieurs itérations, et chaque itération se décompose en trois étapes. Le livre blanc, à la section 3.2, appelle ces trois étapes : Proposal, Validation et Ratification.

Première étape : Proposal. L’algorithme DS choisit aléatoirement un provisioner comme producteur de bloc, chargé de générer des blocs candidats, puis de les diffuser sur tout le réseau. Si aucun bloc candidat n’est produit ou reçu dans le délai de temporisation prescrit, cette étape renvoie NIL et passe directement à l’étape suivante — mais puisque l’on n’a pas de bloc candidat entre les mains, que vote-t-on ensuite ? La réponse : ne pas émettre un vote vide, mais voter NoCandidate, ce qui signifie « aucun bloc candidat n’est vérifiable ».$DUSK

Deuxième étape : Validation. L’algorithme DS sélectionne aléatoirement un ensemble de comités de vote, afin de vérifier le bloc candidat issu de l’étape précédente. Si le bloc candidat est valide, on vote Valid ; s’il est invalide, on vote Invalid ; et s’il n’y a aucun bloc candidat, on vote NoCandidate. Le comité de vote doit atteindre une majorité absolue des 2/3 pour obtenir un quorum. Si le quorum n’est pas atteint dans le délai, le système renvoie NoQuorum. La sortie de cette étape est un ValidationResult, qui comprend le type de vote ayant permis d’atteindre le quorum ainsi que la signature agrégée de tous les votants.@Dusk

Troisième étape : Ratification. On sélectionne ensuite un nouvel ensemble de comités de vote, qui confirme le résultat de Validation. Si, à l’étape précédente, un quorum de Valid a été atteint, ils confirment ce résultat ; si l’étape précédente est NoQuorum ou en échec, ils votent NoQuorum. Cette étape garantit que le résultat de la validation ne dépend pas d’une minorité, mais est reconnu par davantage de provisioners.

Si la Ratification renvoie Success, le bloc candidat est alors accepté officiellement comme nouveau bloc, et le tour se termine. Si la sortie est Fail ou unknown, on passe à la prochaine itération : on redésigne le producteur de blocs et on relance un vote. Le livre blanc précise que le nombre maximal d’itérations est déterminé par un paramètre global ; l’actuel est 50. Si 16 itérations consécutives échouent, le protocole entre en mode d’urgence (angle 10).

La logique centrale du design en trois étapes est l’équilibrage — le producteur de bloc ne peut que générer des blocs candidats, pas voter ; le comité de validation ne peut que vérifier, pas confirmer ; et le comité de ratification ne peut que confirmer le résultat de la validation, pas effectuer une nouvelle vérification. Aucun rôle ne peut, à lui seul, décider du destin d’un bloc.#dusk

Lors du démarrage du réseau Dusk, ce n’est pas seulement la machine virtuelle Piecrust qui entre en jeu : il faut aussi déployer un ensemble de contrats de genèse, qui assurent les opérations les plus fondamentales. Dans la section 6.2 du livre blanc, on les appelle « genesis contracts ». Il s’agit de contrats intelligents spéciaux déployés lors de l’initialisation du réseau, responsables de fonctions essentielles telles que la validation des transactions, le mécanisme de mise sous garantie (staking) et la répartition initiale des jetons. Le livre blanc met particulièrement l’accent sur deux d’entre eux.

Le premier est le contrat de transfert (transfer contract). Il gère tous les transferts de DUSK, $DUSK tout en traitant simultanément la déduction des frais de gaz. Si une transaction inclut un déploiement ou un appel de contrat intelligent, le transfer contract prend également en charge le traitement : il vérifie que la transaction respecte les règles de Moonlight ou Phoenix, puis déduit les frais de gaz correspondants du solde de l’expéditeur. Le livre blanc indique que c’est « le point d’entrée dans la blockchain Dusk », et que toutes les transactions doivent finalement passer par lui.

Le second est le contrat de mise sous garantie (stake contract). Il gère l’ensemble du cycle de vie du staking : il vérifie que le montant déposé par l’utilisateur atteint le seuil minimal requis, verrouille les jetons et enregistre l’utilisateur comme provisioner. Plus l’utilisateur mise de DUSK, plus la probabilité qu’il soit sélectionné par l’algorithme DS pour participer au consensus est élevée. Le contrat traite aussi les demandes de désengagement : une fois la période de verrouillage terminée, l’utilisateur peut récupérer ses jetons, tout en garantissant que l’émission des récompenses et la déduction des pénalités s’exécutent correctement. Le seuil de 1000 DUSK mentionné à l’« angle 1 », ainsi que les récompenses et pénalités évoquées à l’« angle 9 », prennent effet concrètement grâce à ce contrat. @Dusk

La section 6.3 ajoute encore deux autres « contrats ». L’un est le contrat de licence (license contract). Basé sur le protocole Citadel, il gère l’émission et la validation des licences au sein du réseau : il suit la propriété, la validité et les dates d’expiration de chaque licence, et traite les révocations ou les renouvellements. L’autre est le ensemble de contrats Zedger : il instancie un contrat intelligent distinct pour chaque type d’actif de titres, fournissant des fonctions telles que le mint (émission), le burn (destruction), la distribution de dividendes et le transfert forcé, et constitue la mise en œuvre concrète du protocole Zedger évoqué à l’« angle 7 ».

La répartition des rôles entre les quatre contrats est très claire : le transfer contract gère la liquidité, le stake contract gère la participation au consensus, le license contract gère les permissions, et les contrats Zedger gèrent les actifs. Mais cela implique aussi que les fonctions essentielles de Dusk dépendent fortement de la correction de ces quatre contrats : si l’un d’entre eux présente un bug, ce n’est pas seulement une application isolée qui est touchée, mais les opérations de base de l’ensemble du réseau. #dusk

Section 1.1 du livre blanc « Travaux connexes » : en réalité, elle n’a fait qu’une seule chose : dire au lecteur que Dusk n’est pas n’importe qui.

Le livre blanc classe la blockchain existante en trois catégories. La première regroupe les plateformes de contrats intelligents génériques, comme Ethereum et Cardano. Leur problème, c’est que la transparence rend les données financières sensibles impossibles à dissimuler ; même avec des solutions de couche 2 comme les zk-rollups, ce ne sont que des rustines, pas une conception native. La deuxième catégorie regroupe les blockchains de confidentialité, à savoir Zcash et Monero. Elles poussent la confidentialité individuelle à l’extrême, mais manquent de cadre de conformité, de capacité d’audit et de contrats intelligents adaptés aux transactions confidentielles. La troisième catégorie correspond à ce que Dusk veut faire : il n’est pas comme les deux autres.

Ce qu’Ethereum peut faire, Dusk@Dusk ne le fait pas — il ne cherche pas une couverture complète de la DeFi généraliste, mais se concentre sur des scénarios financiers réglementés. Ce que Zcash et Monero peuvent faire, Dusk le fait aussi : il utilise des preuves ZK pour assurer la confidentialité, mais ajoute, par-dessus, des interfaces de conformité et des capacités d’audit. Le livre blanc est très clair : Zcash et Monero « manquent des fonctionnalités nécessaires à l’intégration avec le secteur financier réglementé », y compris le cadre de régulation, la capacité d’audit et la capacité des contrats intelligents à prendre en charge les transactions confidentielles.$DUSK

Ce n’est pas une phrase qui dit « Dusk est meilleur que tous les autres », mais une phrase qui dit « la voie que Dusk choisit est différente ». Il choisit une route plus étroite — une blockchain de confidentialité conforme, destinée aux institutions financières traditionnelles, plutôt qu’une blockchain de confidentialité pour tout le monde. La route est plus étroite : cela signifie une base d’utilisateurs clairement définie, mais cela signifie aussi qu’en l’absence d’adhésion des institutions financières traditionnelles, ce positionnement n’a plus de sens.#dusk

Quand j’ai atteint le chapitre 6, j’ai remarqué un choix clé : l’environnement d’exécution des smart contracts de Dusk est Piecrust, basé sur WebAssembly, et non compatible avec EVM. En 2024, ne pas choisir la compatibilité EVM est une décision qui mérite d’être expliquée.$DUSK

Le livre blanc indique que Piecrust est une implémentation de machine virtuelle WASM, écrite en Rust. Son cœur repose sur deux composants : le crate piecrust, qui gère la machine virtuelle elle-même ; et piecrust-uplink, une boîte à outils de développement qui fournit la chaîne d’outils pour compiler, déployer et tester des contrats. Le livre blanc souligne que ses objectifs de conception sont la compacité, la sécurité, la modularité et la légèreté.

Mais ce qui m’a vraiment intéressé, c’est la conception des host functions. Dusk@Dusk déplace des tâches lourdes—comme la vérification de preuves ZK, la vérification de signatures et le calcul de hachés—hors de la machine virtuelle, vers l’environnement hôte. Le livre blanc liste des host functions spécifiques : la fonction hash prend en charge deux algorithmes de hachage, Blake2b et Poseidon ; verify_plonk et verify_groth16_bn254 vérifient respectivement deux types de preuves ZK, PlonK et Groth16 ; verify_schnorr et verify_bls vérifient des signatures, prenant en charge à la fois les signatures simples et les signatures multiples. Tout cela s’exécute dans l’environnement natif, et non dans un bac à sable WASM.#dusk

Pourquoi faire ça ? Le livre blanc cite des données de recherche : exécuter des applications complexes dans WASM serait 45 % à 255 % plus lent que dans du code natif. Pour une chaîne qui utilise massivement des preuves ZK, cet écart de performance est critique. Si chaque transaction doit vérifier une preuve PlonK dans WASM, rien que ce coût rendrait les délais de transaction inacceptables. Déplacer la vérification dans l’environnement hôte revient à contourner l’obstacle.

Mais une telle approche a aussi un coût pour Dusk. L’absence de compatibilité EVM signifie que les smart contracts existants sur Ethereum ne peuvent pas être migrés directement vers Dusk ; les développeurs doivent réapprendre la chaîne d’outils de développement sur WASM. La compatibilité EVM est un atout de sécurité dans l’industrie, car il existe déjà un grand nombre de développeurs, d’outils et de bases de code. En renonçant à cet atout, Dusk montre qu’il a un positionnement clair pour ses utilisateurs cibles—les développeurs institutionnels du secteur des titres et des actifs du monde réel.

Le toolkit fourni par Piecrust-uplink, y compris la compilation des contrats en modules WASM, l’exécution dans un environnement contrôlé, ainsi que la vérification de la justesse et de la sécurité, semble compenser les limites de l’expérience développeur. Mais si la chaîne d’outils est réellement facile à utiliser, le livre blanc ne peut pas répondre : cela ne peut être jugé qu’après que les développeurs l’auront réellement utilisée.

我读到第5节的时候，发现Dusk在能源效率上做了很多功课，而且给了具体数据，这让我觉得他们确实认真考虑过这个问题。

先看共识层面。白皮书引用了以太坊转PoS后的数据，能耗降低了99.95%以上。但SA共识不只是PoS，它还是委员会制的PoS。白皮书说，确定性分配让区块生成和验证都不需要密集计算，因为谁干活是提前选好的，不是靠算力竞争。委员会只由被选中的那组provisioner参与，而不是全网一起验证，所以整体计算量更小。$DUSK

网络层面，Kadcast的数据更有意思。白皮书说，相比Gossip协议，Kadcast能减少25%到50%的带宽消耗。这不是猜的，是引用了研究数据。而且Kadcast还能降低10%到30%的孤儿块率——就是那些被广播出去但最终没被接受的块。在PoS网络里，少一个孤儿块，就意味着少了一轮白费的投票和验证工作。

加密操作层面，Dusk把ZK证明验证、签名验证、哈希计算这些重活从WASM虚拟机里搬到了宿主环境，用host functions来跑。白皮书引用了研究数据，说在WASM里执行复杂应用比原生代码慢45%到255%。把这个额外开销省掉，对一条大量使用ZK证明的链来说，省下来的计算量是相当可观的。#dusk

不过白皮书也诚实地说，这些能耗节省的具体数字还没有被量化。Kadcast的带宽节省数据来自其他网络，不是Dusk主网实测。这让我觉得他们写白皮书的时候，态度是严谨的，没有为了好看而编数据。

但反过来想，如果Dusk@Dusk 的SA共识真的把验证者数量降到很小的规模，那能耗确实会比以太坊的PoS还要低。以太坊PoS虽然不挖矿了，但全网有几十万验证者，每个人都要跑全节点验证。如果Dusk的验证工作由小规模的委员会来做，那单次验证的能耗确实会少很多。这个逻辑在理论上是成立的，但实际效果，还得等主网上线后拿数据说话。

Quand j’ai lu le livre blanc sur le protocole Zedger, j’ai eu le sentiment de « enfin, ça arrive ». Après autant de préliminaires — de la confidentialité à la conformité, en passant par le modèle de double transaction — Zedger en est l’aboutissement, le point culminant de toutes ces idées techniques.$DUSK

Le livre blanc dit que Zedger est un protocole destiné à gérer les titres et des actifs du monde réel, permettant de frapper et de détruire des jetons, ainsi que d’exécuter des actions sur société comme le versement de dividendes, voire de prendre en charge des transferts forcés. Ces fonctionnalités montrent clairement que son public cible n’est pas le grand public, mais plutôt les institutions qui émettent des titres.

Je me suis particulièrement attardé sur la fonctionnalité de « transfert forcé ». Sur Ethereum, tes actifs t’appartiennent et personne ne peut y toucher. Mais, dans les marchés financiers du monde réel, un tribunal peut geler des actifs, un liquidateur peut forcer un transfert, et les autorités de régulation peuvent exiger la récupération. En intégrant cette fonction, Zedger montre que sa compréhension de la conformité réglementaire ne s’arrête pas aux slogans : elle est vraiment conçue pour les besoins des institutions.@Dusk

Mais il existe un équilibre très subtil ici. Si la fonctionnalité de transfert forcé est détournée, ce n’est plus de la conformité : c’est de la centralisation. Le livre blanc explique que Zedger utilise des preuves ZK et des capacités d’audit pour garantir la légitimité, tout en protégeant la confidentialité des utilisateurs. Je comprends que, à chaque transfert forcé, une preuve cryptographique de conformité doit être fournie, prouvant que l’opération est légale, sans pour autant révéler les détails de la transaction.

Cependant, la description du livre blanc reste assez générale : il n’explique pas en détail qui détient les droits de déclencher un transfert forcé, comment ces droits sont distribués, ni comment prévenir les abus. Si les droits sont détenus unilatéralement par l’émetteur, alors ce système est essentiellement centralisé. Si, au contraire, les droits doivent être activés via une gouvernance on-chain ou un multi-signature, la sécurité et le niveau de décentralisation seraient bien plus élevés.

Je penche donc à croire que l’approche de conception de Zedger est juste : elle fournit un cadre technique clair pour la RWA et les titres. Mais sa décentralisation réelle dépend de la manière précise dont le contrôle des droits est mis en œuvre. Le livre blanc laisse ici une marge pour des questions qui valent le coup d’être approfondies.#dusk

Quand j’ai lu cette partie de la recommandation SA, ma première réaction a été d’aller chercher le paramètre de temps de finalité. Le livre blanc dit « la finalité est obtenue en quelques secondes », mais il ne précise pas exactement combien de secondes. Cette imprécision me met un peu mal à l’aise, mais elle m’a aussi donné encore plus envie de comprendre la logique qui se cache derrière.

D’abord, faisons une comparaison. La finalité de Bitcoin $DUSK repose sur la probabilité : avec environ 6 confirmations de blocs, il faut à peu près 1 heure. Plus vous attendez longtemps, plus vous êtes certain que la transaction ne sera pas réversible. Sur Ethereum, la finalité PoS s’appuie sur le protocole Casper : elle nécessite deux epochs, soit environ 12,8 minutes. Dusk affirme que c’est en seulement quelques secondes ; mais pourquoi ?

L’élément clé réside dans son mécanisme de répartition déterministe. Le livre blanc indique qu’avant le début de chaque tour, l’algorithme DS a déjà sélectionné à l’avance qui sera le producteur de blocs et qui fera partie du comité de vote. Ce « savoir à l’avance » signifie que les électeurs sont prêts avant même que le bloc soit généré : pas besoin d’amener des participants à la dernière minute, ni de diffuser des messages à l’échelle du réseau pour trouver un consensus. Les coûts de communication sont donc fortement réduits.

J’ai décomposé son processus. Chaque tour comprend plusieurs itérations, et chaque itération comporte trois phases : proposition, vote et confirmation. Le comité de vote ne se compose que des validateurs sélectionnés, pas de l’ensemble du réseau. Le nombre de nœuds participant au vote est limité à une plage relativement restreinte, de sorte que le volume de communication pendant le vote est faible : quelques échanges d’informations suffisent pour compléter @Dusk .

Mais il y a un point que je n’arrive pas à clarifier. Le livre blanc mentionne le terme « finalité glissante », mais sans en détailler le mécanisme. D’après ma compréhension, cela pourrait signifier que la finalité n’est pas verrouillée une seule fois : au contraire, à mesure que de nouveaux blocs sont générés, la probabilité de finalité du bloc précédent augmente progressivement. Si c’est le cas, alors « quelques secondes » ferait référence à la confirmation de première couche, et non à une finalité définitivement irréversible. #dusk

De plus, j’ai remarqué que le livre blanc ne fournit pas de nombre précis de secondes. « 3 secondes » et « 9 secondes » sont tous deux qualifiés de « quelques secondes », mais dans un contexte financier, la différence est énorme. Pour l’instant, je n’ai pas trouvé de réponse à cette question dans le livre blanc ; il faudra peut-être attendre les données de tests réelles après le lancement du mainnet.

Quand je lisais le livre blanc, cette question me tournait sans cesse dans la tête. Le plus grand récit de Dusk, c’est : je veux à la fois la confidentialité et la conformité, et l’expérience historique m’apprend que ce genre de promesse finit généralement par mécontenter tout le monde.#dusk

Regardons d’abord les mauvais exemples. Zcash et Monero ont poussé la confidentialité à l’extrême, mais les autorités de régulation n’ont pas accepté, les exchanges les ont retirés, et la liquidité a décliné. Ethereum et Bitcoin ne posent aucun problème du point de vue de la conformité, mais toutes les transactions sont transparentes : quand une institution effectue une grosse opération, le contrepartiste voit tout clairement. Dusk dit avoir trouvé une troisième voie, et au début, j’étais sceptique.@Dusk

La solution proposée dans le livre blanc repose sur un modèle de double transaction et le protocole Zedger. Moonlight est prévu pour les scénarios de conformité, Phoenix pour les scénarios de confidentialité, et Zedger permet d’exécuter des contrats intelligents dans un état confidentiel tout en conservant la capacité d’être auditable. En théorie, cette architecture pourrait fonctionner.

Mais en le terminant, je découvre une faille essentielle. Le livre blanc dit que les autorités de régulation peuvent accéder aux données nécessaires, mais il n’explique pas comment, par quel mécanisme l’autorisation est accordée, qui héberge les clés, ni comment révoquer les droits d’accès. Dans un système de confidentialité qui se veut auditable, la difficulté ne consiste pas tant à permettre aux régulateurs de voir les données, que de garantir que seules les bonnes personnes voient les bonnes données — et uniquement pendant la période autorisée.

J’ai essayé d’en déduire la logique de cette manière. Si Dusk utilise un système de preuves du type zk-SNARK, que les autorités conservent une clé d’audit spécifique,$DUSK pourrait alors vérifier la conformité des transactions sans exposer la confidentialité des utilisateurs. Dans ce cas, le schéma tient. Mais si les pouvoirs de régulation sont abusés, ou si la clé fuit, alors tout l’édifice de la protection de la vie privée s’effondre.

Donc ma conclusion est la suivante : la coexistence de la confidentialité et de la conformité est compréhensible en théorie et, sur le plan technique, potentiellement réalisable, mais l’effet réel dépend entièrement des détails de la conception des mécanismes de contrôle des permissions. Or, pour l’instant, le livre blanc ne fournit pas ces détails : je dois donc attendre la publication de davantage de documents techniques avant de pouvoir juger. La réponse à cette question n’est pas dans le livre blanc, elle se trouve dans le code du réseau principal.

Quand je lis cette partie sur Kadcast, je ne cesse de comparer avec le protocole de gossip d’Ethereum. La logique du gossip est très simple : vous recevez un message, vous le relayer à tous les voisins que vous connaissez, et ces voisins le relaient à leur tour à leurs voisins, jusqu’à ce que tout le réseau l’ait reçu. Mais il y a un problème : à mesure que le nombre de nœuds augmente, le volume de relai répété de messages augmente de façon exponentielle.

La démarche de Kadcast est différente. Elle s’appuie sur une DHT de Kademlia et regroupe les nœuds par paliers selon la distance XOR. Au lieu de relayer vers tous les voisins, chaque nœud ne relaye que vers des nœuds sélectionnés dont la distance XOR augmente progressivement. J’ai dû relire ce mécanisme deux fois pour comprendre à quel point il est ingénieux : il produit un effet de cascade, plutôt qu’une inondation.

Prenons un exemple : le nœud A émet un message. Il ne le relaye qu’à quelques nœuds les plus proches en distance, puis ces nœuds le relaient vers des nœuds plus éloignés. Le nombre de nœuds ciblés à chaque couche est maîtrisé : ce n’est pas une diffusion sans limite. Le livre blanc indique que cela réduit considérablement le nombre total de transmissions nécessaires à la propagation du message.

Alors, quel rapport ce design a-t-il avec le scénario financier $DUSK ? De mon point de vue, le scénario financier est particulièrement sensible à deux choses : la latence et la bande passante. Si une diffusion de transaction nécessite une dizaine de secondes, voire des dizaines de secondes, pour se propager à l’ensemble du réseau, alors la finalité à l’échelle de la seconde perd tout son intérêt. Kadcast arrive à atteindre tous les nœuds avec un nombre minimal de relais grâce à une structure arborescente, et comprime au maximum le temps de propagation.

Il y a aussi un point que je n’avais pas remarqué au début : le livre blanc mentionne que Kadcast brouille naturellement l’origine du message. Comme les nœuds ne communiquent qu’avec des pairs sélectionnés, et ne font pas de diffusion à l’échelle du réseau entier, il est beaucoup plus difficile pour un attaquant de retracer à partir de quel nœud une transaction a été émise. Pour le récit de confidentialité de Dusk@Dusk , c’est un atout supplémentaire.

Mais j’ai encore une question. Le livre blanc compare gossip et Kadcast, mais ne fournit qu’une description qualitative, sans données chiffrées sur les économies de bande passante. Combien exactement est économisé — 30 % ou 90 % ? Sans ces chiffres, il m’est difficile d’évaluer concrètement l’ampleur de l’avantage en efficacité. Peut-être que cet ordre de grandeur devra être confirmé après le lancement sur le réseau principal, avec des données réelles. #dusk

Ma première réaction en lisant la recommandation/consensus SA a été : comment le chiffre « 1000 DUSK » a-t-il été obtenu. Le livre blanc ne donne que le résultat, sans la démarche de déduction. Donc je suis ses paramètres et je remonte à rebours.

Il fixe un epoch à 2160 blocs. En se basant sur la vitesse actuelle de génération de blocs de Dusk, on obtient environ 6 heures par epoch. Ensuite, il donne une formule de maturité : M = 2 × epoch - (height mod epoch). Autrement dit, si vous misez une certaine somme de DUSK, vous devez attendre une grande partie d’un epoch, jusqu’à la fin d’un epoch, avant de pouvoir vraiment commencer à travailler.

Ce choix est intéressant : il aligne le moment d’activation de toutes les nouvelles mises sur la frontière des epochs. Ce n’est pas « activé dès que c’est mis », mais « activé collectivement à partir du même point de départ ». Je suppose que le but est d’avoir un instantané stable du pool de mises pour que l’algorithme DS puisse faire des tirages déterministes. Si on pouvait entrer et être activé à tout moment, l’ensemble des candidats provisioner changerait à chaque bloc, rendant l’allocation déterministe difficile à réaliser.$DUSK

Et que vaut « 1000 DUSK » en lui-même ? J’ai fait un calcul : si le seuil est fixé à 100, le nombre de provisioners exploserait. Il y aurait une concurrence plus intense entre les 64 slots à chaque epoch, mais comme la mise d’un nœud serait trop faible, la sécurité du réseau pourrait au contraire être diluée. Si on fixe le seuil à 10000, alors les particuliers n’entreraient presque pas ; les provisioners deviendraient un jeu réservé à quelques gros nœuds, et la décentralisation en pâtirait.@Dusk

Le chiffre « 1000 » tombe justement au milieu. En comparant avec d’autres paramètres de chaînes PoS que j’ai consultés, le seuil de Dusk n’est pas très bas, mais n’est pas non plus très élevé. Cela ressemble à un message : je ne veux pas que vous puissiez lancer un nœud juste avec un peu d’argent de poche, mais je ne veux pas non plus que vous deviez absolument être un gros détenteur pour participer.

Cependant, j’ai encore une question que je n’ai pas vraiment comprise. Le livre blanc ne fournit pas l’intervalle d’objectif du nombre total de provisioners, et ne dit pas non plus à quel niveau de « intensité de concurrence » les 64 slots seraient optimaux. Sans ces données, je ne peux pas vraiment juger si « 1000 » est le bon chiffre. Il est possible que sa pertinence ne puisse être validée qu’après le lancement sur le mainnet, avec des données réelles.#dusk