Binance Square
Arham_
1.8k Publications

Arham_

253 Suivis
46 Abonnés
835 J’aime
Publications
·
--
Vérifié
J’observe les choses différemment au sujet de @Dusk_Foundation depuis quelque temps. En finance réglementée, la transparence totale peut devenir un problème. Imaginez que chaque position d’investisseur, chaque transaction et chaque portefeuille soient visibles en permanence. Les marchés ont besoin de confidentialité entre eux, tandis que les régulateurs doivent encore pouvoir prouver que les règles ont été respectées. Cela crée la vraie tension : Confidentialité pour les participants. Traçabilité et vérifiabilité pour les régulateurs. Dusk répond à cela avec des preuves à connaissance zéro et une divulgation sélective : prouver ce qui doit être vérifié sans exposer tout ce qui se trouve derrière la preuve. Et ce n’est pas seulement théorique. Dusk travaille avec NPEX, une bourse européenne de valeurs mobilières réglementée, qui a facilité plus de 200 M€ de financement pour 100+ PME. C’est pourquoi #dusk m’intéresse. La question relative aux RWA n’est pas simplement : « Peut-on mettre des titres on-chain ? » C’est plutôt : Peut-on rendre les marchés financiers vérifiables sans qu’ils deviennent totalement publics ? $DUSK {future}(DUSKUSDT) $HEMI {future}(HEMIUSDT) $TUT {future}(TUTUSDT)
J’observe les choses différemment au sujet de @Dusk depuis quelque temps.

En finance réglementée, la transparence totale peut devenir un problème.

Imaginez que chaque position d’investisseur, chaque transaction et chaque portefeuille soient visibles en permanence. Les marchés ont besoin de confidentialité entre eux, tandis que les régulateurs doivent encore pouvoir prouver que les règles ont été respectées.

Cela crée la vraie tension :

Confidentialité pour les participants. Traçabilité et vérifiabilité pour les régulateurs.

Dusk répond à cela avec des preuves à connaissance zéro et une divulgation sélective : prouver ce qui doit être vérifié sans exposer tout ce qui se trouve derrière la preuve.

Et ce n’est pas seulement théorique. Dusk travaille avec NPEX, une bourse européenne de valeurs mobilières réglementée, qui a facilité plus de 200 M€ de financement pour 100+ PME.

C’est pourquoi #dusk m’intéresse.

La question relative aux RWA n’est pas simplement : « Peut-on mettre des titres on-chain ? »

C’est plutôt :

Peut-on rendre les marchés financiers vérifiables sans qu’ils deviennent totalement publics ?
$DUSK
$HEMI
$TUT
·
--
Haussier
Vérifié
@Dusk_Foundation m’a amené à remettre en question l’idée que « plus de transparence » est automatiquement mieux. Je consultais $DUSK sur le graphique de 15 minutes et j’ai pris la tâche de trading de la campagne en position longue pendant que le prix était autour de 0,0704 $. Mais le graphique n’était pas la partie la plus intéressante. L’idée plus vaste de Dusk est que l’activité financière n’a pas besoin d’être soit totalement publique, soit totalement cachée. Elle doit être privée lorsque c’est nécessaire, et vérifiable lorsque c’est requis. Cette distinction compte dans la finance réglementée. Un investisseur n’a peut-être pas besoin que chaque détail de transaction soit exposé, tandis qu’une partie autorisée doit encore pouvoir vérifier ce qui s’est passé. Dusk aborde cela grâce aux preuves à divulgation nulle de connaissance, aux transactions confidentielles et à la divulgation sélective. Donc la vraie question n’est pas : « Cette transaction doit-elle être visible ? » Elle est : « Visible par qui, et pour quelle raison ? » C’est une supposition très différente de la transparence par défaut. Et si les marchés réglementés ont réellement besoin de cet espace intermédiaire, #dusk pourrait résoudre quelque chose de plus spécifique que de simplement construire une « blockchain privée ». La question la plus difficile est de savoir si la confidentialité vérifiable devient une exigence réelle du marché — ou reste une idée technique astucieuse en quête de demande. {future}(DUSKUSDT)
@Dusk m’a amené à remettre en question l’idée que « plus de transparence » est automatiquement mieux.

Je consultais $DUSK sur le graphique de 15 minutes et j’ai pris la tâche de trading de la campagne en position longue pendant que le prix était autour de 0,0704 $.

Mais le graphique n’était pas la partie la plus intéressante.

L’idée plus vaste de Dusk est que l’activité financière n’a pas besoin d’être soit totalement publique, soit totalement cachée.

Elle doit être privée lorsque c’est nécessaire, et vérifiable lorsque c’est requis.

Cette distinction compte dans la finance réglementée.

Un investisseur n’a peut-être pas besoin que chaque détail de transaction soit exposé, tandis qu’une partie autorisée doit encore pouvoir vérifier ce qui s’est passé.

Dusk aborde cela grâce aux preuves à divulgation nulle de connaissance, aux transactions confidentielles et à la divulgation sélective.

Donc la vraie question n’est pas :

« Cette transaction doit-elle être visible ? »

Elle est :

« Visible par qui, et pour quelle raison ? »

C’est une supposition très différente de la transparence par défaut.

Et si les marchés réglementés ont réellement besoin de cet espace intermédiaire, #dusk pourrait résoudre quelque chose de plus spécifique que de simplement construire une « blockchain privée ».

La question la plus difficile est de savoir si la confidentialité vérifiable devient une exigence réelle du marché — ou reste une idée technique astucieuse en quête de demande.
·
--
@Dusk_Foundation #dusk $DUSK En fouillant dans l’approche de Dusk pour la finance tokenisée, un chiffre a rendu le problème évident pour moi : 100 M$. Imaginez un portefeuille de crédit privé de 100 M$ qui évolue onchain. Les investisseurs doivent pouvoir vérifier la propriété, le règlement et le statut des actifs. Mais ils ne veulent probablement pas que chaque emprunteur, les conditions de prix et les relations financières soient exposés publiquement. C’est, je pense, l’élément qu’on oublie. La même transparence qui rend un actif plus facile à vérifier peut aussi rendre l’activité sous-jacente plus difficile à protéger. L’accent de Dusk sur la divulgation sélective aborde cette tension sous un autre angle : prouver ce qui doit être prouvé sans révéler automatiquement tout le reste. Et c’est important parce que la finance réglementée n’a pas besoin d’une transparence maximale. Elle a besoin de la bonne transparence, pour les bonnes personnes, au bon moment. Peut-être que le vrai défi de la mise en place de la finance onchain n’est pas de prouver ce qui s’est passé. C’est de le prouver sans en révéler trop. Donc, si on regarde les discussions actuelles de Dusk, qu’est-ce que vous pensez que serait la prochaine étape ? Ou, actuellement, si on parle de la plupart des “loser coins” $APR et $ACE , est-ce qu’ils vont rebondir ?
@Dusk #dusk $DUSK
En fouillant dans l’approche de Dusk pour la finance tokenisée, un chiffre a rendu le problème évident pour moi : 100 M$.

Imaginez un portefeuille de crédit privé de 100 M$ qui évolue onchain.

Les investisseurs doivent pouvoir vérifier la propriété, le règlement et le statut des actifs. Mais ils ne veulent probablement pas que chaque emprunteur, les conditions de prix et les relations financières soient exposés publiquement.

C’est, je pense, l’élément qu’on oublie.

La même transparence qui rend un actif plus facile à vérifier peut aussi rendre l’activité sous-jacente plus difficile à protéger.

L’accent de Dusk sur la divulgation sélective aborde cette tension sous un autre angle : prouver ce qui doit être prouvé sans révéler automatiquement tout le reste.

Et c’est important parce que la finance réglementée n’a pas besoin d’une transparence maximale.

Elle a besoin de la bonne transparence, pour les bonnes personnes, au bon moment.

Peut-être que le vrai défi de la mise en place de la finance onchain n’est pas de prouver ce qui s’est passé.

C’est de le prouver sans en révéler trop.

Donc, si on regarde les discussions actuelles de Dusk, qu’est-ce que vous pensez que serait la prochaine étape ? Ou, actuellement, si on parle de la plupart des “loser coins” $APR et $ACE , est-ce qu’ils vont rebondir ?
BULLISH 👆
0%
BEARISH 👇
100%
2 Votes • Vote fermé
·
--
$ACE
$ACE
Arham_
·
--
Vous pouvez terminer la campagne de Dusk sans jamais utiliser DuskEVM.

J’ai suivi la campagne moi-même et j’ai terminé la tâche de trading de 15 minutes. La voie la plus simple est la suivante : créer du contenu, participer, trader $DUSK .

Mais DuskEVM joue un autre jeu.

Il offre aux builders des outils EVM familiers tout en les reliant à l’infrastructure de Dusk pour la finance réglementée, où la confidentialité et le règlement vérifiable doivent fonctionner ensemble.

Ainsi, la couche EVM n’est pas vraiment l’histoire.

C’est la porte d’entrée familière vers un arrière-plan très différent.

Et cela crée la tension.

La campagne peut attirer des personnes qui n’ont aucune raison de développer des applications financières réglementées.

DuskEVM a besoin que certaines de ces personnes trouvent finalement cette raison.

La vraie question : DuskEVM amène-t-il des builders à #dusk @Dusk ou ne fait-il que donner aux builders un autre EVM à déployer ?
·
--
Vérifié
Vous pouvez terminer la campagne de Dusk sans jamais utiliser DuskEVM. J’ai suivi la campagne moi-même et j’ai terminé la tâche de trading de 15 minutes. La voie la plus simple est la suivante : créer du contenu, participer, trader $DUSK . Mais DuskEVM joue un autre jeu. Il offre aux builders des outils EVM familiers tout en les reliant à l’infrastructure de Dusk pour la finance réglementée, où la confidentialité et le règlement vérifiable doivent fonctionner ensemble. Ainsi, la couche EVM n’est pas vraiment l’histoire. C’est la porte d’entrée familière vers un arrière-plan très différent. Et cela crée la tension. La campagne peut attirer des personnes qui n’ont aucune raison de développer des applications financières réglementées. DuskEVM a besoin que certaines de ces personnes trouvent finalement cette raison. La vraie question : DuskEVM amène-t-il des builders à #dusk @Dusk_Foundation ou ne fait-il que donner aux builders un autre EVM à déployer ?
Vous pouvez terminer la campagne de Dusk sans jamais utiliser DuskEVM.

J’ai suivi la campagne moi-même et j’ai terminé la tâche de trading de 15 minutes. La voie la plus simple est la suivante : créer du contenu, participer, trader $DUSK .

Mais DuskEVM joue un autre jeu.

Il offre aux builders des outils EVM familiers tout en les reliant à l’infrastructure de Dusk pour la finance réglementée, où la confidentialité et le règlement vérifiable doivent fonctionner ensemble.

Ainsi, la couche EVM n’est pas vraiment l’histoire.

C’est la porte d’entrée familière vers un arrière-plan très différent.

Et cela crée la tension.

La campagne peut attirer des personnes qui n’ont aucune raison de développer des applications financières réglementées.

DuskEVM a besoin que certaines de ces personnes trouvent finalement cette raison.

La vraie question : DuskEVM amène-t-il des builders à #dusk @Dusk ou ne fait-il que donner aux builders un autre EVM à déployer ?
·
--
Baissier
Vérifié
Récemment, en observant de plus près @Dusk_Foundation more, j’ai remarqué quelque chose que je ne vois généralement pas dans les récits de la L1. J’ai en fait vérifié la page DUSK sur Binance et j’ai moi-même effectué la tâche de trading de la campagne. Au moment où je l’ai consultée, DUSK se situait autour de 0,0616 $ ; sa capitalisation boursière était de 30,79 M $, son FDV de 61,7 M $ et environ 499 M de DUSK en circulation sur une offre maximale de 1 Md. Les chiffres sont modestes par rapport à la plupart des L1 bien établies. Mais la partie la plus intéressante, c’est ce que Dusk cherche à construire. La plupart des chaînes considèrent la transparence comme un réglage par défaut. Dusk part d’une autre hypothèse : Et si la finance réglementée avait besoin, en même temps, de confidentialité et de transparence ? Cela compte, car les informations des investisseurs, les détails des transactions et les données de conformité ne peuvent pas toujours être entièrement publiques. Mais les régulateurs doivent quand même pouvoir vérifier ce qui s’est passé. Dusk conçoit ce système en tenant compte de cette tension, grâce à la confidentialité, à la divulgation sélective et au règlement déterministe. Ainsi, après avoir regardé au-delà de la campagne et en vérifiant concrètement le volet du token, je reviens toujours à une seule question : Dusk peut-il transformer l’attention et l’activité de trading en une demande pour l’infrastructure financière spécifique qu’il est en train de construire ? L’écart entre un token échangeable et un réseau de finance réglementée réellement utile, c’est là que, je pense, l’histoire intéressante commence. #dusk $DUSK
Récemment, en observant de plus près @Dusk more, j’ai remarqué quelque chose que je ne vois généralement pas dans les récits de la L1.

J’ai en fait vérifié la page DUSK sur Binance et j’ai moi-même effectué la tâche de trading de la campagne.

Au moment où je l’ai consultée, DUSK se situait autour de 0,0616 $ ; sa capitalisation boursière était de 30,79 M $, son FDV de 61,7 M $ et environ 499 M de DUSK en circulation sur une offre maximale de 1 Md.

Les chiffres sont modestes par rapport à la plupart des L1 bien établies. Mais la partie la plus intéressante, c’est ce que Dusk cherche à construire.

La plupart des chaînes considèrent la transparence comme un réglage par défaut.

Dusk part d’une autre hypothèse :

Et si la finance réglementée avait besoin, en même temps, de confidentialité et de transparence ?

Cela compte, car les informations des investisseurs, les détails des transactions et les données de conformité ne peuvent pas toujours être entièrement publiques. Mais les régulateurs doivent quand même pouvoir vérifier ce qui s’est passé.

Dusk conçoit ce système en tenant compte de cette tension, grâce à la confidentialité, à la divulgation sélective et au règlement déterministe.

Ainsi, après avoir regardé au-delà de la campagne et en vérifiant concrètement le volet du token, je reviens toujours à une seule question :

Dusk peut-il transformer l’attention et l’activité de trading en une demande pour l’infrastructure financière spécifique qu’il est en train de construire ?

L’écart entre un token échangeable et un réseau de finance réglementée réellement utile, c’est là que, je pense, l’histoire intéressante commence.
#dusk
$DUSK
·
--
J’ai passé un moment à relire @babylonlabs_io , et une chose n’arrêtait pas de me travailler.   L’histoire de la sécurité est facile à suivre. L’histoire de la puissance, elle, ne l’est pas.   Babylon a déjà plus de 56 800 BTC mis en jeu via elle. Ce type de chiffre attire naturellement l’attention sur la sécurité, l’échelle et la crédibilité. La plupart des gens liront un chiffre comme celui-ci et penseront la même chose : ça devient important.   Mais c’est précisément là que commence ma question.   Quand un protocole commence à se rapprocher autant de la sécurité, de la coordination et du capital, il ne se contente généralement pas de gagner en importance. Il commence à gagner en influence.   C’est la tension à laquelle je reviens sans cesse avec Babylon. #baby   Plus le récit sur la sécurité devient clair, plus il devient facile de cesser de poser la question plus dérangeante en dessous :   si cette couche devient plus importante, qui devient plus puissant avec elle ?   La crypto a déjà vu des versions de ce phénomène. L’infrastructure semble souvent neutre au début. Plus tard, les couches les plus proches de la coordination commencent à façonner les comportements autour d’elles : ce qui est priorisé, qui compte davantage, quelles relations deviennent plus difficiles à ignorer.   Cela ne veut pas dire que quelque chose est cassé. Cela veut dire que l’importance et l’influence ne progressent presque jamais séparément.   C’est pourquoi je pense que la question la plus intéressante pour Babylon n’est peut-être pas de savoir si sa conception de la sécurité a du sens.   La question, c’est plutôt si la puissance qui se forme autour de cette conception reste visible, équilibrée et acceptable à mesure que le système grandit.   Pour moi, c’est là que se situe la vraie tension.   Un protocole peut paraître plus solide au fur et à mesure qu’il devient plus central. Cela ne rend pas automatiquement l’écosystème qui l’entoure plus neutre.   Et une fois qu’un système commence à concentrer la sécurité, le capital et la coordination au même endroit, les gens remarquent généralement d’abord l’architecture.   Ils remarquent la puissance plus tard. $BABY $KOMA $GRVT maker semble
J’ai passé un moment à relire @BabylonLabs_io , et une chose n’arrêtait pas de me travailler.

L’histoire de la sécurité est facile à suivre.
L’histoire de la puissance, elle, ne l’est pas.

Babylon a déjà plus de 56 800 BTC mis en jeu via elle. Ce type de chiffre attire naturellement l’attention sur la sécurité, l’échelle et la crédibilité. La plupart des gens liront un chiffre comme celui-ci et penseront la même chose : ça devient important.

Mais c’est précisément là que commence ma question.

Quand un protocole commence à se rapprocher autant de la sécurité, de la coordination et du capital, il ne se contente généralement pas de gagner en importance. Il commence à gagner en influence.

C’est la tension à laquelle je reviens sans cesse avec Babylon. #baby

Plus le récit sur la sécurité devient clair, plus il devient facile de cesser de poser la question plus dérangeante en dessous :

si cette couche devient plus importante, qui devient plus puissant avec elle ?

La crypto a déjà vu des versions de ce phénomène. L’infrastructure semble souvent neutre au début. Plus tard, les couches les plus proches de la coordination commencent à façonner les comportements autour d’elles : ce qui est priorisé, qui compte davantage, quelles relations deviennent plus difficiles à ignorer.

Cela ne veut pas dire que quelque chose est cassé.
Cela veut dire que l’importance et l’influence ne progressent presque jamais séparément.

C’est pourquoi je pense que la question la plus intéressante pour Babylon n’est peut-être pas de savoir si sa conception de la sécurité a du sens.

La question, c’est plutôt si la puissance qui se forme autour de cette conception reste visible, équilibrée et acceptable à mesure que le système grandit.

Pour moi, c’est là que se situe la vraie tension.

Un protocole peut paraître plus solide au fur et à mesure qu’il devient plus central.
Cela ne rend pas automatiquement l’écosystème qui l’entoure plus neutre.

Et une fois qu’un système commence à concentrer la sécurité, le capital et la coordination au même endroit, les gens remarquent généralement d’abord l’architecture.

Ils remarquent la puissance plus tard.
$BABY $KOMA $GRVT
maker semble
Green 💚
25%
Red ❤️
75%
8 Votes • Vote fermé
·
--
Je lisais davantage au sujet de @babylonlabs_io et une idée ne cessait de s’interposer dans la version “optimiste” de l’histoire que je me racontais.   Beaucoup de ce qui paraît solide aujourd’hui ne semble solide que tant que les incitations rendent le choix encore facile.   Cela ne veut pas dire que la participation n’est pas réelle. Cela veut dire que participation réelle et alignement durable ne sont pas la même chose.   C’est en cela que je trouve quelque chose de plus intéressant que le simple argumentaire sur la sécurité.   Babylon peut apporter une sécurité adossée à Bitcoin dans davantage d’endroits. D’accord. Mais cela laisse encore une question plus difficile en dessous :   que se passe-t-il plus tard, quand les personnes qui sécurisent, utilisent ou construisent autour de ce système ne sont plus récompensées de la même manière ?   La crypto ne se “casse” généralement pas au niveau du récit. Elle se casse lorsque les mécanismes économiques commencent à entraîner les gens dans des directions différentes.   On voit ce schéma sur l’ensemble du marché. Pendant l’expansion, l’alignement semble plus profond qu’il ne l’est vraiment. Puis les rendements se compriment, de meilleures opportunités apparaissent ailleurs, et ce qui semblait être un engagement commence à ressembler davantage à une participation conditionnelle.   C’est pourquoi je ne pense pas que le test le plus difficile de Babylon soit de savoir si la conception fonctionne.   C’est de savoir si le comportement qui l’entoure tient encore une fois que le marché cesse de faire la même décision pour tout le monde.   C’est là, je pense, que le vrai défi commence. #baby $BABY $COTI $UAI
Je lisais davantage au sujet de @BabylonLabs_io et une idée ne cessait de s’interposer dans la version “optimiste” de l’histoire que je me racontais.

Beaucoup de ce qui paraît solide aujourd’hui ne semble solide que tant que les incitations rendent le choix encore facile.

Cela ne veut pas dire que la participation n’est pas réelle.
Cela veut dire que participation réelle et alignement durable ne sont pas la même chose.

C’est en cela que je trouve quelque chose de plus intéressant que le simple argumentaire sur la sécurité.

Babylon peut apporter une sécurité adossée à Bitcoin dans davantage d’endroits. D’accord. Mais cela laisse encore une question plus difficile en dessous :

que se passe-t-il plus tard, quand les personnes qui sécurisent, utilisent ou construisent autour de ce système ne sont plus récompensées de la même manière ?

La crypto ne se “casse” généralement pas au niveau du récit.
Elle se casse lorsque les mécanismes économiques commencent à entraîner les gens dans des directions différentes.

On voit ce schéma sur l’ensemble du marché. Pendant l’expansion, l’alignement semble plus profond qu’il ne l’est vraiment. Puis les rendements se compriment, de meilleures opportunités apparaissent ailleurs, et ce qui semblait être un engagement commence à ressembler davantage à une participation conditionnelle.

C’est pourquoi je ne pense pas que le test le plus difficile de Babylon soit de savoir si la conception fonctionne.

C’est de savoir si le comportement qui l’entoure tient encore une fois que le marché cesse de faire la même décision pour tout le monde.

C’est là, je pense, que le vrai défi commence. #baby
$BABY $COTI $UAI
BULLISH❣️🔥
27%
BEARISH💔🤓
73%
11 Votes • Vote fermé
·
--
J’ai passé un peu de temps à creuser @babylonlabs_io et une question revenait sans cesse : Tout le monde parle de sécurité partagée. Presque personne ne parle d’incitations partagées. Au début, ils semblent être la même chose. Ils ne le sont pas. Un protocole peut hériter de la sécurité de Bitcoin. Cela ne veut pas automatiquement dire que les personnes qui l’entourent continueront à agir de manière à la renforcer. C’est là que commence la question la plus difficile. La crypto a déjà vu ce schéma. Les incitations peuvent créer une convergence rapidement — mais elles peuvent aussi la défaire tout aussi vite. Quand l’économie change, la liquidité bouge, les validateurs réévaluent, et le consensus d’hier peut sembler très différent. Cela m’a fait me demander si l’une des questions les plus difficiles de Babylon est plutôt économique que technique. Étendre la sécurité de Bitcoin est un défi. Garder les participants alignés sur le plan économique après cela en est un autre. C’est la partie qui retient toute mon attention. Que #Babylon réussisse ne sera pas décidé uniquement par l’architecture. Cela dépendra aussi de savoir si les incitations derrière cette architecture continuent d’avoir du sens quand les conditions de marché changeront inévitablement. La sécurité se teste par les attaques. Les incitations se testent avec le temps. #baby $BABY {future}(BABYUSDT) $TAG {future}(TAGUSDT) $ON {future}(ONUSDT) 🤔 Qu’est-ce qui rend un réseau fort ?
J’ai passé un peu de temps à creuser @BabylonLabs_io et une question revenait sans cesse :
Tout le monde parle de sécurité partagée. Presque personne ne parle d’incitations partagées.
Au début, ils semblent être la même chose.
Ils ne le sont pas.
Un protocole peut hériter de la sécurité de Bitcoin. Cela ne veut pas automatiquement dire que les personnes qui l’entourent continueront à agir de manière à la renforcer.
C’est là que commence la question la plus difficile.
La crypto a déjà vu ce schéma. Les incitations peuvent créer une convergence rapidement — mais elles peuvent aussi la défaire tout aussi vite. Quand l’économie change, la liquidité bouge, les validateurs réévaluent, et le consensus d’hier peut sembler très différent.
Cela m’a fait me demander si l’une des questions les plus difficiles de Babylon est plutôt économique que technique.
Étendre la sécurité de Bitcoin est un défi. Garder les participants alignés sur le plan économique après cela en est un autre.
C’est la partie qui retient toute mon attention.
Que #Babylon réussisse ne sera pas décidé uniquement par l’architecture. Cela dépendra aussi de savoir si les incitations derrière cette architecture continuent d’avoir du sens quand les conditions de marché changeront inévitablement.
La sécurité se teste par les attaques. Les incitations se testent avec le temps. #baby
$BABY

$TAG

$ON

🤔 Qu’est-ce qui rend un réseau fort ?
🔒 Strong security
0%
💰 Strong incentives
0%
⚖️ Both equally
0%
⏳ Time will tell
0%
0 Votes • Vote fermé
·
--
Vérifié
Un élément de la campagne des coffres Bitcoin sans confiance de Babylon (TBV) est plus révélateur qu’il n’y paraît au premier abord :   en fait, la proposition ne se limite pas à « Bitcoin, mais utile ». Il s’agit de BTC natif comme garantie, sans l’envelopper, sans le bridger, ni de réintroduire un intermédiaire au milieu.   Cela compte, parce que la plupart de l’utilité de Bitcoin commence encore par le fait que Bitcoin devient autre chose.   BTC est le plus gros actif de la crypto, pourtant la plupart de son rôle économique est encore limité à être détenu, transféré... ou vendu. Quand les gens veulent davantage, l’habitude consiste à abandonner le BTC natif et à utiliser une version qui s’intègre plus facilement au reste de l’écosystème crypto.   TBV est intéressant parce qu’il s’oppose à cette habitude.   Ainsi, le vrai enjeu n’est pas seulement la structure du coffre. C’est la tentative d’élargir le rôle financier de Bitcoin sans, au préalable, changer ce qu’est Bitcoin.   C’est une tension plus grande que ce que le langage de la campagne ne laisse voir. La crypto répète qu’elle veut de la liquidité Bitcoin, mais la plupart des systèmes construits autour de cette idée n’ont su y accéder qu’en transformant le BTC en une version plus pratique quelque part ailleurs.   C’est pourquoi @babylonlabs_io $BABY et #baby valent la peine d’être surveillés ici. Non pas parce que cela prouve quelque chose pour l’instant, mais parce que cela teste discrètement une question plus dérangeante :   Bitcoin peut-il devenir un capital utilisable dans l’économie on-chain sans d’abord devenir moins « bitcoin-like » ?   Si TBV prend vraiment de l’ampleur, cela pourrait finir par être le signal le plus important : non pas que Bitcoin a trouvé un autre cas d’usage, mais qu’il commence à entrer dans la finance on-chain à des conditions plus natives. $DIA {future}(DIAUSDT) $PIEVERSE {future}(PIEVERSEUSDT) Quel est le plus grand obstacle au BTC natif dans DeFi ?
Un élément de la campagne des coffres Bitcoin sans confiance de Babylon (TBV) est plus révélateur qu’il n’y paraît au premier abord :

en fait, la proposition ne se limite pas à « Bitcoin, mais utile ». Il s’agit de BTC natif comme garantie, sans l’envelopper, sans le bridger, ni de réintroduire un intermédiaire au milieu.

Cela compte, parce que la plupart de l’utilité de Bitcoin commence encore par le fait que Bitcoin devient autre chose.

BTC est le plus gros actif de la crypto, pourtant la plupart de son rôle économique est encore limité à être détenu, transféré... ou vendu. Quand les gens veulent davantage, l’habitude consiste à abandonner le BTC natif et à utiliser une version qui s’intègre plus facilement au reste de l’écosystème crypto.

TBV est intéressant parce qu’il s’oppose à cette habitude.

Ainsi, le vrai enjeu n’est pas seulement la structure du coffre. C’est la tentative d’élargir le rôle financier de Bitcoin sans, au préalable, changer ce qu’est Bitcoin.

C’est une tension plus grande que ce que le langage de la campagne ne laisse voir. La crypto répète qu’elle veut de la liquidité Bitcoin, mais la plupart des systèmes construits autour de cette idée n’ont su y accéder qu’en transformant le BTC en une version plus pratique quelque part ailleurs.

C’est pourquoi @BabylonLabs_io $BABY et #baby valent la peine d’être surveillés ici. Non pas parce que cela prouve quelque chose pour l’instant, mais parce que cela teste discrètement une question plus dérangeante :

Bitcoin peut-il devenir un capital utilisable dans l’économie on-chain sans d’abord devenir moins « bitcoin-like » ?

Si TBV prend vraiment de l’ampleur, cela pourrait finir par être le signal le plus important : non pas que Bitcoin a trouvé un autre cas d’usage, mais qu’il commence à entrer dans la finance on-chain à des conditions plus natives.
$DIA
$PIEVERSE

Quel est le plus grand obstacle au BTC natif dans DeFi ?
🔒 Security
50%
⚡ User experience
50%
💧 Liquidity
0%
👥 Adoption
0%
2 Votes • Vote fermé
·
--
les gars aiment et commentent s’il vous plaît
les gars aiment et commentent s’il vous plaît
Arham_
·
--
J’ai passé un peu de temps à examiner la campagne des coffres Bitcoin sans confiance (TBV) de Babylon, et un détail a retenu mon attention : l’enjeu n’est pas seulement d’utiliser Bitcoin. Il s’agit d’utiliser le BTC natif comme garantie, sans l’envelopper, le faire passer via un pont ou le confier d’abord à une autre couche.
 
C’est important parce que la plupart des cas d’usage du Bitcoin commencent encore par transformer le Bitcoin en autre chose.
 
Le BTC est l’actif le plus important dans la crypto, mais son rôle économique reste largement limité au fait d’être détenu, transféré ou vendu. Quand les gens veulent en faire davantage, le chemin habituel consiste à laisser le Bitcoin natif derrière soi et à utiliser une version plus flexible ailleurs.
 
TBV va dans la direction opposée.
 
C’est la tension à laquelle je reviens sans cesse : le marché dit qu’il veut des cas d’usage pour Bitcoin, mais la plupart des Bitcoin réellement exploitables ont d’abord dû devenir moins natifs.
 
Donc la partie intéressante ne tient pas seulement à la fonctionnalité elle-même. Il s’agit de la tentative d’élargir le rôle financier du Bitcoin sans commencer par changer ce qu’est le Bitcoin.
 
Si cela commence à fonctionner, cela pourrait dire quelque chose de plus vaste sur la place du Bitcoin ensuite, non seulement comme valeur que les gens conservent, mais comme capital pouvant circuler au sein de l’économie on-chain selon des modalités davantage BTC natives.
@BabylonLabs_io #baby $BABY

$DEXE

$B2


₿ Utilité du BTC natif ?
·
--
Vérifié
J’ai passé un peu de temps à examiner la campagne des coffres Bitcoin sans confiance (TBV) de Babylon, et un détail a retenu mon attention : l’enjeu n’est pas seulement d’utiliser Bitcoin. Il s’agit d’utiliser le BTC natif comme garantie, sans l’envelopper, le faire passer via un pont ou le confier d’abord à une autre couche.   C’est important parce que la plupart des cas d’usage du Bitcoin commencent encore par transformer le Bitcoin en autre chose.   Le BTC est l’actif le plus important dans la crypto, mais son rôle économique reste largement limité au fait d’être détenu, transféré ou vendu. Quand les gens veulent en faire davantage, le chemin habituel consiste à laisser le Bitcoin natif derrière soi et à utiliser une version plus flexible ailleurs.   TBV va dans la direction opposée.   C’est la tension à laquelle je reviens sans cesse : le marché dit qu’il veut des cas d’usage pour Bitcoin, mais la plupart des Bitcoin réellement exploitables ont d’abord dû devenir moins natifs.   Donc la partie intéressante ne tient pas seulement à la fonctionnalité elle-même. Il s’agit de la tentative d’élargir le rôle financier du Bitcoin sans commencer par changer ce qu’est le Bitcoin.   Si cela commence à fonctionner, cela pourrait dire quelque chose de plus vaste sur la place du Bitcoin ensuite, non seulement comme valeur que les gens conservent, mais comme capital pouvant circuler au sein de l’économie on-chain selon des modalités davantage BTC natives. @babylonlabs_io #baby $BABY {future}(BABYUSDT) $DEXE {future}(DEXEUSDT) $B2 {future}(B2USDT) ₿ Utilité du BTC natif ?
J’ai passé un peu de temps à examiner la campagne des coffres Bitcoin sans confiance (TBV) de Babylon, et un détail a retenu mon attention : l’enjeu n’est pas seulement d’utiliser Bitcoin. Il s’agit d’utiliser le BTC natif comme garantie, sans l’envelopper, le faire passer via un pont ou le confier d’abord à une autre couche.

C’est important parce que la plupart des cas d’usage du Bitcoin commencent encore par transformer le Bitcoin en autre chose.

Le BTC est l’actif le plus important dans la crypto, mais son rôle économique reste largement limité au fait d’être détenu, transféré ou vendu. Quand les gens veulent en faire davantage, le chemin habituel consiste à laisser le Bitcoin natif derrière soi et à utiliser une version plus flexible ailleurs.

TBV va dans la direction opposée.

C’est la tension à laquelle je reviens sans cesse : le marché dit qu’il veut des cas d’usage pour Bitcoin, mais la plupart des Bitcoin réellement exploitables ont d’abord dû devenir moins natifs.

Donc la partie intéressante ne tient pas seulement à la fonctionnalité elle-même. Il s’agit de la tentative d’élargir le rôle financier du Bitcoin sans commencer par changer ce qu’est le Bitcoin.

Si cela commence à fonctionner, cela pourrait dire quelque chose de plus vaste sur la place du Bitcoin ensuite, non seulement comme valeur que les gens conservent, mais comme capital pouvant circuler au sein de l’économie on-chain selon des modalités davantage BTC natives.
@BabylonLabs_io #baby $BABY
$DEXE
$B2

₿ Utilité du BTC natif ?
✅ The future
100%
🤔 Too early
0%
📦 Wrapped wins
0%
❓Not sure
0%
3 Votes • Vote fermé
·
--
Vérifié
Un détail m’a particulièrement marqué dans la campagne des Babylon Trustless Bitcoin Vaults (TBV) : l’accent ne porte pas seulement sur « l’utilisation de Bitcoin », mais sur l’utilisation de BTC natifs comme garantie, sans l’envelopper, sans le faire passer via un pont (bridging) et sans le router par l’intermédiaire d’autres acteurs.   Ce point compte, car le Bitcoin est énorme, mais économiquement il reste encore largement passif. Les gens le détiennent, le déplacent ou le vendent. Quand ils veulent une utilité, la voie habituelle consiste à le transformer en une version plus flexible ailleurs.   TBV propose une idée différente.   Pas seulement du Bitcoin comme réserve de valeur, mais du Bitcoin comme garantie opérationnelle, et surtout, une garantie sous forme native.   C’est cette partie à laquelle je reviens sans cesse. La fonctionnalité elle-même en est une. L’implication plus vaste, c’est que TBV traduit une tentative d’étendre le rôle financier du Bitcoin sans, au préalable, l’abstraire.   Si ce modèle devient viable, il pourrait avoir des conséquences bien au-delà d’une seule campagne.   Car alors, la question ne sera plus de savoir si le Bitcoin peut être conservé en toute sécurité. Il s’agira de savoir si le BTC natif peut commencer à participer à la finance on-chain sans d’abord devenir autre chose. @babylonlabs_io #baby $BABY $ESPORTS $RE BTC natif comme garantie ?
Un détail m’a particulièrement marqué dans la campagne des Babylon Trustless Bitcoin Vaults (TBV) : l’accent ne porte pas seulement sur « l’utilisation de Bitcoin », mais sur l’utilisation de BTC natifs comme garantie, sans l’envelopper, sans le faire passer via un pont (bridging) et sans le router par l’intermédiaire d’autres acteurs.

Ce point compte, car le Bitcoin est énorme, mais économiquement il reste encore largement passif. Les gens le détiennent, le déplacent ou le vendent. Quand ils veulent une utilité, la voie habituelle consiste à le transformer en une version plus flexible ailleurs.

TBV propose une idée différente.

Pas seulement du Bitcoin comme réserve de valeur, mais du Bitcoin comme garantie opérationnelle, et surtout, une garantie sous forme native.

C’est cette partie à laquelle je reviens sans cesse. La fonctionnalité elle-même en est une. L’implication plus vaste, c’est que TBV traduit une tentative d’étendre le rôle financier du Bitcoin sans, au préalable, l’abstraire.

Si ce modèle devient viable, il pourrait avoir des conséquences bien au-delà d’une seule campagne.

Car alors, la question ne sera plus de savoir si le Bitcoin peut être conservé en toute sécurité. Il s’agira de savoir si le BTC natif peut commencer à participer à la finance on-chain sans d’abord devenir autre chose.
@BabylonLabs_io
#baby
$BABY
$ESPORTS
$RE
BTC natif comme garantie ?
✅ Yes, the future
33%
⚖️ Only sometimes
0%
📦 Wrapped BTC wins
67%
⏳ Too early
0%
3 Votes • Vote fermé
·
--
Haussier
J’ai passé un peu de temps à examiner les coffres Bitcoin sans confiance (TBV) de Babylon, et ce qui a surtout retenu mon attention n’était pas l’architecture des coffres en elle-même. C’est plutôt la question que les TBV posent discrètement au marché du Bitcoin : Les utilisateurs veulent-ils vraiment minimiser la confiance, ou cherchent-ils surtout la commodité tout en la présentant de manière à paraître sans confiance ? Sa conception suit une intuition très native du Bitcoin : réduire la confiance au maximum, plutôt que de la déplacer derrière des interfaces plus épurées ou des habillages plus familiers. L’ingénierie compte, mais la vraie question est de savoir si les utilisateurs adoptent réellement cette philosophie. Car la partie difficile ne consiste pas à construire une infrastructure réellement minimisant la confiance. Le plus difficile, c’est d’amener les gens à la choisir. Les utilisateurs de la cryptomonnaie disent régulièrement qu’ils accordent de la valeur à la souveraineté, à la garde non confiée (self-custody) et à la décentralisation. Mais l’adoption continue d’orienter son flux vers des produits qui suppriment le plus vite les frictions, même quand cette simplicité ramène discrètement de la confiance. C’est la contradiction que les TBV mettent en lumière. Pour moi, c’est plus grand qu’une seule fonctionnalité de Babylon. Les TBV ressemblent à une étude de cas sur le point de savoir si l’infrastructure Bitcoin devient enfin suffisamment utilisable pour que des principes puissent rivaliser avec la commodité. Si cela se produit, cela dit quelque chose d’important sur la maturation du marché. Sinon, cela dit aussi quelque chose. Au final, le plus grand défi du Bitcoin sans confiance ne sera peut-être pas de construire une infrastructure meilleure : il pourrait s’agir de changer le comportement des utilisateurs.@babylonlabs_io #baby $BABY $RIF $BANK
J’ai passé un peu de temps à examiner les coffres Bitcoin sans confiance (TBV) de Babylon, et ce qui a surtout retenu mon attention n’était pas l’architecture des coffres en elle-même.

C’est plutôt la question que les TBV posent discrètement au marché du Bitcoin :

Les utilisateurs veulent-ils vraiment minimiser la confiance, ou cherchent-ils surtout la commodité tout en la présentant de manière à paraître sans confiance ?

Sa conception suit une intuition très native du Bitcoin : réduire la confiance au maximum, plutôt que de la déplacer derrière des interfaces plus épurées ou des habillages plus familiers. L’ingénierie compte, mais la vraie question est de savoir si les utilisateurs adoptent réellement cette philosophie.

Car la partie difficile ne consiste pas à construire une infrastructure réellement minimisant la confiance.

Le plus difficile, c’est d’amener les gens à la choisir.

Les utilisateurs de la cryptomonnaie disent régulièrement qu’ils accordent de la valeur à la souveraineté, à la garde non confiée (self-custody) et à la décentralisation. Mais l’adoption continue d’orienter son flux vers des produits qui suppriment le plus vite les frictions, même quand cette simplicité ramène discrètement de la confiance.

C’est la contradiction que les TBV mettent en lumière.

Pour moi, c’est plus grand qu’une seule fonctionnalité de Babylon. Les TBV ressemblent à une étude de cas sur le point de savoir si l’infrastructure Bitcoin devient enfin suffisamment utilisable pour que des principes puissent rivaliser avec la commodité.

Si cela se produit, cela dit quelque chose d’important sur la maturation du marché. Sinon, cela dit aussi quelque chose.

Au final, le plus grand défi du Bitcoin sans confiance ne sera peut-être pas de construire une infrastructure meilleure : il pourrait s’agir de changer le comportement des utilisateurs.@BabylonLabs_io #baby $BABY $RIF $BANK
·
--
Shehab Goma
·
--
Baissier
J’ai passé du temps à regarder les statistiques en direct de GRVT au lieu de regarder le terrain. Un point m’a arrêté.

La couche de confidentialité est réelle. Correspondance hors chaîne. Preuves ZK sur chaîne. Pas de l’image de marque.

Mais le flux du marché semblait toujours familier.

169 paires. 843 M$ de volume. 352,6 M$ d’open interest. Même avec des perpétuels crypto et RWA, le flux se regroupe autour des principales. Rien que BTC_USDT_PERP : 246,6 M$ de volume, 165,8 M$ d’open interest.

C’est ça qui m’a marqué.

@grvt_io change la manière dont les gens échangent avec plus de sécurité. Ça ne change pas ce que la foule veut échanger. Cette distinction compte.

La crypto suppose qu’une meilleure infrastructure produit un comportement différent. Parfois, elle ne fait que rendre le même comportement plus sûr et plus difficile à exploiter.

Le règlement privé réduit les fuites. Rend le front-running moins lisible. Améliore la confidentialité de l’exécution. Ce qu’il ne peut pas faire, en revanche, c’est effacer l’instinct grégaire. Les traders continuent de se tourner vers les carnets les plus profonds. Toujours ils se regroupent sur les paires les plus faciles à dimensionner et à quitter. La ZK protège la transaction. Elle n’empêche pas la foule.

Plusieurs rapports évoquent un lancement de token autour du 21 juillet 2026. L’attention est plus élevée. J’attendrais une confirmation officielle, mais le calendrier affine la question.

La question intéressante n’est pas de savoir si la confidentialité de GRVT fonctionne. Elle fonctionne.

La question est de savoir si le règlement privé change quelque chose au-delà du risque d’exécution.

Si le comportement des traders a l’air identique, la contribution de GRVT pourrait être plus limitée, mais plus honnête. Ne pas changer la psychologie. Protéger les gens pendant qu’ils échangent comme ils l’ont toujours fait.

C’est toujours significatif. Le prochain avantage dans la conception des échanges ne viendra pas du fait de modifier la foule. Il viendra de la réduction du coût d’un comportement de foule.
@grvt_io #grvt
BTC+0,66%
LAB+15,05%
AMDUS+2,48%
·
--
Vérifié
La plupart des gens pensent que les méthodes de vérification d’OpenGradient — ZKML, TEE, Vanilla — sont un choix unique qu’on fait par application. Choisissez votre niveau de confiance et restez-y. Ce n’est pas ainsi que cela fonctionne réellement. L’architecture permet d’exécuter, au sein de la même transaction, des inférences différentes avec des méthodes de vérification différentes. TEE pour l’étape de raisonnement du LLM. ZKML pour un modèle de risque. Vanilla pour l’analytique. le tout dans une seule opération atomique. C’est un choix de conception discrètement important. Cela signifie que le niveau de vérifiabilité de cette application n’est pas une réponse unique : c’est une composition. Un agent de trading pourrait avoir une certitude mathématique de niveau ZKML pour la partie qui calcule l’exposition au risque, tandis que la partie qui génère l’explication en langage naturel s’appuie sur une attestation TEE, et qu’une étape de journalisation tourne uniquement sur le mode de signature Vanilla. Le hic : rien, dans la sortie, ne vous indique quelles parties ont été vérifiées et comment. Un utilisateur voit une inférence vérifiée et suppose une confiance uniforme. En réalité, trois garanties différentes peuvent être assemblées, et la plus faible de la chaîne fait le véritable travail de limiter à quel point vous pouvez réellement faire confiance au résultat. C’est une force, techniquement : un réglage fin de la confiance plutôt qu’une exigence de preuve “taille unique”. Mais cela déplace un vrai fardeau sur les développeurs, qui doivent divulguer ce qui est vérifié à quel niveau, et sur les utilisateurs, qui doivent réellement demander. Pour l’instant, rien n’impose cette divulgation. La vérification composable est une ingénierie intelligente. Une confiance composable sans transparence composable est un manque qui vaut la peine d’être surveillé. Faut-il exiger que les applications divulguent les méthodes de vérification pour chaque étape d’inférence ? @OpenGradient #OPG #DowHitsRecordClose #SupremeCourtBlocksTrumpFromRemovingFedCook #YenHitsFourDecadeLowVsDollar $OPG $TAIKO $NFP
La plupart des gens pensent que les méthodes de vérification d’OpenGradient — ZKML, TEE, Vanilla — sont un choix unique qu’on fait par application. Choisissez votre niveau de confiance et restez-y.
Ce n’est pas ainsi que cela fonctionne réellement. L’architecture permet d’exécuter, au sein de la même transaction, des inférences différentes avec des méthodes de vérification différentes. TEE pour l’étape de raisonnement du LLM. ZKML pour un modèle de risque. Vanilla pour l’analytique. le tout dans une seule opération atomique.
C’est un choix de conception discrètement important. Cela signifie que le niveau de vérifiabilité de cette application n’est pas une réponse unique : c’est une composition. Un agent de trading pourrait avoir une certitude mathématique de niveau ZKML pour la partie qui calcule l’exposition au risque, tandis que la partie qui génère l’explication en langage naturel s’appuie sur une attestation TEE, et qu’une étape de journalisation tourne uniquement sur le mode de signature Vanilla.
Le hic : rien, dans la sortie, ne vous indique quelles parties ont été vérifiées et comment. Un utilisateur voit une inférence vérifiée et suppose une confiance uniforme. En réalité, trois garanties différentes peuvent être assemblées, et la plus faible de la chaîne fait le véritable travail de limiter à quel point vous pouvez réellement faire confiance au résultat.
C’est une force, techniquement : un réglage fin de la confiance plutôt qu’une exigence de preuve “taille unique”. Mais cela déplace un vrai fardeau sur les développeurs, qui doivent divulguer ce qui est vérifié à quel niveau, et sur les utilisateurs, qui doivent réellement demander. Pour l’instant, rien n’impose cette divulgation.
La vérification composable est une ingénierie intelligente. Une confiance composable sans transparence composable est un manque qui vaut la peine d’être surveillé.
Faut-il exiger que les applications divulguent les méthodes de vérification pour chaque étape d’inférence ?
@OpenGradient
#OPG
#DowHitsRecordClose
#SupremeCourtBlocksTrumpFromRemovingFedCook
#YenHitsFourDecadeLowVsDollar
$OPG
$TAIKO
$NFP
🧩 Yes, mandatory
0%
🔧 Devs decide
0%
🤷 Doesn't matter
0%
📊 Only for high-stakes
0%
0 Votes • Vote fermé
·
--
Like Comment 👇 et récupère-le 💫💫💫💫
Like Comment 👇 et récupère-le 💫💫💫💫
Arham_
·
--
Voici ce que personne n’a examiné de près. Leurs preuves, les preuves ZKML, la partie qui devrait être l’objectif même : tout est stocké sur Walrus.
C’est confirmé directement par leurs propres documents d’architecture. Walrus conserve les grosses données, la chaîne ne fait que garder un pointeur.
Maintenant, allez lire la page de sécurité de Walrus. En langage clair, sans demi-mesures : par défaut, chaque blob sur Walrus est public.
Accessible par n’importe qui. Pas de chiffrement sauf si vous l’ajoutez vous-même. Toute personne ayant l’ID du blob peut simplement... le récupérer.
Alors, à quel moment le chiffrement apparaît-il réellement ?
Consultez l’annonce du partenariat OpenGradient–Walrus. Le chiffrement est mentionné exactement une fois et il est limité aux modèles privés et propriétaires du niveau payant, le tout conditionné par quelque chose appelé Seal.
Des permissions sont appliquées on-chain, bien sûr, mais uniquement pour ce produit précis.
Personne ne parle de chiffrement pour le reste. Les preuves ZKML du quotidien. Les sorties d’inférence standard qui constituent une IA vérifiable, en pratique, construite tous les jours pour chaque utilisateur ordinaire.
Elles ne sont nommées nulle part comme étant chiffrées. Donc, par défaut, selon Walrus lui-même, elles sont là, publiques et récupérables comme n’importe quel autre blob.
La vérification n’a jamais été la même chose que la confidentialité. @OpenGradient Il suffit de laisser les gens croire que c’était le cas parce que le mot vérifiable fait penser que ça couvre tout. Mais non. La confidentialité est un niveau que vous achetez. La vérification, ce n’est que des maths à ciel ouvert, disponibles pour quiconque a l’ID.
@OpenGradient
#OPG
$OPG
$TAC
$RAVE
Votre preuve, par défaut, c’est…
·
--
Voici ce que personne n’a examiné de près. Leurs preuves, les preuves ZKML, la partie qui devrait être l’objectif même : tout est stocké sur Walrus. C’est confirmé directement par leurs propres documents d’architecture. Walrus conserve les grosses données, la chaîne ne fait que garder un pointeur. Maintenant, allez lire la page de sécurité de Walrus. En langage clair, sans demi-mesures : par défaut, chaque blob sur Walrus est public. Accessible par n’importe qui. Pas de chiffrement sauf si vous l’ajoutez vous-même. Toute personne ayant l’ID du blob peut simplement... le récupérer. Alors, à quel moment le chiffrement apparaît-il réellement ? Consultez l’annonce du partenariat OpenGradient–Walrus. Le chiffrement est mentionné exactement une fois et il est limité aux modèles privés et propriétaires du niveau payant, le tout conditionné par quelque chose appelé Seal. Des permissions sont appliquées on-chain, bien sûr, mais uniquement pour ce produit précis. Personne ne parle de chiffrement pour le reste. Les preuves ZKML du quotidien. Les sorties d’inférence standard qui constituent une IA vérifiable, en pratique, construite tous les jours pour chaque utilisateur ordinaire. Elles ne sont nommées nulle part comme étant chiffrées. Donc, par défaut, selon Walrus lui-même, elles sont là, publiques et récupérables comme n’importe quel autre blob. La vérification n’a jamais été la même chose que la confidentialité. @OpenGradient Il suffit de laisser les gens croire que c’était le cas parce que le mot vérifiable fait penser que ça couvre tout. Mais non. La confidentialité est un niveau que vous achetez. La vérification, ce n’est que des maths à ciel ouvert, disponibles pour quiconque a l’ID. @OpenGradient #OPG $OPG $TAC $RAVE Votre preuve, par défaut, c’est…
Voici ce que personne n’a examiné de près. Leurs preuves, les preuves ZKML, la partie qui devrait être l’objectif même : tout est stocké sur Walrus.
C’est confirmé directement par leurs propres documents d’architecture. Walrus conserve les grosses données, la chaîne ne fait que garder un pointeur.
Maintenant, allez lire la page de sécurité de Walrus. En langage clair, sans demi-mesures : par défaut, chaque blob sur Walrus est public.
Accessible par n’importe qui. Pas de chiffrement sauf si vous l’ajoutez vous-même. Toute personne ayant l’ID du blob peut simplement... le récupérer.
Alors, à quel moment le chiffrement apparaît-il réellement ?
Consultez l’annonce du partenariat OpenGradient–Walrus. Le chiffrement est mentionné exactement une fois et il est limité aux modèles privés et propriétaires du niveau payant, le tout conditionné par quelque chose appelé Seal.
Des permissions sont appliquées on-chain, bien sûr, mais uniquement pour ce produit précis.
Personne ne parle de chiffrement pour le reste. Les preuves ZKML du quotidien. Les sorties d’inférence standard qui constituent une IA vérifiable, en pratique, construite tous les jours pour chaque utilisateur ordinaire.
Elles ne sont nommées nulle part comme étant chiffrées. Donc, par défaut, selon Walrus lui-même, elles sont là, publiques et récupérables comme n’importe quel autre blob.
La vérification n’a jamais été la même chose que la confidentialité. @OpenGradient Il suffit de laisser les gens croire que c’était le cas parce que le mot vérifiable fait penser que ça couvre tout. Mais non. La confidentialité est un niveau que vous achetez. La vérification, ce n’est que des maths à ciel ouvert, disponibles pour quiconque a l’ID.
@OpenGradient
#OPG
$OPG
$TAC
$RAVE
Votre preuve, par défaut, c’est…
🌐 Public to anyone
0%
🔐 Encrypted automatically
0%
💳 Only private if you pay
0%
🤷 Genuinely unclear
0%
0 Votes • Vote fermé
·
--
Tout le monde continue d’appeler OpenGradient une IA vérifiable. Beau mot. Regardons ça une seconde. Imaginons que vous envoyiez un prompt via un LLM Proxy Node. Il rebondit vers un modèle tiers. Le TEE encapsule tout le trajet et vous récupérez une attestation. D’accord, mais qu’est-ce que cette chose prouve réellement ? Juste que personne n’a lu votre prompt pendant le trajet. Personne n’a remplacé la réponse en chemin pour vous la renvoyer. La conduite est restée propre du début à la fin. C’est tout. Voici ce que ça ne touche jamais : quel modèle a réellement rédigé votre réponse. Que le fournisseur vous ait discrètement rétrogradé vers quelque chose de moins cher. Que l’entrée ait été déformée avant même d’arriver chez eux. Tout ça n’est pas visible depuis l’intérieur d’un enclave. Une fois que votre requête quitte OpenGradient et atterrit sur le serveur de quelqu’un d’autre, la vérification s’arrête. Mur infranchissable. Donc la “raisonnement vérifié” fait un peu de magie. Ce qui est réellement vérifié, c’est la livraison. Le modèle lui-même continue de tourner sur la base de la confiance, comme toujours. Pas une arnaque, pas même vraiment un défaut. Juste quelque chose à savoir avant de brancher l’argent d’un agent sur une garantie qui ne couvre pas exactement ce que vous pensez qu’elle couvre. @OpenGradient #OPG $ZEREBRO {future}(ZEREBROUSDT) $RAVE {future}(RAVEUSDT) $OPG {spot}(OPGUSDT)
Tout le monde continue d’appeler OpenGradient une IA vérifiable. Beau mot. Regardons ça une seconde.
Imaginons que vous envoyiez un prompt via un LLM Proxy Node. Il rebondit vers un modèle tiers. Le TEE encapsule tout le trajet et vous récupérez une attestation.
D’accord, mais qu’est-ce que cette chose prouve réellement ?
Juste que personne n’a lu votre prompt pendant le trajet. Personne n’a remplacé la réponse en chemin pour vous la renvoyer. La conduite est restée propre du début à la fin. C’est tout.
Voici ce que ça ne touche jamais : quel modèle a réellement rédigé votre réponse. Que le fournisseur vous ait discrètement rétrogradé vers quelque chose de moins cher. Que l’entrée ait été déformée avant même d’arriver chez eux.
Tout ça n’est pas visible depuis l’intérieur d’un enclave. Une fois que votre requête quitte OpenGradient et atterrit sur le serveur de quelqu’un d’autre, la vérification s’arrête. Mur infranchissable.
Donc la “raisonnement vérifié” fait un peu de magie. Ce qui est réellement vérifié, c’est la livraison. Le modèle lui-même continue de tourner sur la base de la confiance, comme toujours.
Pas une arnaque, pas même vraiment un défaut. Juste quelque chose à savoir avant de brancher l’argent d’un agent sur une garantie qui ne couvre pas exactement ce que vous pensez qu’elle couvre.
@OpenGradient
#OPG
$ZEREBRO

$RAVE

$OPG
Pipe proof ✅
100%
Need more 🧠
0%
Big gap 🚨
0%
Don't care 🤷
0%
1 Votes • Vote fermé
·
--
La plupart de ce que nous avons couvert à propos de leur pile de confidentialité concerne le fait de masquer qui a demandé quelque chose. Les attestations TEE, le streaming OHTTP, les décompositions relay/gateway : tout est conçu pour que personne ne puisse voir qui a envoyé une requête. Leur propre messagerie ajoute une deuxième affirmation par-dessus. En reformulant leur raisonnement déclaré : la plupart des IA ne répondront pas à vos vraies questions… mais elles se souviennent quand même de tout ce que vous leur avez demandé. C’est l’écart qu’ils disent avoir comblé. Deux choses différentes, toutefois. Masquer qui a posé la question est un problème de confidentialité. Supprimer les refus d’un modèle est une décision totalement différente. Le pitch d’OpenGradient les fusionne en une seule phrase… mais ce n’est pas la même fonctionnalité. Et voici l’écart réel qui vaut d’être nommé : la vérification prouve qu’un modèle spécifique a produit une sortie spécifique pour une entrée spécifique, sans altération. C’est tout. Cela ne dit rien sur le fait que l’échange lui-même était correct. « Vérifié » et « validé » ne sont pas le même mot, même si beaucoup de marketing autour d’une IA vérifiable veut qu’on les fasse passer pour interchangeables. Ce n’est pas une critique du travail d’ingénierie : ce que fait le TEE tient la route… Il vaut simplement la peine de distinguer les deux affirmations avant de croire qu’elles constituent une seule fonctionnalité. @OpenGradient #OPG $VELVET {future}(VELVETUSDT) $MYX {future}(MYXUSDT) $OPG {future}(OPGUSDT)
La plupart de ce que nous avons couvert à propos de leur pile de confidentialité concerne le fait de masquer qui a demandé quelque chose. Les attestations TEE, le streaming OHTTP, les décompositions relay/gateway : tout est conçu pour que personne ne puisse voir qui a envoyé une requête.

Leur propre messagerie ajoute une deuxième affirmation par-dessus. En reformulant leur raisonnement déclaré : la plupart des IA ne répondront pas à vos vraies questions… mais elles se souviennent quand même de tout ce que vous leur avez demandé. C’est l’écart qu’ils disent avoir comblé.

Deux choses différentes, toutefois. Masquer qui a posé la question est un problème de confidentialité. Supprimer les refus d’un modèle est une décision totalement différente. Le pitch d’OpenGradient les fusionne en une seule phrase… mais ce n’est pas la même fonctionnalité.

Et voici l’écart réel qui vaut d’être nommé : la vérification prouve qu’un modèle spécifique a produit une sortie spécifique pour une entrée spécifique, sans altération. C’est tout. Cela ne dit rien sur le fait que l’échange lui-même était correct. « Vérifié » et « validé » ne sont pas le même mot, même si beaucoup de marketing autour d’une IA vérifiable veut qu’on les fasse passer pour interchangeables.

Ce n’est pas une critique du travail d’ingénierie : ce que fait le TEE tient la route… Il vaut simplement la peine de distinguer les deux affirmations avant de croire qu’elles constituent une seule fonctionnalité.
@OpenGradient
#OPG
$VELVET

$MYX

$OPG
🔍 Verified Enough
100%
⚖️ Vetted Matters
0%
🤝 Need Both
0%
🤔 Not Sure
0%
1 Votes • Vote fermé
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