Binance Square
BlockBreaker
8.2k Publications

BlockBreaker

Compte Square Vérifié+
Crypto Analyst 🧠 | Binance charts📊 | Tracking Market Moves Daily | X @Block_Breaker55
Ouvert au trading
Détenteur pour BNB
Détenteur pour BNB
Trade régulièrement
1.7 an(s)
215 Suivis
47.9K+ Abonnés
25.9K+ J’aime
Publications
Portefeuille
·
--
#termmax @termmax J’ai regardé TermMax moins comme un autre protocole de prêt et davantage comme un pari sur le fait que la DeFi peut rendre le temps négociable. Cela semble abstrait, mais ça change ma façon de voir le produit. La plupart des prêts DeFi reposent sur des taux variables. Le taux bouge, votre position bouge, et le marché revalorise en permanence le coût du capital. TermMax prend une voie différente en séparant le principal de la composante d’intérêt et en donnant aux utilisateurs un moyen d’exprimer une maturité fixe. Concrètement, cela fait que la question se pose moins en “Quel est le rendement ?” et davantage en “À combien vaut ce flux de trésorerie jusqu’à une date précise ?” Je remarque constamment que c’est là que commence la partie la plus intéressante. Un marché à taux fixe a besoin de plus que de la liquidité. Il lui faut de la liquidité au bon prix, pour la bonne maturité, avec la bonne garantie. C’est un problème beaucoup plus étroit qu’un AMM classique qui essaie d’évaluer un actif par rapport à un autre. La structure en ordres par plages de TermMax m’intéresse parce que les teneurs de marché peuvent définir l’endroit exact où ils veulent fournir de la liquidité, au lieu de rester aveuglément dans une seule courbe de tarification. Ça peut sembler subtil, mais ça pourrait compter énormément lorsque les taux et les conditions de garantie évoluent rapidement. Et puis il y a la couche des options. Je ne fais pas vraiment confiance à un marché d’options uniquement parce qu’il affiche des primes attractives. Quelqu’un finit toujours par porter l’autre côté du risque. Pour moi, la vraie question est de savoir si TermMax peut rendre ce risque suffisamment transparent pour que les apporteurs de liquidité puissent le tarifer de façon rationnelle. C’est pourquoi je surveille le protocole avec un autre regard : pas l’APY mis en avant, pas l’effet de levier, pas le nombre de produits, mais la possibilité que la maturité fixe et le risque deviennent de véritables primitives liquides dans la DeFi. Cette partie reste à prouver. Et honnêtement, c’est précisément ce qui fait que TermMax mérite d’être suivi.
#termmax @TermMax
J’ai regardé TermMax moins comme un autre protocole de prêt et davantage comme un pari sur le fait que la DeFi peut rendre le temps négociable.

Cela semble abstrait, mais ça change ma façon de voir le produit.

La plupart des prêts DeFi reposent sur des taux variables. Le taux bouge, votre position bouge, et le marché revalorise en permanence le coût du capital. TermMax prend une voie différente en séparant le principal de la composante d’intérêt et en donnant aux utilisateurs un moyen d’exprimer une maturité fixe. Concrètement, cela fait que la question se pose moins en “Quel est le rendement ?” et davantage en “À combien vaut ce flux de trésorerie jusqu’à une date précise ?”

Je remarque constamment que c’est là que commence la partie la plus intéressante.

Un marché à taux fixe a besoin de plus que de la liquidité. Il lui faut de la liquidité au bon prix, pour la bonne maturité, avec la bonne garantie. C’est un problème beaucoup plus étroit qu’un AMM classique qui essaie d’évaluer un actif par rapport à un autre.

La structure en ordres par plages de TermMax m’intéresse parce que les teneurs de marché peuvent définir l’endroit exact où ils veulent fournir de la liquidité, au lieu de rester aveuglément dans une seule courbe de tarification. Ça peut sembler subtil, mais ça pourrait compter énormément lorsque les taux et les conditions de garantie évoluent rapidement.

Et puis il y a la couche des options.

Je ne fais pas vraiment confiance à un marché d’options uniquement parce qu’il affiche des primes attractives. Quelqu’un finit toujours par porter l’autre côté du risque. Pour moi, la vraie question est de savoir si TermMax peut rendre ce risque suffisamment transparent pour que les apporteurs de liquidité puissent le tarifer de façon rationnelle.

C’est pourquoi je surveille le protocole avec un autre regard : pas l’APY mis en avant, pas l’effet de levier, pas le nombre de produits, mais la possibilité que la maturité fixe et le risque deviennent de véritables primitives liquides dans la DeFi.

Cette partie reste à prouver. Et honnêtement, c’est précisément ce qui fait que TermMax mérite d’être suivi.
#dusk $DUSK @Dusk_Foundation J’ai commencé à regarder Dusk sous un angle différent : non pas comme une « blockchain de confidentialité », mais comme un système où l’environnement d’exécution détermine concrètement à quel point la confidentialité devient exploitable. C’est pourquoi la Rusk VM a attiré mon attention. Elle utilise WASM pour l’exécution des contrats, mais ne s’arrête pas là. Dusk expose des opérations cryptographiques via la couche hôte de la VM, y compris le hachage, les opérations sur les courbes elliptiques et la vérification à preuve à divulgation nulle de connaissance. En pratique, le contrat n’a pas besoin d’implémenter lui-même chaque primitive coûteuse. Je pense que ce choix de conception est plus important qu’il n’en a l’air au premier abord. Un contrat confidentiel n’est utile que lorsque les développeurs peuvent raisonner sur ses coûts, ses entrées et ses scénarios d’échec. L’ABI de Rusk et les outils Rust créent une interface définie entre le code du contrat et ces capacités natives. J’ai déjà vu cela avec des systèmes de smart contracts : la partie intéressante est rarement le langage. C’est plutôt la frontière entre le code applicatif et les primitives de bas niveau qui se trouvent en dessous. Ce que j’observerais de très près avec Rusk, ce n’est pas un autre titre de benchmark. Je voudrais comprendre dans quelle mesure les appels hôtes restent prévisibles, comment la tarification du gas évolue, comment les changements d’ABI sont gérés, et comment les développeurs déboguent des contrats lorsque l’état lui-même est intentionnellement masqué. C’est la partie qui, à mes yeux, est réellement intéressante. La confidentialité au niveau du protocole, c’est une chose. Rendre la confidentialité programmable sans transformer le développement en un projet de recherche en cryptographie, c’est un problème beaucoup plus difficile.
#dusk $DUSK @Dusk
J’ai commencé à regarder Dusk sous un angle différent : non pas comme une « blockchain de confidentialité », mais comme un système où l’environnement d’exécution détermine concrètement à quel point la confidentialité devient exploitable.

C’est pourquoi la Rusk VM a attiré mon attention. Elle utilise WASM pour l’exécution des contrats, mais ne s’arrête pas là. Dusk expose des opérations cryptographiques via la couche hôte de la VM, y compris le hachage, les opérations sur les courbes elliptiques et la vérification à preuve à divulgation nulle de connaissance. En pratique, le contrat n’a pas besoin d’implémenter lui-même chaque primitive coûteuse.

Je pense que ce choix de conception est plus important qu’il n’en a l’air au premier abord. Un contrat confidentiel n’est utile que lorsque les développeurs peuvent raisonner sur ses coûts, ses entrées et ses scénarios d’échec. L’ABI de Rusk et les outils Rust créent une interface définie entre le code du contrat et ces capacités natives.

J’ai déjà vu cela avec des systèmes de smart contracts : la partie intéressante est rarement le langage. C’est plutôt la frontière entre le code applicatif et les primitives de bas niveau qui se trouvent en dessous.

Ce que j’observerais de très près avec Rusk, ce n’est pas un autre titre de benchmark. Je voudrais comprendre dans quelle mesure les appels hôtes restent prévisibles, comment la tarification du gas évolue, comment les changements d’ABI sont gérés, et comment les développeurs déboguent des contrats lorsque l’état lui-même est intentionnellement masqué.

C’est la partie qui, à mes yeux, est réellement intéressante. La confidentialité au niveau du protocole, c’est une chose. Rendre la confidentialité programmable sans transformer le développement en un projet de recherche en cryptographie, c’est un problème beaucoup plus difficile.
#dusk $DUSK @Dusk_Foundation PoBB : le jeu caché derrière l’élection du leader de Dusk Je trouve PoBB intéressant pour une raison qui est souvent manquée quand les gens le décrivent comme une « sélection de leader privée ». L’idée plus profonde est qu’un validateur peut concourir à la production de blocs sans annoncer les informations qui feraient de lui une cible évidente. Dans la conception de Dusk, les enchères sont engagées, et le vainqueur éventuel peut prouver la validité de l’enchère en connaissance nulle (zero knowledge), plutôt que d’exposer simplement tout le paysage des enchères. Cela change la donne. Dans un système PoS plus transparent, savoir qui est susceptible de produire le prochain bloc peut devenir une information utile. On peut observer les mises, suivre les validateurs et élaborer des stratégies autour d’une direction prévisible. PoBB tente de réduire une partie de cette visibilité. Mais je ne suis pas convaincu que la confidentialité rende automatiquement le système plus sûr. Les questions qui m’importent sont plus concrètes : que se passe-t-il quand l’enchérisseur gagnant disparaît ? Une censure répétée des preuves d’enchères peut-elle affecter la vivacité (liveness) ? Les grands opérateurs gagnent-ils un avantage grâce à la coordination ? Et le mécanisme de score peut-il résister à la manipulation sans rendre une participation honnête trop coûteuse ? J’ai déjà vu des conceptions de protocole résoudre un problème d’incitation seulement pour le déplacer vers un endroit moins évident. C’est ce qui rend PoBB digne d’étude. Son véritable test n’est pas de savoir si Dusk peut cacher l’enchère d’un validateur. Il s’agit de savoir si une blockchain peut préserver une concurrence équitable lorsque les concurrents ne peuvent pas facilement se voir les uns les autres.
#dusk $DUSK @Dusk
PoBB : le jeu caché derrière l’élection du leader de Dusk

Je trouve PoBB intéressant pour une raison qui est souvent manquée quand les gens le décrivent comme une « sélection de leader privée ».

L’idée plus profonde est qu’un validateur peut concourir à la production de blocs sans annoncer les informations qui feraient de lui une cible évidente. Dans la conception de Dusk, les enchères sont engagées, et le vainqueur éventuel peut prouver la validité de l’enchère en connaissance nulle (zero knowledge), plutôt que d’exposer simplement tout le paysage des enchères.

Cela change la donne.

Dans un système PoS plus transparent, savoir qui est susceptible de produire le prochain bloc peut devenir une information utile. On peut observer les mises, suivre les validateurs et élaborer des stratégies autour d’une direction prévisible. PoBB tente de réduire une partie de cette visibilité.

Mais je ne suis pas convaincu que la confidentialité rende automatiquement le système plus sûr.

Les questions qui m’importent sont plus concrètes : que se passe-t-il quand l’enchérisseur gagnant disparaît ? Une censure répétée des preuves d’enchères peut-elle affecter la vivacité (liveness) ? Les grands opérateurs gagnent-ils un avantage grâce à la coordination ? Et le mécanisme de score peut-il résister à la manipulation sans rendre une participation honnête trop coûteuse ?

J’ai déjà vu des conceptions de protocole résoudre un problème d’incitation seulement pour le déplacer vers un endroit moins évident.

C’est ce qui rend PoBB digne d’étude. Son véritable test n’est pas de savoir si Dusk peut cacher l’enchère d’un validateur. Il s’agit de savoir si une blockchain peut préserver une concurrence équitable lorsque les concurrents ne peuvent pas facilement se voir les uns les autres.
#dusk $DUSK @Dusk_Foundation Le SMS de Zedger : une éventuelle confidentialité des valeurs mobilières nécessite d’abord un système comptable J’ai examiné Zedger sous un angle légèrement différent. La plupart des modèles de confidentialité se demandent comment masquer un compte ou une transaction. Les valeurs mobilières ont cependant un autre problème : la propriété n’est pas qu’un simple nombre. Elle évolue avec le temps, les droits de transfert, les droits de vote, les dividendes et le statut d’approbation. C’est pourquoi la Sparse Merkle-Segment Trie (SMST) a retenu mon attention. La SMST combine un Sparse Merkle Tree et un Segment Tree, permettant à Zedger de valider l’état du compte tout en gardant, dans la structure, différentes catégories de soldes. La conception peut suivre les soldes maximaux, transférables, ouvrant droit au vote et aux dividendes, sans exposer toute l’historique du compte au public. J’ai vu d’autres modèles de comptes privés, comme BlockMaze, qui se concentrent fortement sur le masquage des soldes et des relations expéditeur-destinataire avec des zk-SNARKs. C’est utile pour des paiements privés, mais les valeurs mobilières d’entreprise posent un problème de données différent. Vous devez souvent prouver qu’un transfert est autorisé, et pas seulement prouver que la valeur a bougé. C’est ici que Zedger me paraît plus délibéré. Son arbre de liste blanche et sa structure de mémoire de compte sont liés à la machine à états, de sorte que la conformité n’est pas un tableau de bord externe qui vérifie les transactions après coup. Je reste toutefois prudent face à la complexité. Chaque champ d’état supplémentaire et chaque règle de preuve ajoutent une charge d’ingénierie et de vérification. Mais la question intéressante n’est pas de savoir si la SMST cache les soldes. C’est de savoir si un modèle de compte cryptographique peut préserver les réalités souvent complexes de la propriété des valeurs mobilières sans transformer le grand livre en une base publique de détenteurs d’actions.
#dusk $DUSK @Dusk
Le SMS de Zedger : une éventuelle confidentialité des valeurs mobilières nécessite d’abord un système comptable

J’ai examiné Zedger sous un angle légèrement différent. La plupart des modèles de confidentialité se demandent comment masquer un compte ou une transaction. Les valeurs mobilières ont cependant un autre problème : la propriété n’est pas qu’un simple nombre. Elle évolue avec le temps, les droits de transfert, les droits de vote, les dividendes et le statut d’approbation.

C’est pourquoi la Sparse Merkle-Segment Trie (SMST) a retenu mon attention. La SMST combine un Sparse Merkle Tree et un Segment Tree, permettant à Zedger de valider l’état du compte tout en gardant, dans la structure, différentes catégories de soldes. La conception peut suivre les soldes maximaux, transférables, ouvrant droit au vote et aux dividendes, sans exposer toute l’historique du compte au public.

J’ai vu d’autres modèles de comptes privés, comme BlockMaze, qui se concentrent fortement sur le masquage des soldes et des relations expéditeur-destinataire avec des zk-SNARKs. C’est utile pour des paiements privés, mais les valeurs mobilières d’entreprise posent un problème de données différent. Vous devez souvent prouver qu’un transfert est autorisé, et pas seulement prouver que la valeur a bougé.

C’est ici que Zedger me paraît plus délibéré. Son arbre de liste blanche et sa structure de mémoire de compte sont liés à la machine à états, de sorte que la conformité n’est pas un tableau de bord externe qui vérifie les transactions après coup.

Je reste toutefois prudent face à la complexité. Chaque champ d’état supplémentaire et chaque règle de preuve ajoutent une charge d’ingénierie et de vérification.

Mais la question intéressante n’est pas de savoir si la SMST cache les soldes. C’est de savoir si un modèle de compte cryptographique peut préserver les réalités souvent complexes de la propriété des valeurs mobilières sans transformer le grand livre en une base publique de détenteurs d’actions.
#dusk $DUSK @Dusk_Foundation Phoenix m’a fait voir Dusk sous un angle différent. Je pense que les systèmes de confidentialité sont souvent évalués à l’envers. Les gens se demandent si une transaction peut dissimuler son expéditeur, son montant et sa destination. Pour ma part, je préférerais me demander ce que fait réellement le système sous cette couche de confidentialité, et ce qui se passe quand l’utilisation réelle commence à s’accumuler. Phoenix utilise un modèle de type UTXO où DUSK existe sous forme de notes privées. Une dépense publie un nullifiant pour prouver que la note a déjà été consommée, sans exposer laquelle. Cette séparation est importante car l’ensemble de confidentialité peut grandir grâce à l’historique des notes, plutôt que de dépendre d’une poignée de leurres sélectionnés au moment de la dépense. C’est là que je trouve la conception plus intéressante que le pitch habituel du type « Dusk est privé ». La question plus difficile, c’est l’efficacité. Phoenix utilise des preuves à connaissance zéro pour relier l’ensemble, et cela crée un profil d’ingénierie très différent de celui de systèmes comme Monero, qui s’appuie sur des signatures en anneau plus Bulletproofs+, ou Zcash, dont la conception Orchard plus récente utilise Halo 2. Je ne suis pas convaincu que le gagnant soit celui qui dispose de la cryptographie la plus solide sur le papier. Je veux connaître le coût de cette confidentialité : taille des preuves, temps de génération des preuves, temps de vérification, et la manière dont ces métriques évoluent à mesure que l’ensemble de notes grandit. Parce que la confidentialité qui fonctionne à merveille dans un prototype, c’est une chose. La confidentialité qui reste exploitable quand la chaîne transporte des années de transactions, c’est un test bien plus intéressant.
#dusk $DUSK @Dusk
Phoenix m’a fait voir Dusk sous un angle différent.

Je pense que les systèmes de confidentialité sont souvent évalués à l’envers. Les gens se demandent si une transaction peut dissimuler son expéditeur, son montant et sa destination. Pour ma part, je préférerais me demander ce que fait réellement le système sous cette couche de confidentialité, et ce qui se passe quand l’utilisation réelle commence à s’accumuler.

Phoenix utilise un modèle de type UTXO où DUSK existe sous forme de notes privées. Une dépense publie un nullifiant pour prouver que la note a déjà été consommée, sans exposer laquelle. Cette séparation est importante car l’ensemble de confidentialité peut grandir grâce à l’historique des notes, plutôt que de dépendre d’une poignée de leurres sélectionnés au moment de la dépense.

C’est là que je trouve la conception plus intéressante que le pitch habituel du type « Dusk est privé ».

La question plus difficile, c’est l’efficacité.

Phoenix utilise des preuves à connaissance zéro pour relier l’ensemble, et cela crée un profil d’ingénierie très différent de celui de systèmes comme Monero, qui s’appuie sur des signatures en anneau plus Bulletproofs+, ou Zcash, dont la conception Orchard plus récente utilise Halo 2.

Je ne suis pas convaincu que le gagnant soit celui qui dispose de la cryptographie la plus solide sur le papier.

Je veux connaître le coût de cette confidentialité : taille des preuves, temps de génération des preuves, temps de vérification, et la manière dont ces métriques évoluent à mesure que l’ensemble de notes grandit.

Parce que la confidentialité qui fonctionne à merveille dans un prototype, c’est une chose. La confidentialité qui reste exploitable quand la chaîne transporte des années de transactions, c’est un test bien plus intéressant.
#dusk $DUSK @Dusk_Foundation Norme XSC et arbitrage entre confidentialité et conformité Je reviens sans cesse à une question inconfortable à propos de XSC : peut-on rendre une transaction financière privée sans rendre la logique de conformité sous-jacente trop rigide ? La partie intéressante du design de Dusk n’est pas seulement que des preuves à divulgation nulle de connaissance peuvent masquer les détails de la transaction. XSC est conçu autour de la démonstration que certaines conditions sont satisfaites sans exposer tout ce qui se trouve derrière la preuve. Sa spécification décrit des types de preuves pour des éléments comme l’inclusion dans un ensemble, la connaissance, l’égalité, les contrôles de plage et l’autorisation, tandis que le contrat lui-même définit les règles que le portefeuille doit appliquer. Cela semble propre jusqu’à ce que l’on regarde le volet juridique. La réglementation est rarement une affirmation booléenne nette. « Cet investisseur est-il éligible ? » peut se transformer en questions de juridiction, d’évolution du statut, d’exemptions, d’obligations de déclaration et de savoir qui est autorisé à vérifier quoi. J’ai vu des systèmes de confidentialité traités comme si la cryptographie résolvait à elle seule le problème de conformité. Ce n’est pas le cas. Une preuve à divulgation nulle de connaissance peut prouver une affirmation ; elle ne peut pas décider si l’affirmation correspond à l’intention du régulateur. La recherche sur la conformité blockchain fait la même distinction : des preuves préservant la confidentialité peuvent réduire les divulgations inutiles, mais les règles de gouvernance, d’autorisation et de divulgation restent déterminantes. C’est pourquoi je trouve XSC plus intéressant comme problème de conception qu’en tant qu’histoire de produit. Le vrai test est de savoir si la finance réglementée peut être exprimée sous forme de prédicats précis et exécutoires, sans transformer discrètement la confidentialité en une couche de permission supplémentaire. C’est dans cet arbitrage que commence le travail sérieux.
#dusk $DUSK @Dusk
Norme XSC et arbitrage entre confidentialité et conformité

Je reviens sans cesse à une question inconfortable à propos de XSC : peut-on rendre une transaction financière privée sans rendre la logique de conformité sous-jacente trop rigide ?

La partie intéressante du design de Dusk n’est pas seulement que des preuves à divulgation nulle de connaissance peuvent masquer les détails de la transaction. XSC est conçu autour de la démonstration que certaines conditions sont satisfaites sans exposer tout ce qui se trouve derrière la preuve. Sa spécification décrit des types de preuves pour des éléments comme l’inclusion dans un ensemble, la connaissance, l’égalité, les contrôles de plage et l’autorisation, tandis que le contrat lui-même définit les règles que le portefeuille doit appliquer.

Cela semble propre jusqu’à ce que l’on regarde le volet juridique. La réglementation est rarement une affirmation booléenne nette. « Cet investisseur est-il éligible ? » peut se transformer en questions de juridiction, d’évolution du statut, d’exemptions, d’obligations de déclaration et de savoir qui est autorisé à vérifier quoi.

J’ai vu des systèmes de confidentialité traités comme si la cryptographie résolvait à elle seule le problème de conformité. Ce n’est pas le cas. Une preuve à divulgation nulle de connaissance peut prouver une affirmation ; elle ne peut pas décider si l’affirmation correspond à l’intention du régulateur. La recherche sur la conformité blockchain fait la même distinction : des preuves préservant la confidentialité peuvent réduire les divulgations inutiles, mais les règles de gouvernance, d’autorisation et de divulgation restent déterminantes.

C’est pourquoi je trouve XSC plus intéressant comme problème de conception qu’en tant qu’histoire de produit. Le vrai test est de savoir si la finance réglementée peut être exprimée sous forme de prédicats précis et exécutoires, sans transformer discrètement la confidentialité en une couche de permission supplémentaire.

C’est dans cet arbitrage que commence le travail sérieux.
L’or grimpe au-dessus de 4 400 $ : plus haut en deux mois L’or a franchi 4 400 dollars l’once, atteignant son plus haut niveau en plus de deux mois. Les prix spot ont brièvement touché environ 4 435 dollars. Cette hausse intervient alors que les traders réévaluent les perspectives de taux aux États-Unis après des données sur l’emploi plus faibles, tandis que l’attention se tourne désormais vers les principaux chiffres de l’inflation américaine pour obtenir des indices sur la prochaine décision de la Fed. Pour l’or, la question clé est de savoir si les acheteurs pourront maintenir l’élan au-dessus de 4 400 $ — ou si la hausse des prix du pétrole, les rendements et le regain d’attentes de relèvement des taux déclenchent un nouveau repli. $RAD $BANANAS31 $MITO
L’or grimpe au-dessus de 4 400 $ : plus haut en deux mois

L’or a franchi 4 400 dollars l’once, atteignant son plus haut niveau en plus de deux mois. Les prix spot ont brièvement touché environ 4 435 dollars.

Cette hausse intervient alors que les traders réévaluent les perspectives de taux aux États-Unis après des données sur l’emploi plus faibles, tandis que l’attention se tourne désormais vers les principaux chiffres de l’inflation américaine pour obtenir des indices sur la prochaine décision de la Fed.

Pour l’or, la question clé est de savoir si les acheteurs pourront maintenir l’élan au-dessus de 4 400 $ — ou si la hausse des prix du pétrole, les rendements et le regain d’attentes de relèvement des taux déclenchent un nouveau repli.
$RAD $BANANAS31 $MITO
SpaceX vient de publier ses premiers résultats financiers publics, et les chiffres sont solides : le chiffre d’affaires a bondi de 92 % pour atteindre 7,8 Md$ et a dépassé les estimations. Désormais, le marché surveille deux points de près : le verrouillage des actions et la hausse des coûts liés à l’IA. $HEI $BICO $BANK
SpaceX vient de publier ses premiers résultats financiers publics, et les chiffres sont solides : le chiffre d’affaires a bondi de 92 % pour atteindre 7,8 Md$ et a dépassé les estimations. Désormais, le marché surveille deux points de près : le verrouillage des actions et la hausse des coûts liés à l’IA.
$HEI $BICO $BANK
🎙️ Maintenir l’équilibre écologique, construire la place Binance
cover
Fin
04 h 12 min 03 sec
9.7k
35
89
🎙️ Construisons ensemble le BNB Build
avatar
Fin
02 h 16 min 29 sec
15.6k
41
52
#baby $BABY @babylonlabs_io J'ai réfléchi à Babylone sous l’angle de l’expérience utilisateur, et je reviens sans cesse à une idée : le Bitcoin n’est pas difficile à cause de la cryptographie. Il est difficile parce que chaque étape de signature supplémentaire amène les gens à se demander s’ils sont sur le point de commettre une erreur irréversible. Babylone demande aux utilisateurs de rester aux commandes de leur BTC lorsqu’ils interagissent avec des timelocks, des transactions de staking, des étapes d’enregistrement et la compatibilité des portefeuilles. Aucune de ces composantes n’est, en soi, un défaut, mais, ensemble, elles augmentent le coût mental de la participation. Ce qui m’intéresse le plus n’est pas le modèle de staking. C’est l’interface entre le protocole et la personne qui détient les clés. Les projets qui gagneront ne seront pas nécessairement ceux qui disposent des scripts les plus intelligents. Ce seront ceux qui dissimulent la complexité sans en cacher la propriété. Pour moi, c’est là le véritable étalon. Si j’ai besoin de comprendre les rouages internes de Bitcoin avant de me sentir à l’aise pour faire du staking, alors l’expérience utilisateur doit encore évoluer. L’auto-conservation doit inspirer de la confiance, pas l’hésitation.
#baby $BABY @BabylonLabs_io
J'ai réfléchi à Babylone sous l’angle de l’expérience utilisateur, et je reviens sans cesse à une idée : le Bitcoin n’est pas difficile à cause de la cryptographie. Il est difficile parce que chaque étape de signature supplémentaire amène les gens à se demander s’ils sont sur le point de commettre une erreur irréversible.

Babylone demande aux utilisateurs de rester aux commandes de leur BTC lorsqu’ils interagissent avec des timelocks, des transactions de staking, des étapes d’enregistrement et la compatibilité des portefeuilles. Aucune de ces composantes n’est, en soi, un défaut, mais, ensemble, elles augmentent le coût mental de la participation.

Ce qui m’intéresse le plus n’est pas le modèle de staking. C’est l’interface entre le protocole et la personne qui détient les clés.

Les projets qui gagneront ne seront pas nécessairement ceux qui disposent des scripts les plus intelligents. Ce seront ceux qui dissimulent la complexité sans en cacher la propriété.

Pour moi, c’est là le véritable étalon. Si j’ai besoin de comprendre les rouages internes de Bitcoin avant de me sentir à l’aise pour faire du staking, alors l’expérience utilisateur doit encore évoluer. L’auto-conservation doit inspirer de la confiance, pas l’hésitation.
🎙️ 3 conseils importants pour les débutants : apprenez d’abord, commencez petit, et accordez une grande importance au risk management ; les explications en langage simple dans la salle de diffusion sont en cours 🎤
avatar
Fin
03 h 23 min 28 sec
9.7k
31
78
🎙️ Partage de connaissances sur la Web3 on-chain, et comment participer correctement au marché des contrats au comptant
avatar
Fin
03 h 56 min 21 sec
16.5k
68
82
#baby $BABY @babylonlabs_io Une chose à laquelle je reviens toujours avec Babylon, c’est que la confidentialité n’est pas une réponse simple par oui ou par non. Votre BTC ne quitte jamais votre contrôle, et Taproot fait un bon travail en masquant le script de mise. Mais l’empreinte sur la chaîne est toujours là. Avec le temps, le calendrier des mises, les schémas des UTXO et l’activité d’enregistrement peuvent révéler plus que ce que beaucoup de gens s’attendent à voir — y compris des indices sur le fournisseur de finalité derrière une mise. Le script reste caché. Le comportement ne l’est pas.
#baby $BABY @BabylonLabs_io
Une chose à laquelle je reviens toujours avec Babylon, c’est que la confidentialité n’est pas une réponse simple par oui ou par non.

Votre BTC ne quitte jamais votre contrôle, et Taproot fait un bon travail en masquant le script de mise. Mais l’empreinte sur la chaîne est toujours là. Avec le temps, le calendrier des mises, les schémas des UTXO et l’activité d’enregistrement peuvent révéler plus que ce que beaucoup de gens s’attendent à voir — y compris des indices sur le fournisseur de finalité derrière une mise.

Le script reste caché. Le comportement ne l’est pas.
#baby $BABY @babylonlabs_io Je remarque sans cesse que les gens traitent l’interopérabilité de Babylon comme si elle résolvait le même problème sur chaque chaîne. Je ne pense pas que ce soit le cas. Au sein de l’écosystème Cosmos, la conception paraît claire. Un relayer IBC déplace des checkpoints vers Babylon, et les validateurs de Babylon les vérifient et votent. Le modèle de sécurité reste relativement cohérent parce que les chaînes parlent déjà un langage similaire. En dehors de Cosmos, le tableau change. J’ai déjà vu cela avec l’infrastructure inter-chaînes. Dès que vous passez à différents environnements d’exécution, « l’interopérabilité » devient un problème d’ingénierie de preuve. Chaque nouvel écosystème a besoin de sa propre manière de vérifier une sécurité adossée à Bitcoin, au lieu de s’intégrer à une norme universelle. C’est pourquoi je pense que le plus grand défi de Babylon n’est pas d’ajouter davantage de chaînes. Il s’agit de faire en sorte que le modèle de sécurité paraisse également « natif » partout, sans créer une histoire de confiance différente pour chaque intégration.
#baby $BABY @BabylonLabs_io
Je remarque sans cesse que les gens traitent l’interopérabilité de Babylon comme si elle résolvait le même problème sur chaque chaîne.

Je ne pense pas que ce soit le cas.

Au sein de l’écosystème Cosmos, la conception paraît claire. Un relayer IBC déplace des checkpoints vers Babylon, et les validateurs de Babylon les vérifient et votent. Le modèle de sécurité reste relativement cohérent parce que les chaînes parlent déjà un langage similaire.

En dehors de Cosmos, le tableau change.

J’ai déjà vu cela avec l’infrastructure inter-chaînes. Dès que vous passez à différents environnements d’exécution, « l’interopérabilité » devient un problème d’ingénierie de preuve. Chaque nouvel écosystème a besoin de sa propre manière de vérifier une sécurité adossée à Bitcoin, au lieu de s’intégrer à une norme universelle.

C’est pourquoi je pense que le plus grand défi de Babylon n’est pas d’ajouter davantage de chaînes.

Il s’agit de faire en sorte que le modèle de sécurité paraisse également « natif » partout, sans créer une histoire de confiance différente pour chaque intégration.
#baby $BABY @babylonlabs_io Ce qui m’intéresse le plus dans Babylon, c’est qu’il n’essaie pas de rendre un mauvais comportement impossible. Il essaie de rendre impossible de le cacher. C’est une grande différence. Si un fournisseur de finalité signe deux messages contradictoires avec la même clé EOTS, l’erreur révèle elle-même la clé. Donc la preuve n’est pas quelque chose qu’on ajoute plus tard. La preuve, c’est l’erreur. J’ai vu beaucoup de discussions en matière de sécurité crypto au sujet de la punition, mais ici, cela semble plus direct. C’est presque comme si le système disait : « Si vous trichez, vous vous dévoilez. » Pour moi, c’est plus clair qu’un dispositif qui nécessite, ensuite, une longue argumentation. Le design « 3f+1 » raconte aussi une histoire claire. Babylon s’attend à ce que certains validateurs échouent. Il ne veut simplement pas que des détenteurs honnêtes de BTC paient pour cet échec. Cette partie compte énormément pour moi, car beaucoup de systèmes disent qu’ils protègent les utilisateurs, tout en laissant une marge permettant à des personnes innocentes d’être blessées quand les choses tournent mal. Donc ma conclusion est simple. Le modèle de slashing de Babylon n’est pas vraiment une question de drame ou de peur. Il s’agit de faire en sorte que la malhonnêteté laisse une trace qu’on ne peut pas ignorer.
#baby $BABY @BabylonLabs_io
Ce qui m’intéresse le plus dans Babylon, c’est qu’il n’essaie pas de rendre un mauvais comportement impossible. Il essaie de rendre impossible de le cacher.

C’est une grande différence. Si un fournisseur de finalité signe deux messages contradictoires avec la même clé EOTS, l’erreur révèle elle-même la clé. Donc la preuve n’est pas quelque chose qu’on ajoute plus tard. La preuve, c’est l’erreur.

J’ai vu beaucoup de discussions en matière de sécurité crypto au sujet de la punition, mais ici, cela semble plus direct. C’est presque comme si le système disait : « Si vous trichez, vous vous dévoilez. » Pour moi, c’est plus clair qu’un dispositif qui nécessite, ensuite, une longue argumentation.

Le design « 3f+1 » raconte aussi une histoire claire. Babylon s’attend à ce que certains validateurs échouent. Il ne veut simplement pas que des détenteurs honnêtes de BTC paient pour cet échec. Cette partie compte énormément pour moi, car beaucoup de systèmes disent qu’ils protègent les utilisateurs, tout en laissant une marge permettant à des personnes innocentes d’être blessées quand les choses tournent mal.

Donc ma conclusion est simple. Le modèle de slashing de Babylon n’est pas vraiment une question de drame ou de peur. Il s’agit de faire en sorte que la malhonnêteté laisse une trace qu’on ne peut pas ignorer.
·
--
Haussier
#baby $BABY @babylonlabs_io J’ai remarqué que la plupart des discussions autour de Babylon se concentrent sur le déblocage rapide (unbonding). Je pense que la question la plus intéressante est plutôt : qu’est-ce qui rend « rapide » crédible, au premier lieu. La réponse n’est pas la vitesse. C’est la discipline des timestamps. Chaque checkpoint Bitcoin est, en pratique, une preuve publique indiquant : « voici l’historique auquel nous nous engageons ». Si ces preuves sont suffisamment fréquentes, les validateurs n’ont pas besoin d’attendre de longues périodes de retrait, car l’historique a déjà été ancré. Si elles sont trop espacées, le temps d’attente supplémentaire revient silencieusement par une autre porte. C’est pourquoi je ne considère pas la fréquence des timestamps comme un paramètre opérationnel. Je la vois comme un budget de sécurité. Publier trop souvent et les frais Bitcoin deviennent une partie de votre coût de sécurité. Publier trop rarement et vos garanties de finalité commencent à dépendre d’hypothèses qui se trouvent en dehors de Bitcoin. Pour moi, Babylon n’essaie pas d’éliminer les compromis. Il les déplace en un seul endroit où chacun peut les mesurer : le calendrier des checkpoints.
#baby $BABY @BabylonLabs_io
J’ai remarqué que la plupart des discussions autour de Babylon se concentrent sur le déblocage rapide (unbonding). Je pense que la question la plus intéressante est plutôt : qu’est-ce qui rend « rapide » crédible, au premier lieu.

La réponse n’est pas la vitesse. C’est la discipline des timestamps.

Chaque checkpoint Bitcoin est, en pratique, une preuve publique indiquant : « voici l’historique auquel nous nous engageons ». Si ces preuves sont suffisamment fréquentes, les validateurs n’ont pas besoin d’attendre de longues périodes de retrait, car l’historique a déjà été ancré. Si elles sont trop espacées, le temps d’attente supplémentaire revient silencieusement par une autre porte.

C’est pourquoi je ne considère pas la fréquence des timestamps comme un paramètre opérationnel. Je la vois comme un budget de sécurité. Publier trop souvent et les frais Bitcoin deviennent une partie de votre coût de sécurité. Publier trop rarement et vos garanties de finalité commencent à dépendre d’hypothèses qui se trouvent en dehors de Bitcoin.

Pour moi, Babylon n’essaie pas d’éliminer les compromis. Il les déplace en un seul endroit où chacun peut les mesurer : le calendrier des checkpoints.
🎙️ Maintenir l’équilibre écologique et construire la place Binance
avatar
Fin
04 h 55 min 08 sec
16.6k
32
85
🎙️ Le marché va-t-il monter ou baisser ? Store bnb together
avatar
Fin
02 h 15 min 44 sec
23.7k
18
12
nLIGHT (NASDAQ : LASR) a grimpé d’environ 5,8 %, se démarquant dans le cadre d’une plus large vague de ventes sur les valeurs technologiques. Le mouvement a suivi une annonce concernant un important contrat de défense américain pour un système de laser à haute énergie. La première attribution s’élève à 44 millions de dollars, le programme total pouvant potentiellement atteindre 627 millions de dollars. Alors que les actions des semi-conducteurs et de l’IA subissaient des pressions, les investisseurs semblaient davantage se concentrer sur le rôle croissant de nLIGHT dans la technologie de défense et les systèmes à énergie dirigée. #LASR #nLIGHT #DefenseTechnology #stockssignal $LAB
nLIGHT (NASDAQ : LASR) a grimpé d’environ 5,8 %, se démarquant dans le cadre d’une plus large vague de ventes sur les valeurs technologiques.

Le mouvement a suivi une annonce concernant un important contrat de défense américain pour un système de laser à haute énergie. La première attribution s’élève à 44 millions de dollars, le programme total pouvant potentiellement atteindre 627 millions de dollars.

Alors que les actions des semi-conducteurs et de l’IA subissaient des pressions, les investisseurs semblaient davantage se concentrer sur le rôle croissant de nLIGHT dans la technologie de défense et les systèmes à énergie dirigée.

#LASR #nLIGHT #DefenseTechnology #stockssignal
$LAB
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme