LinhNB
768 Publications
LinhNB
Trade régulièrement
5.8 an(s)
128 Suivis
219 Abonnés
901 J’aime
Publications
Tous
Citations
J’ai passé les deux dernières semaines à essayer de comprendre une question au sujet de GRVT : comment une plateforme d’échange peut-elle sembler aussi proche d’un CEX tout en permettant aux utilisateurs de conserver leur auto‑garde ? Ce qui m’a surpris, c’est que la réponse n’était pas le Moteur de Correspondance. C’était l’Ordonnancement Cryptographique par Lots (Cryptographic Order Batching). Au début, je pensais que le batching servait simplement à réduire les coûts de gaz. Plus j’ai examiné l’architecture de GRVT, moins cette explication était convaincante.
GRVT affirme que son Moteur de Correspondance peut traiter plus de 600 000 ordres par seconde avec une latence inférieure à 2 millisecondes. Ethereum n’a jamais été conçu pour vérifier des centaines de milliers de transactions par seconde. Si chaque ordre était réglé individuellement on-chain, l’exécution serait éventuellement limitée par le règlement. Un Moteur de Correspondance plus rapide ne rendrait pas l’échange sensiblement plus rapide.
Le Batching d’Ordres Cryptographique n’existe pas parce qu’Ethereum est lent. Il existe parce que le Moteur de Correspondance et Ethereum fonctionnent sous des contraintes de performance fondamentalement différentes. Les ordres sont appariés hors chaîne et représentés par une seule preuve à divulgation nulle de connaissance (Zero-Knowledge). Ethereum vérifie ensuite l’état résultant plutôt que chaque ordre pris individuellement. Cela a changé ma façon de voir l’auto‑garde.
J’associais l’auto‑garde à une transparence d’exécution totale. GRVT dissocie ces idées. Les utilisateurs contrôlent toujours leur collatéral tandis que le règlement reste vérifiable. Ce qu’ils perdent, c’est la visibilité continue sur chaque décision d’appariement. Ce n’est pas forcément une faiblesse. C’est un choix architectural différent. Le système échange l’observabilité continue de l’exécution contre une certitude cryptographique concernant l’état final.
Je ne suis toujours pas sûr que cette distinction compte pour la plupart des traders. Si votre priorité est la vitesse d’exécution, l’auto‑garde et un règlement vérifiable, probablement non. Si la transparence de l’exécution est le plus important, alors oui. Le Batching d’Ordres Cryptographique ne ressemble plus à une technique de mise à l’échelle. Il ressemble plutôt au mécanisme qui permet à un échange hybride de séparer l’exécution de la vérification, sans séparer les performances de la confiance. @grvt_io #grvt $LAB
GRVT affirme que son Moteur de Correspondance peut traiter plus de 600 000 ordres par seconde avec une latence inférieure à 2 millisecondes. Ethereum n’a jamais été conçu pour vérifier des centaines de milliers de transactions par seconde. Si chaque ordre était réglé individuellement on-chain, l’exécution serait éventuellement limitée par le règlement. Un Moteur de Correspondance plus rapide ne rendrait pas l’échange sensiblement plus rapide.
Le Batching d’Ordres Cryptographique n’existe pas parce qu’Ethereum est lent. Il existe parce que le Moteur de Correspondance et Ethereum fonctionnent sous des contraintes de performance fondamentalement différentes. Les ordres sont appariés hors chaîne et représentés par une seule preuve à divulgation nulle de connaissance (Zero-Knowledge). Ethereum vérifie ensuite l’état résultant plutôt que chaque ordre pris individuellement. Cela a changé ma façon de voir l’auto‑garde.
J’associais l’auto‑garde à une transparence d’exécution totale. GRVT dissocie ces idées. Les utilisateurs contrôlent toujours leur collatéral tandis que le règlement reste vérifiable. Ce qu’ils perdent, c’est la visibilité continue sur chaque décision d’appariement. Ce n’est pas forcément une faiblesse. C’est un choix architectural différent. Le système échange l’observabilité continue de l’exécution contre une certitude cryptographique concernant l’état final.
Je ne suis toujours pas sûr que cette distinction compte pour la plupart des traders. Si votre priorité est la vitesse d’exécution, l’auto‑garde et un règlement vérifiable, probablement non. Si la transparence de l’exécution est le plus important, alors oui. Le Batching d’Ordres Cryptographique ne ressemble plus à une technique de mise à l’échelle. Il ressemble plutôt au mécanisme qui permet à un échange hybride de séparer l’exécution de la vérification, sans séparer les performances de la confiance. @grvt_io #grvt $LAB
Il y a un aspect du protocole Newton qui m’est resté en tête après la lecture de la documentation. Contrairement à ce que beaucoup supposent, le projet ne cherche pas vraiment à résoudre la confidentialité. Il modifie ce qu’une blockchain doit savoir pour établir la confiance.
Pendant des années, les blockchains ont reposé sur une hypothèse simple : la transparence crée la confiance. Pourtant, les informations les plus précieuses dans la finance — dossiers KYC, stratégies d’investissement, données d’entreprise et modèles internes de gestion du risque — ne peuvent jamais être rendues publiques. Si la confiance dépend de la divulgation d’informations sensibles, la blockchain aura toujours du mal à soutenir des agents IA, des RWA et la finance institutionnelle.
Le protocole Newton adopte une approche différente. La blockchain n’a pas besoin de savoir ce que contiennent les données. Elle doit seulement fournir la preuve que les données ont été utilisées conformément à la bonne politique, par la bonne autorité, et dans le bon contexte, avant qu’une action ne soit autorisée. Newton ne change pas la manière dont les données sont protégées. Il modifie ce que les blockchains doivent être en mesure de vérifier.
C’est pourquoi je ne considère pas les flux de travail préservant la confidentialité comme un simple cadre de chiffrement. Les Privacy Envelopes, le HPKE et la génération de clés distribuée ne sont que l’infrastructure. La vraie innovation, c’est qu’aucune partie ne peut transformer des données privées en une action autorisée sans avoir satisfait des politiques prédéfinies. Newton protège non seulement la confidentialité, mais aussi la légitimité même de l’action.
C’est également là que Newton se distingue de nombreuses solutions de confidentialité dans Web3. La plupart visent à masquer l’information. Newton se concentre sur la preuve que l’autorité a été exercée correctement. La blockchain n’a plus besoin de lire les données ; elle doit uniquement vérifier que le droit d’agir a été validé avant l’exécution.
Pour moi, c’est là la signification réelle des flux de travail préservant la confidentialité. La prochaine génération de blockchains ne sera peut-être plus jugée par la quantité de données qu’elle stocke, mais par le nombre de décisions légitimes qu’elle peut vérifier sans jamais accéder aux données sous-jacentes. Le protocole Newton ne fait pas que rajouter une couche de confidentialité. Il redéfinit la manière dont les blockchains créent la confiance.
@NewtonProtocol $NEWT #Newt $LAB
Pendant des années, les blockchains ont reposé sur une hypothèse simple : la transparence crée la confiance. Pourtant, les informations les plus précieuses dans la finance — dossiers KYC, stratégies d’investissement, données d’entreprise et modèles internes de gestion du risque — ne peuvent jamais être rendues publiques. Si la confiance dépend de la divulgation d’informations sensibles, la blockchain aura toujours du mal à soutenir des agents IA, des RWA et la finance institutionnelle.
Le protocole Newton adopte une approche différente. La blockchain n’a pas besoin de savoir ce que contiennent les données. Elle doit seulement fournir la preuve que les données ont été utilisées conformément à la bonne politique, par la bonne autorité, et dans le bon contexte, avant qu’une action ne soit autorisée. Newton ne change pas la manière dont les données sont protégées. Il modifie ce que les blockchains doivent être en mesure de vérifier.
C’est pourquoi je ne considère pas les flux de travail préservant la confidentialité comme un simple cadre de chiffrement. Les Privacy Envelopes, le HPKE et la génération de clés distribuée ne sont que l’infrastructure. La vraie innovation, c’est qu’aucune partie ne peut transformer des données privées en une action autorisée sans avoir satisfait des politiques prédéfinies. Newton protège non seulement la confidentialité, mais aussi la légitimité même de l’action.
C’est également là que Newton se distingue de nombreuses solutions de confidentialité dans Web3. La plupart visent à masquer l’information. Newton se concentre sur la preuve que l’autorité a été exercée correctement. La blockchain n’a plus besoin de lire les données ; elle doit uniquement vérifier que le droit d’agir a été validé avant l’exécution.
Pour moi, c’est là la signification réelle des flux de travail préservant la confidentialité. La prochaine génération de blockchains ne sera peut-être plus jugée par la quantité de données qu’elle stocke, mais par le nombre de décisions légitimes qu’elle peut vérifier sans jamais accéder aux données sous-jacentes. Le protocole Newton ne fait pas que rajouter une couche de confidentialité. Il redéfinit la manière dont les blockchains créent la confiance.
@NewtonProtocol $NEWT #Newt $LAB
Si l’autoconservation devait être traduite en justice, je pense qu’elle serait condamnée à tort.
L’accusation semble convaincante.
« Un trader peut encore être liquidé parce que le système calcule mal la marge. Alors, qu’est-ce que l’autoconservation protège réellement ? »
Plus j’ai étudié l’architecture de GRVT, plus j’ai compris que cette critique vise le mauvais composant.
L’autoconservation n’a jamais promis d’empêcher les liquidations incorrectes. Elle garantit simplement que vos actifs restent les vôtres, même si l’opérateur de l’échange devient insolvable ou agit de façon malveillante.
La marge est un problème tout à fait différent.
Un moteur de risque ne demande pas : « À qui appartiennent ces actifs ? » Il demande : « Compte tenu des conditions actuelles du marché, cette garantie est-elle encore suffisante pour soutenir la position ? » La vérification de la propriété et l’évaluation des risques résolvent des problèmes différents ; elles appartiennent donc à des couches architecturales distinctes.
Cela signifie qu’un trader peut rester le propriétaire légitime de chaque actif tout en étant liquidé, parce que l’évaluation de la garantie, la marge de maintenance ou le risque du portefeuille ont été calculés incorrectement. La liquidation est causée par la couche de risque — et non par la couche de custody (conservation).
Pour moi, c’est là l’insight architectural réel de GRVT.
Au lieu de construire un seul système responsable de tout, GRVT sépare les responsabilités. L’autoconservation protège contre le risque lié à l’opérateur, tandis que la marge unifiée et le moteur de risque déterminent si une position reste financièrement sûre. Chaque couche est propriétaire d’une catégorie différente d’échec.
Cette séparation change la façon dont la confiance fonctionne. Plutôt que de faire confiance à une seule boîte noire, les utilisateurs peuvent identifier quelle couche est responsable lorsqu’un problème survient.
Si je devais rendre un verdict, je trouverais l’autoconservation non coupable.
Pas parce qu’elle élimine tous les risques. Mais parce qu’elle n’a jamais prétendu le faire.
La vraie contribution de GRVT n’est pas de créer un système qui ne tombe jamais en panne. C’est de créer un système où chaque défaillance correspond clairement à une couche architecturale tenue pour responsable. Et, à mon avis, c’est cela qui rend une bourse hybride réellement plus digne de confiance.
@grvt_io #grvt $LAB $BEAT
L’accusation semble convaincante.
« Un trader peut encore être liquidé parce que le système calcule mal la marge. Alors, qu’est-ce que l’autoconservation protège réellement ? »
Plus j’ai étudié l’architecture de GRVT, plus j’ai compris que cette critique vise le mauvais composant.
L’autoconservation n’a jamais promis d’empêcher les liquidations incorrectes. Elle garantit simplement que vos actifs restent les vôtres, même si l’opérateur de l’échange devient insolvable ou agit de façon malveillante.
La marge est un problème tout à fait différent.
Un moteur de risque ne demande pas : « À qui appartiennent ces actifs ? » Il demande : « Compte tenu des conditions actuelles du marché, cette garantie est-elle encore suffisante pour soutenir la position ? » La vérification de la propriété et l’évaluation des risques résolvent des problèmes différents ; elles appartiennent donc à des couches architecturales distinctes.
Cela signifie qu’un trader peut rester le propriétaire légitime de chaque actif tout en étant liquidé, parce que l’évaluation de la garantie, la marge de maintenance ou le risque du portefeuille ont été calculés incorrectement. La liquidation est causée par la couche de risque — et non par la couche de custody (conservation).
Pour moi, c’est là l’insight architectural réel de GRVT.
Au lieu de construire un seul système responsable de tout, GRVT sépare les responsabilités. L’autoconservation protège contre le risque lié à l’opérateur, tandis que la marge unifiée et le moteur de risque déterminent si une position reste financièrement sûre. Chaque couche est propriétaire d’une catégorie différente d’échec.
Cette séparation change la façon dont la confiance fonctionne. Plutôt que de faire confiance à une seule boîte noire, les utilisateurs peuvent identifier quelle couche est responsable lorsqu’un problème survient.
Si je devais rendre un verdict, je trouverais l’autoconservation non coupable.
Pas parce qu’elle élimine tous les risques. Mais parce qu’elle n’a jamais prétendu le faire.
La vraie contribution de GRVT n’est pas de créer un système qui ne tombe jamais en panne. C’est de créer un système où chaque défaillance correspond clairement à une couche architecturale tenue pour responsable. Et, à mon avis, c’est cela qui rend une bourse hybride réellement plus digne de confiance.
@grvt_io #grvt $LAB $BEAT
Dix opérateurs ne signifient pas nécessairement dix décisions indépendantes.
C’est l’hypothèse que j’ai commencé à remettre en question en étudiant le protocole Newton. Nous mesurons souvent la décentralisation en comptant les opérateurs, mais un réseau d’autorisation est sécurisé non pas par le nombre de nœuds, mais par le nombre de chemins indépendants capables d’atteindre la même décision d’autorisation.
Dans Newton, les opérateurs exécutent la même politique Rego compilée en WASM sur le même Intent et le même PolicyData avant que l’exécution ne commence. Répliquer le calcul est facile. Démontrer que des participants indépendants atteignent la même limite d’autorisation, c’est ce qui construit réellement la confiance.
C’est pourquoi la diversité d’infrastructure compte plus que le nombre d’opérateurs. Si la plupart des opérateurs utilisent le même fournisseur de cloud, ils partagent aussi le même domaine d’échec. Une seule panne d’infrastructure peut perturber l’évaluation de la politique pour de nombreux opérateurs, de sorte que l’autorisation dépend non seulement de la politique, mais aussi d’une infrastructure située en dehors du protocole.
Pour moi, ce n’est pas une faiblesse de Newton. C’est l’exigence standard qu’un protocole d’autorisation doit satisfaire. Une fois que la politique devient la porte entre Intent et Execution, aucun domaine d’échec unique ne doit pouvoir influencer cette porte. Sinon, la décentralisation existe dans la topologie, mais pas dans l’autorisation.
Le design fail-closed (échec fermé) de Newton reflète exactement cette philosophie. Si l’autorisation ne peut pas être établie avec un niveau de confiance suffisant, l’exécution s’arrête. Le protocole privilégie volontairement une indisponibilité temporaire plutôt qu’une décision d’autorisation qui ne peut pas être approuvée.
En la considérant ainsi, la diversité des opérateurs n’est plus une simple optimisation opérationnelle. Elle fait partie du modèle de sécurité de Newton. La vraie question n’est pas le nombre d’opérateurs en ligne, mais de savoir si un seul domaine d’échec peut décider du moment où l’autorisation existe. Si la réponse est oui, le réseau a multiplié les opérateurs sans multiplier réellement la confiance.@NewtonProtocol $NEWT #Newt $LAB
C’est l’hypothèse que j’ai commencé à remettre en question en étudiant le protocole Newton. Nous mesurons souvent la décentralisation en comptant les opérateurs, mais un réseau d’autorisation est sécurisé non pas par le nombre de nœuds, mais par le nombre de chemins indépendants capables d’atteindre la même décision d’autorisation.
Dans Newton, les opérateurs exécutent la même politique Rego compilée en WASM sur le même Intent et le même PolicyData avant que l’exécution ne commence. Répliquer le calcul est facile. Démontrer que des participants indépendants atteignent la même limite d’autorisation, c’est ce qui construit réellement la confiance.
C’est pourquoi la diversité d’infrastructure compte plus que le nombre d’opérateurs. Si la plupart des opérateurs utilisent le même fournisseur de cloud, ils partagent aussi le même domaine d’échec. Une seule panne d’infrastructure peut perturber l’évaluation de la politique pour de nombreux opérateurs, de sorte que l’autorisation dépend non seulement de la politique, mais aussi d’une infrastructure située en dehors du protocole.
Pour moi, ce n’est pas une faiblesse de Newton. C’est l’exigence standard qu’un protocole d’autorisation doit satisfaire. Une fois que la politique devient la porte entre Intent et Execution, aucun domaine d’échec unique ne doit pouvoir influencer cette porte. Sinon, la décentralisation existe dans la topologie, mais pas dans l’autorisation.
Le design fail-closed (échec fermé) de Newton reflète exactement cette philosophie. Si l’autorisation ne peut pas être établie avec un niveau de confiance suffisant, l’exécution s’arrête. Le protocole privilégie volontairement une indisponibilité temporaire plutôt qu’une décision d’autorisation qui ne peut pas être approuvée.
En la considérant ainsi, la diversité des opérateurs n’est plus une simple optimisation opérationnelle. Elle fait partie du modèle de sécurité de Newton. La vraie question n’est pas le nombre d’opérateurs en ligne, mais de savoir si un seul domaine d’échec peut décider du moment où l’autorisation existe. Si la réponse est oui, le réseau a multiplié les opérateurs sans multiplier réellement la confiance.@NewtonProtocol $NEWT #Newt $LAB
Certaines trajectoires commencent avec seulement quelques traces. Mais après que des milliers les ont parcourues, plus personne ne se souvient pourquoi elles ont été créées. Les gens continuent de les suivre, parce qu’ils supposent que ceux qui les ont précédés ont déjà trouvé le meilleur chemin.
En lisant à propos de @NewtonProtocol is Policy Marketplace, j’ai réalisé qu’une politique peut gagner de la valeur de la même manière.
Au début, je pensais que la valeur venait de la qualité. Plus une politique est précise, sécurisée et adaptable, plus de protocoles devraient l’adopter. Si c’était le cas, Policy Marketplace deviendrait un marché où la connaissance serait récompensée.
Mais les marchés fonctionnent rarement ainsi.
Dans la technologie, les gens adoptent souvent la confiance avant la qualité. La qualité peut créer la confiance, mais avec le temps, la confiance commence à se renforcer d’elle-même.
Une politique utilisée par des milliers de protocoles obtient davantage d’audits, d’outils et d’historique de mise en œuvre. Les développeurs ne la choisissent peut-être plus parce qu’ils l’ont étudiée attentivement. Ils la choisissent parce que tout le monde l’a déjà.
C’est à ce moment-là que la valeur change.
Une politique n’est alors plus appréciée uniquement pour sa qualité.
Elle est appréciée pour la confiance accumulée autour d’elle.
C’est le paradoxe que je vois dans Policy Marketplace. Une bonne politique crée des effets de réseau. Mais une fois que ces effets deviennent suffisamment forts, ils rendent plus difficile le remplacement par de meilleures politiques. Le marché commence à récompenser davantage la popularité que l’amélioration.
Si cela se produit, Policy Marketplace cessera de découvrir les meilleures politiques.
Il en préservera simplement les plus établies.
C’est le vrai défi que Newton doit relever.
Le marché ne devrait pas seulement rendre les politiques réutilisables. Il doit aussi faire en sorte que la confiance puisse être gagnée en continu. Une politique ne devrait pas rester précieuse uniquement parce qu’elle existe depuis des années. Elle doit continuer à prouver sa valeur grâce aux performances, à l’adaptabilité et à des résultats concrets.
Sinon, les effets de réseau remplaceront la qualité.
Mais si Newton peut construire un système où la réputation est remise à jour par des preuves, plutôt que d’être héritée de l’histoire, alors Policy Marketplace deviendra plus qu’un simple lieu d’échange de politiques.
Cela deviendra un marché où c’est la confiance elle-même qui se mesure et qui concurrence.
Et peut-être que c’est précisément ce qui manquait à la blockchain.
$NEWT #Newt $LAB $TAC
En lisant à propos de @NewtonProtocol is Policy Marketplace, j’ai réalisé qu’une politique peut gagner de la valeur de la même manière.
Au début, je pensais que la valeur venait de la qualité. Plus une politique est précise, sécurisée et adaptable, plus de protocoles devraient l’adopter. Si c’était le cas, Policy Marketplace deviendrait un marché où la connaissance serait récompensée.
Mais les marchés fonctionnent rarement ainsi.
Dans la technologie, les gens adoptent souvent la confiance avant la qualité. La qualité peut créer la confiance, mais avec le temps, la confiance commence à se renforcer d’elle-même.
Une politique utilisée par des milliers de protocoles obtient davantage d’audits, d’outils et d’historique de mise en œuvre. Les développeurs ne la choisissent peut-être plus parce qu’ils l’ont étudiée attentivement. Ils la choisissent parce que tout le monde l’a déjà.
C’est à ce moment-là que la valeur change.
Une politique n’est alors plus appréciée uniquement pour sa qualité.
Elle est appréciée pour la confiance accumulée autour d’elle.
C’est le paradoxe que je vois dans Policy Marketplace. Une bonne politique crée des effets de réseau. Mais une fois que ces effets deviennent suffisamment forts, ils rendent plus difficile le remplacement par de meilleures politiques. Le marché commence à récompenser davantage la popularité que l’amélioration.
Si cela se produit, Policy Marketplace cessera de découvrir les meilleures politiques.
Il en préservera simplement les plus établies.
C’est le vrai défi que Newton doit relever.
Le marché ne devrait pas seulement rendre les politiques réutilisables. Il doit aussi faire en sorte que la confiance puisse être gagnée en continu. Une politique ne devrait pas rester précieuse uniquement parce qu’elle existe depuis des années. Elle doit continuer à prouver sa valeur grâce aux performances, à l’adaptabilité et à des résultats concrets.
Sinon, les effets de réseau remplaceront la qualité.
Mais si Newton peut construire un système où la réputation est remise à jour par des preuves, plutôt que d’être héritée de l’histoire, alors Policy Marketplace deviendra plus qu’un simple lieu d’échange de politiques.
Cela deviendra un marché où c’est la confiance elle-même qui se mesure et qui concurrence.
Et peut-être que c’est précisément ce qui manquait à la blockchain.
$NEWT #Newt $LAB $TAC
Newton ne gère pas le temps. Il gère la durée pendant laquelle une décision peut encore être considérée comme fiable.
En lisant la documentation de Newton, j’ai remarqué un détail facile à négliger. La plupart des discussions se concentrent sur les politiques, Rego et PolicyData, mais posent rarement une question plus simple : pendant combien de temps une décision d’autorisation doit-elle rester fiable ?
Les blockchains traditionnelles traitent l’autorisation comme un droit. Une fois validée, une décision est généralement considérée comme valable jusqu’à son exécution. Newton l’aborde différemment. Chaque autorisation résulte de l’évaluation d’un ensemble précis de données à un moment précis, et non d’une vérité qui devrait rester valable pour toujours.
Cette idée apparaît tout au long de l’architecture. Les paramètres statiques dans data.params peuvent rester inchangés pendant des mois, tandis que les observations provenant de PolicyData peuvent changer à chaque bloc. Une politique évalue tout cela ensemble, même si ces éléments évoluent selon des calendriers différents. Une autorisation dépend donc non seulement de la logique correcte, mais aussi du fait que l’information reflète encore l’état actuel du monde.
C’est pourquoi je ne vois pas la « durée de vie de la décision » comme un simple mécanisme d’expiration. Elle reflète une hypothèse plus profonde : chaque décision commence à vieillir dès sa création. Non pas parce que la politique est erronée, mais parce que les marchés évoluent, les soldes changent et les observations externes continuent de se transformer.
Newton n’essaie pas de prolonger la durée de vie d’une autorisation. Au lieu de cela, il limite la durée pendant laquelle le système doit faire confiance à une décision antérieure avant de l’évaluer à nouveau avec des observations fraîches.
C’est peut-être pour cela que le temps n’est pas le véritable centre d’intérêt de l’architecture de Newton.
Ce que Newton gère en réalité, c’est la durée pendant laquelle une décision reste digne de confiance.
Une politique parfaitement rédigée peut pourtant produire un résultat incorrect si le monde qu’elle a évalué a déjà changé. Dans Newton, la sécurité ne vient pas seulement du fait de prendre la bonne décision, mais aussi de savoir quand cette décision ne doit plus être considérée comme fiable.
@NewtonProtocol #Newt $NEWT $LAB $BEE
En lisant la documentation de Newton, j’ai remarqué un détail facile à négliger. La plupart des discussions se concentrent sur les politiques, Rego et PolicyData, mais posent rarement une question plus simple : pendant combien de temps une décision d’autorisation doit-elle rester fiable ?
Les blockchains traditionnelles traitent l’autorisation comme un droit. Une fois validée, une décision est généralement considérée comme valable jusqu’à son exécution. Newton l’aborde différemment. Chaque autorisation résulte de l’évaluation d’un ensemble précis de données à un moment précis, et non d’une vérité qui devrait rester valable pour toujours.
Cette idée apparaît tout au long de l’architecture. Les paramètres statiques dans data.params peuvent rester inchangés pendant des mois, tandis que les observations provenant de PolicyData peuvent changer à chaque bloc. Une politique évalue tout cela ensemble, même si ces éléments évoluent selon des calendriers différents. Une autorisation dépend donc non seulement de la logique correcte, mais aussi du fait que l’information reflète encore l’état actuel du monde.
C’est pourquoi je ne vois pas la « durée de vie de la décision » comme un simple mécanisme d’expiration. Elle reflète une hypothèse plus profonde : chaque décision commence à vieillir dès sa création. Non pas parce que la politique est erronée, mais parce que les marchés évoluent, les soldes changent et les observations externes continuent de se transformer.
Newton n’essaie pas de prolonger la durée de vie d’une autorisation. Au lieu de cela, il limite la durée pendant laquelle le système doit faire confiance à une décision antérieure avant de l’évaluer à nouveau avec des observations fraîches.
C’est peut-être pour cela que le temps n’est pas le véritable centre d’intérêt de l’architecture de Newton.
Ce que Newton gère en réalité, c’est la durée pendant laquelle une décision reste digne de confiance.
Une politique parfaitement rédigée peut pourtant produire un résultat incorrect si le monde qu’elle a évalué a déjà changé. Dans Newton, la sécurité ne vient pas seulement du fait de prendre la bonne décision, mais aussi de savoir quand cette décision ne doit plus être considérée comme fiable.
@NewtonProtocol #Newt $NEWT $LAB $BEE
La blockchain résout un problème fondamental : préserver ce qui s’est passé. Une fois qu’une transaction est confirmée, l’état devient immuable.
Mais @NewtonProtocol révèle une limite plus profonde : la blockchain préserve le résultat, pas toujours le raisonnement qui y a conduit.
Une transaction peut être valide selon la logique du contrat intelligent, mais la décision qui l’autorise n’est peut-être plus justifiée dans des conditions de marché, des données ou un état qui évoluent.
Cela crée un fossé entre la justesse de l’exécution et la légitimité de la décision.
La blockchain traditionnelle demande :
« Cette transaction est-elle valide selon le code ? »
Newton demande :
« La décision derrière cette transaction est-elle valide selon l’intention, la politique et l’état à cet instant ? »
C’est la base du Decision-Centric Security Model.
Newton ne supprime pas l’immutabilité. Il sépare ce qui doit rester définitif de ce qui doit évoluer.
L’exécution nécessite une finalité.
La logique décisionnelle nécessite une adaptabilité.
C’est pourquoi Newton introduit une couche de politique :
Intention - Politique - Décision - Exécution
L’intention définit l’objectif. La politique définit la limite d’autorisation. La décision vérifie si l’exécution reste alignée avec l’intention.
Le problème le plus difficile n’est pas de changer la politique. C’est de préserver la légitimité de la décision dans le temps.
Une décision dépend de la version de la politique, de l’état, des données d’oracle et du contexte. Sans ces éléments, un système peut prouver qu’une transaction a eu lieu, mais ne peut pas expliquer pourquoi elle a été approuvée.
C’est là que la gestion des versions de politique, la provenance des décisions, l’autorisation avec état et la reproductibilité des décisions deviennent essentielles.
Elles permettent la traçabilité de la décision : reconstituer le cheminement du raisonnement qui a conduit à l’autorisation.
Newton introduit un concept plus profond : le raisonnement immuable.
La blockchain a rendu l’état final immuable. Newton rend le contexte de décision vérifiable dans le temps.
L’avenir de la finance décentralisée ne dépendra pas seulement d’une exécution immuable.
Il dépendra aussi du fait que les décisions restent explicables, reproductibles et dignes de confiance à mesure que les systèmes évoluent.
Le protocole Newton ne rend pas la blockchain moins immuable.
Il rend le changement plus responsable.
$NEWT #Newt $LAB $EVAA
Mais @NewtonProtocol révèle une limite plus profonde : la blockchain préserve le résultat, pas toujours le raisonnement qui y a conduit.
Une transaction peut être valide selon la logique du contrat intelligent, mais la décision qui l’autorise n’est peut-être plus justifiée dans des conditions de marché, des données ou un état qui évoluent.
Cela crée un fossé entre la justesse de l’exécution et la légitimité de la décision.
La blockchain traditionnelle demande :
« Cette transaction est-elle valide selon le code ? »
Newton demande :
« La décision derrière cette transaction est-elle valide selon l’intention, la politique et l’état à cet instant ? »
C’est la base du Decision-Centric Security Model.
Newton ne supprime pas l’immutabilité. Il sépare ce qui doit rester définitif de ce qui doit évoluer.
L’exécution nécessite une finalité.
La logique décisionnelle nécessite une adaptabilité.
C’est pourquoi Newton introduit une couche de politique :
Intention - Politique - Décision - Exécution
L’intention définit l’objectif. La politique définit la limite d’autorisation. La décision vérifie si l’exécution reste alignée avec l’intention.
Le problème le plus difficile n’est pas de changer la politique. C’est de préserver la légitimité de la décision dans le temps.
Une décision dépend de la version de la politique, de l’état, des données d’oracle et du contexte. Sans ces éléments, un système peut prouver qu’une transaction a eu lieu, mais ne peut pas expliquer pourquoi elle a été approuvée.
C’est là que la gestion des versions de politique, la provenance des décisions, l’autorisation avec état et la reproductibilité des décisions deviennent essentielles.
Elles permettent la traçabilité de la décision : reconstituer le cheminement du raisonnement qui a conduit à l’autorisation.
Newton introduit un concept plus profond : le raisonnement immuable.
La blockchain a rendu l’état final immuable. Newton rend le contexte de décision vérifiable dans le temps.
L’avenir de la finance décentralisée ne dépendra pas seulement d’une exécution immuable.
Il dépendra aussi du fait que les décisions restent explicables, reproductibles et dignes de confiance à mesure que les systèmes évoluent.
Le protocole Newton ne rend pas la blockchain moins immuable.
Il rend le changement plus responsable.
$NEWT #Newt $LAB $EVAA
Ce qui m’a fait changer d’avis sur @NewtonProtocol : ce n’est pas un AI Agent.
Au début, je pensais que @NewtonProtocol était un protocole qui permet à l’IA d’exécuter des tâches on-chain de manière plus sûre.
Mais après avoir lu la documentation, je me suis rendu compte que l’IA n’est que la partie visible. Le cœur de Newton se trouve dans l’autorisation.
Newton ne commence pas par la question « À quel point l’agent est-il intelligent ? »
Au contraire : « Qu’est-ce que l’agent a le droit de faire, dans quelles limites, et comment prouver qu’il ne dépasse pas les pouvoirs qui lui ont été accordés ? »
C’est pour cela que zkPermissions est devenu central dans l’architecture.
Les utilisateurs ne donnent pas tous les pouvoirs à l’agent. Les droits sont définis par une policy : quels actifs peuvent être utilisés, dans quelles limites, quelles conditions doivent être remplies, et quand l’autorisation prend fin.
L’agent ne possède pas l’autorité.
Il ne fait de l’exécution déléguée que tant que l’action reste dans la policy vérifiée.
C’est le plus grand point de différence.
La blockchain traditionnelle demande : « Cette transaction est-elle valide ? »
Newton ajoute : « Le droit qui a permis de créer cette transaction est-il encore valide ? »
L’un protège l’exactitude de la transaction.
L’autre protège les limites du pouvoir de représentation.
Donc, je ne considère pas zkPermissions comme une simple fonctionnalité de sécurité pour l’IA.
C’est une façon pour Newton de rendre l’autorisation définissable par policy, bornée par des conditions et vérifiée grâce à des preuves de connaissance zéro.
Il ne s’agit pas de résoudre tous les problèmes de l’IA.
Ils se concentrent sur un problème de base plus profond :
Comment des droits délégués sur la blockchain peuvent-ils être vérifiés plutôt que de reposer uniquement sur la confiance ?
Si l’IA devient la nouvelle couche d’exécution de Web3, le contrôle des droits de l’agent ne sera plus une fonctionnalité secondaire.
Cela deviendra une infrastructure.
#Newt $NEWT $LAB $BEAT
Au début, je pensais que @NewtonProtocol était un protocole qui permet à l’IA d’exécuter des tâches on-chain de manière plus sûre.
Mais après avoir lu la documentation, je me suis rendu compte que l’IA n’est que la partie visible. Le cœur de Newton se trouve dans l’autorisation.
Newton ne commence pas par la question « À quel point l’agent est-il intelligent ? »
Au contraire : « Qu’est-ce que l’agent a le droit de faire, dans quelles limites, et comment prouver qu’il ne dépasse pas les pouvoirs qui lui ont été accordés ? »
C’est pour cela que zkPermissions est devenu central dans l’architecture.
Les utilisateurs ne donnent pas tous les pouvoirs à l’agent. Les droits sont définis par une policy : quels actifs peuvent être utilisés, dans quelles limites, quelles conditions doivent être remplies, et quand l’autorisation prend fin.
L’agent ne possède pas l’autorité.
Il ne fait de l’exécution déléguée que tant que l’action reste dans la policy vérifiée.
C’est le plus grand point de différence.
La blockchain traditionnelle demande : « Cette transaction est-elle valide ? »
Newton ajoute : « Le droit qui a permis de créer cette transaction est-il encore valide ? »
L’un protège l’exactitude de la transaction.
L’autre protège les limites du pouvoir de représentation.
Donc, je ne considère pas zkPermissions comme une simple fonctionnalité de sécurité pour l’IA.
C’est une façon pour Newton de rendre l’autorisation définissable par policy, bornée par des conditions et vérifiée grâce à des preuves de connaissance zéro.
Il ne s’agit pas de résoudre tous les problèmes de l’IA.
Ils se concentrent sur un problème de base plus profond :
Comment des droits délégués sur la blockchain peuvent-ils être vérifiés plutôt que de reposer uniquement sur la confiance ?
Si l’IA devient la nouvelle couche d’exécution de Web3, le contrôle des droits de l’agent ne sera plus une fonctionnalité secondaire.
Cela deviendra une infrastructure.
#Newt $NEWT $LAB $BEAT
Je me suis une fois mépris sur la manière dont @NewtonProtocol repose réellement sur le consensus
Pendant longtemps, je pensais que Newton Protocol était purement technique : il hérite simplement du consensus de la chaîne sous-jacente. Si la chaîne est sûre, Newton est sûr. Cette formulation paraît raisonnable, mais plus j’ai observé l’automatisation réelle en pratique, plus j’ai compris qu’elle passait à côté de quelque chose d’important, plus que la sécurité elle-même : le temps.
L’automatisation ne vit pas dans « la vérité ultime ». Elle vit dans la fenêtre, avant que cette vérité ne devienne définitive. Un intent ne peut pas attendre indéfiniment une finalité absolue, car à ce moment-là, l’opportunité économique a déjà disparu. Ainsi, Newton Protocol, même s’il ne l’énonce jamais explicitement, suppose que le consensus de la chaîne sous-jacente se comporte de façon suffisamment prévisible pour que le temps reste exploitable. Ce n’est pas une hypothèse sur la justesse, mais sur la latence et la régularité de la finalité.
Voici l’angle rarement discuté : chaque intent sur Newton Protocol est effectivement un pari sur la distribution des reorgs. Quand vous choisissez d’attendre N blocs, vous dites implicitement que les reorgs plus profonds que N blocs sont assez rares pour être acceptables. La documentation mentionne les rollbacks sur les reorgs, mais elle ne dit pas que toute la « part alpha » de l’automatisation vient du fait que ces rollbacks sont suffisamment rares. Quand les reorgs deviennent imprévisibles, l’automatisation ne devient pas « fausse » — elle devient économiquement insignifiante.
Cela m’a amené à une autre idée fausse que j’ai longtemps conservée. Newton Protocol n’est pas réellement neutre vis-à-vis de la chaîne sous-jacente. Il ne choisit pas les forks, c’est vrai. Mais il force les builders à évaluer la qualité du consensus à travers la façon dont ils utilisent le temps. Attendre plus longtemps achète de la sécurité ; agir plus tôt achète de l’avantage. Aucune couche en dessous n’absorbe ce compromis à votre place.
Donc la vraie question, lors du déploiement de Newton Protocol, n’est pas « cette chaîne a-t-elle une finalité ? »
La vraie question est : la finalité de cette chaîne est-elle suffisamment stable pour que le temps lui-même puisse être traité comme un actif ?
Sinon, Newton continuera à fonctionner, mais l’automatisation ne sera plus qu’une exécution cron plus élégante.
@NewtonProtocol $NEWT #Newt $LAB $BEAT
Pendant longtemps, je pensais que Newton Protocol était purement technique : il hérite simplement du consensus de la chaîne sous-jacente. Si la chaîne est sûre, Newton est sûr. Cette formulation paraît raisonnable, mais plus j’ai observé l’automatisation réelle en pratique, plus j’ai compris qu’elle passait à côté de quelque chose d’important, plus que la sécurité elle-même : le temps.
L’automatisation ne vit pas dans « la vérité ultime ». Elle vit dans la fenêtre, avant que cette vérité ne devienne définitive. Un intent ne peut pas attendre indéfiniment une finalité absolue, car à ce moment-là, l’opportunité économique a déjà disparu. Ainsi, Newton Protocol, même s’il ne l’énonce jamais explicitement, suppose que le consensus de la chaîne sous-jacente se comporte de façon suffisamment prévisible pour que le temps reste exploitable. Ce n’est pas une hypothèse sur la justesse, mais sur la latence et la régularité de la finalité.
Voici l’angle rarement discuté : chaque intent sur Newton Protocol est effectivement un pari sur la distribution des reorgs. Quand vous choisissez d’attendre N blocs, vous dites implicitement que les reorgs plus profonds que N blocs sont assez rares pour être acceptables. La documentation mentionne les rollbacks sur les reorgs, mais elle ne dit pas que toute la « part alpha » de l’automatisation vient du fait que ces rollbacks sont suffisamment rares. Quand les reorgs deviennent imprévisibles, l’automatisation ne devient pas « fausse » — elle devient économiquement insignifiante.
Cela m’a amené à une autre idée fausse que j’ai longtemps conservée. Newton Protocol n’est pas réellement neutre vis-à-vis de la chaîne sous-jacente. Il ne choisit pas les forks, c’est vrai. Mais il force les builders à évaluer la qualité du consensus à travers la façon dont ils utilisent le temps. Attendre plus longtemps achète de la sécurité ; agir plus tôt achète de l’avantage. Aucune couche en dessous n’absorbe ce compromis à votre place.
Donc la vraie question, lors du déploiement de Newton Protocol, n’est pas « cette chaîne a-t-elle une finalité ? »
La vraie question est : la finalité de cette chaîne est-elle suffisamment stable pour que le temps lui-même puisse être traité comme un actif ?
Sinon, Newton continuera à fonctionner, mais l’automatisation ne sera plus qu’une exécution cron plus élégante.
@NewtonProtocol $NEWT #Newt $LAB $BEAT
Hier, j’ai croisé Ly alors que nous nous promenions dehors. Nous nous rencontrons souvent comme ça pour parler du protocole Newton. Ly m’a demandé :
« Pourquoi le @NewtonProtocol choisit-il le conflit au lieu de le résoudre tôt ? »
Je n’ai pas répondu immédiatement. Parce que la question elle-même donnait l’impression qu’elle supposait quelque chose qui n’existe pas réellement dans le système : l’idée que le conflit serait une chose que l’on peut choisir de conserver ou de supprimer. Dans le protocole Newton, ce n’est pas comme ça.
Dans ce système, l’inférence ne mène pas directement à une conclusion. Elle génère plusieurs hypothèses à la fois, qui se chevauchent au départ plutôt que d’exister comme des possibilités séparées. Ce que l’on appelle « conflit », c’est simplement un état d’enchevêtrement non résolu, où aucune issue unique n’est devenue assez distincte pour se suffire à elle-même.
« Résoudre » sonne comme une étape active, mais dans le protocole Newton, ce n’est pas toujours autorisé. Cela ne se produit que lorsque le fait de sélectionner une branche ne déforme pas la structure globale qui se trouve derrière elle. Si cette condition n’est pas remplie, alors « résoudre tôt » n’est pas un « progrès plus rapide » : c’est juste un engagement prématuré.
Le point clé, c’est que le protocole Newton ne traite pas le conflit comme quelque chose à corriger. Il ne le traite que comme un signal : ce n’est pas encore le moment de décider. Il n’existe pas de mécanisme distinct pour éliminer le conflit, parce que le conflit disparaît naturellement dès que les conditions nécessaires à une conclusion valide sont réunies.
Autrement dit, il adopte cette approche parce qu’il ne privilégie pas la vitesse de la conclusion. Il privilégie l’exactitude du timing. Si vous résolvez trop tôt, le résultat peut encore sembler correct localement, mais il ne fait que refléter une tranche étroite de la structure complète.
En repensant à la question de Ly, j’ai compris que le protocole Newton ne se situe pas entre le conflit et la résolution. Il se situe avant les deux. Il ne s’intéresse qu’à une chose : le moment où un système est réellement autorisé à transformer plusieurs possibilités en une seule issue définitivement engagée. Et tant que ce moment n’arrive pas, le conflit n’est pas un problème : c’est simplement le signe que le système n’est pas encore prêt à faire confiance à une quelconque conclusion.
@NewtonProtocol $NEWT #Newt $LAB $GAIA
« Pourquoi le @NewtonProtocol choisit-il le conflit au lieu de le résoudre tôt ? »
Je n’ai pas répondu immédiatement. Parce que la question elle-même donnait l’impression qu’elle supposait quelque chose qui n’existe pas réellement dans le système : l’idée que le conflit serait une chose que l’on peut choisir de conserver ou de supprimer. Dans le protocole Newton, ce n’est pas comme ça.
Dans ce système, l’inférence ne mène pas directement à une conclusion. Elle génère plusieurs hypothèses à la fois, qui se chevauchent au départ plutôt que d’exister comme des possibilités séparées. Ce que l’on appelle « conflit », c’est simplement un état d’enchevêtrement non résolu, où aucune issue unique n’est devenue assez distincte pour se suffire à elle-même.
« Résoudre » sonne comme une étape active, mais dans le protocole Newton, ce n’est pas toujours autorisé. Cela ne se produit que lorsque le fait de sélectionner une branche ne déforme pas la structure globale qui se trouve derrière elle. Si cette condition n’est pas remplie, alors « résoudre tôt » n’est pas un « progrès plus rapide » : c’est juste un engagement prématuré.
Le point clé, c’est que le protocole Newton ne traite pas le conflit comme quelque chose à corriger. Il ne le traite que comme un signal : ce n’est pas encore le moment de décider. Il n’existe pas de mécanisme distinct pour éliminer le conflit, parce que le conflit disparaît naturellement dès que les conditions nécessaires à une conclusion valide sont réunies.
Autrement dit, il adopte cette approche parce qu’il ne privilégie pas la vitesse de la conclusion. Il privilégie l’exactitude du timing. Si vous résolvez trop tôt, le résultat peut encore sembler correct localement, mais il ne fait que refléter une tranche étroite de la structure complète.
En repensant à la question de Ly, j’ai compris que le protocole Newton ne se situe pas entre le conflit et la résolution. Il se situe avant les deux. Il ne s’intéresse qu’à une chose : le moment où un système est réellement autorisé à transformer plusieurs possibilités en une seule issue définitivement engagée. Et tant que ce moment n’arrive pas, le conflit n’est pas un problème : c’est simplement le signe que le système n’est pas encore prêt à faire confiance à une quelconque conclusion.
@NewtonProtocol $NEWT #Newt $LAB $GAIA
J’ai d’abord lu « exécution prévisible » dans le @NewtonProtocol docs et ma première réaction n’a pas été très positive. J’avais l’impression que le système cherchait à contraindre ce que l’avenir est autorisé à être. Il y avait quelque chose de trop rigide là-dedans, comme si la possibilité était préfiltrée.
Mais cette réaction n’a pas vraiment résisté à une lecture plus attentive. Le but du protocole Newton n’est pas de limiter les résultats : c’est de supprimer, à la base, le besoin de confiance interpersonnelle. Une fois que l’on part du principe que les participants ne se font pas confiance, c’est au système de porter cette charge.
Dans les systèmes d’exécution « classiques », chaque action crée de l’incertitude quant à son résultat. On ne se contente pas de demander « est-ce que ça tourne », on se demande aussi « est-ce que je peux faire confiance à ce que j’obtiendrai une fois que c’est exécuté ». C’est cette deuxième question qui fait le plus souvent dérailler la coordination, et non l’exécution elle-même.
« Exécution prévisible » déplace cette dépendance vers la structure. Au lieu de faire confiance aux acteurs, on fait confiance à une couche de règles partagée qui définit quels résultats sont valides. Si l’action respecte les règles, alors le résultat n’est plus une affaire de croyance : c’est simplement une vérification.
Mais ce changement s’accompagne d’une tension propre, et il est facile de la rater au début. À partir du moment où tout doit passer par une grammaire partagée, tout ce qui ne peut pas y être exprimé devient invisible par défaut. Pas forcément faux, ni impossible : simplement non reconnu.
Malgré tout, je ne pense pas que l’objectif ici soit le contrôle ou la restriction. Cela ressemble davantage à une tentative de rendre la coordination possible dans des environnements où la confiance manque structurellement. Le système ne rétrécit pas l’avenir : il cherche plutôt à rendre l’avenir collectivement lisible.
Vu sous cet angle, le protocole Newton concerne moins le fait de façonner ce qui peut arriver que la définition de ce qui peut être convenu comme s’étant produit correctement. Il réduit le coût de l’accord, même si cela signifie que tout ce qui est nouveau n’est pas immédiatement compris. Cet arbitrage constitue probablement le véritable espace de conception ici.
@NewtonProtocol $NEWT #Newt $BAS $NEX
Mais cette réaction n’a pas vraiment résisté à une lecture plus attentive. Le but du protocole Newton n’est pas de limiter les résultats : c’est de supprimer, à la base, le besoin de confiance interpersonnelle. Une fois que l’on part du principe que les participants ne se font pas confiance, c’est au système de porter cette charge.
Dans les systèmes d’exécution « classiques », chaque action crée de l’incertitude quant à son résultat. On ne se contente pas de demander « est-ce que ça tourne », on se demande aussi « est-ce que je peux faire confiance à ce que j’obtiendrai une fois que c’est exécuté ». C’est cette deuxième question qui fait le plus souvent dérailler la coordination, et non l’exécution elle-même.
« Exécution prévisible » déplace cette dépendance vers la structure. Au lieu de faire confiance aux acteurs, on fait confiance à une couche de règles partagée qui définit quels résultats sont valides. Si l’action respecte les règles, alors le résultat n’est plus une affaire de croyance : c’est simplement une vérification.
Mais ce changement s’accompagne d’une tension propre, et il est facile de la rater au début. À partir du moment où tout doit passer par une grammaire partagée, tout ce qui ne peut pas y être exprimé devient invisible par défaut. Pas forcément faux, ni impossible : simplement non reconnu.
Malgré tout, je ne pense pas que l’objectif ici soit le contrôle ou la restriction. Cela ressemble davantage à une tentative de rendre la coordination possible dans des environnements où la confiance manque structurellement. Le système ne rétrécit pas l’avenir : il cherche plutôt à rendre l’avenir collectivement lisible.
Vu sous cet angle, le protocole Newton concerne moins le fait de façonner ce qui peut arriver que la définition de ce qui peut être convenu comme s’étant produit correctement. Il réduit le coût de l’accord, même si cela signifie que tout ce qui est nouveau n’est pas immédiatement compris. Cet arbitrage constitue probablement le véritable espace de conception ici.
@NewtonProtocol $NEWT #Newt $BAS $NEX
Connectez-vous pour découvrir plus de contenu