@Dusk
je suis allé vérifier exactement ce que signifie « custody zéro confiance » dans l’annonce dusk-cordial-npex, puisque ce terme implique généralement une architecture cryptographique spécifique, et je me suis dit que le communiqué de presse l’utilisait probablement de façon approximative pour « auto-hébergé plutôt que SaaS tiers ». je me trompais, et honnêtement j’ai presque rédigé toute cette publication autour de cette mauvaise hypothèse avant de consulter réellement les documents techniques de cordial — leur produit de trésorerie utilise bel et bien une signature par seuil MPC, Frost pour Ed25519, une couche de consensus BFT répartie sur des nœuds indépendants, des parts de clés qui ne sont jamais reconstituées à un seul endroit. c’est une vraie cryptographie de confiance distribuée, pas du marketing déguisé.
alors le fait que npex choisisse un déploiement auto-hébergé et obtienne une architecture zéro confiance authentique ne s’oppose pas vraiment à ce que j’avais supposé au départ : la proposition de cordial consiste à permettre aux institutions d’exécuter elles-mêmes cette architecture plutôt que de faire confiance à un fournisseur SaaS et à son cloud.
ce que je ne sais toujours pas, en revanche, c’est si npex exécute la configuration complète multi-nœuds BFT ou quelque chose de plus proche d’un déploiement à nœud unique, puisque la documentation de cordial mentionne les deux comme étant techniquement disponibles. ils ne sont pas également « zéro confiance » en pratique, même sur le même logiciel sous-jacent.
quelqu’un sait-il si le déploiement cordial réel de npex est à nœud unique ou une configuration de seuil véritablement multi-nœuds ? 🧐
#dusk $DUSK
je suis allé vérifier exactement ce que signifie « custody zéro confiance » dans l’annonce dusk-cordial-npex, puisque ce terme implique généralement une architecture cryptographique spécifique, et je me suis dit que le communiqué de presse l’utilisait probablement de façon approximative pour « auto-hébergé plutôt que SaaS tiers ». je me trompais, et honnêtement j’ai presque rédigé toute cette publication autour de cette mauvaise hypothèse avant de consulter réellement les documents techniques de cordial — leur produit de trésorerie utilise bel et bien une signature par seuil MPC, Frost pour Ed25519, une couche de consensus BFT répartie sur des nœuds indépendants, des parts de clés qui ne sont jamais reconstituées à un seul endroit. c’est une vraie cryptographie de confiance distribuée, pas du marketing déguisé.
alors le fait que npex choisisse un déploiement auto-hébergé et obtienne une architecture zéro confiance authentique ne s’oppose pas vraiment à ce que j’avais supposé au départ : la proposition de cordial consiste à permettre aux institutions d’exécuter elles-mêmes cette architecture plutôt que de faire confiance à un fournisseur SaaS et à son cloud.
ce que je ne sais toujours pas, en revanche, c’est si npex exécute la configuration complète multi-nœuds BFT ou quelque chose de plus proche d’un déploiement à nœud unique, puisque la documentation de cordial mentionne les deux comme étant techniquement disponibles. ils ne sont pas également « zéro confiance » en pratique, même sur le même logiciel sous-jacent.
quelqu’un sait-il si le déploiement cordial réel de npex est à nœud unique ou une configuration de seuil véritablement multi-nœuds ? 🧐
#dusk $DUSK
