LinhNB
768 Publications
LinhNB
Trade régulièrement
5.8 an(s)
128 Suivis
219 Abonnés
901 J’aime
Publications
Tous
Citations
Voir la traduction
I spent the past two weeks trying to understand one question about GRVT: how can an exchange feel this close to a CEX while still letting users keep self-custody? What surprised me was that the answer wasn’t the Matching Engine. It was Cryptographic Order Batching. At first, I thought batching was simply about reducing gas costs. The more I looked at GRVT’s architecture, the less convincing that explanation became.
GRVT says its Matching Engine can process more than 600,000 orders per second with latency below 2 milliseconds. Ethereum was never designed to verify hundreds of thousands of transactions every second. If every order settled individually on-chain, execution would eventually be constrained by settlement. A faster Matching Engine would stop making the exchange meaningfully faster.
Cryptographic Order Batching doesn’t exist because Ethereum is slow. It exists because the Matching Engine and Ethereum operate under fundamentally different performance constraints. Orders are matched off-chain and represented by a single Zero-Knowledge proof. Ethereum verifies the resulting state instead of every individual order. That changed how I think about self-custody.
I had associated self-custody with complete execution transparency. GRVT separates those ideas. Users still control their collateral while settlement remains verifiable. What they lose is continuous visibility into every matching decision. That isn’t necessarily a weakness. It’s a different architectural choice. The system trades continuous observability of execution for cryptographic certainty about the final state.
I’m still not sure whether that distinction matters to most traders. If your priority is execution speed, self-custody, and verifiable settlement, probably not. If execution transparency matters most, it probably does. Cryptographic Order Batching no longer looks like a scaling technique to me. It looks like the mechanism that lets a Hybrid Exchange separate execution from verification without separating performance from trust.
@grvt_io #grvt $LAB
GRVT says its Matching Engine can process more than 600,000 orders per second with latency below 2 milliseconds. Ethereum was never designed to verify hundreds of thousands of transactions every second. If every order settled individually on-chain, execution would eventually be constrained by settlement. A faster Matching Engine would stop making the exchange meaningfully faster.
Cryptographic Order Batching doesn’t exist because Ethereum is slow. It exists because the Matching Engine and Ethereum operate under fundamentally different performance constraints. Orders are matched off-chain and represented by a single Zero-Knowledge proof. Ethereum verifies the resulting state instead of every individual order. That changed how I think about self-custody.
I had associated self-custody with complete execution transparency. GRVT separates those ideas. Users still control their collateral while settlement remains verifiable. What they lose is continuous visibility into every matching decision. That isn’t necessarily a weakness. It’s a different architectural choice. The system trades continuous observability of execution for cryptographic certainty about the final state.
I’m still not sure whether that distinction matters to most traders. If your priority is execution speed, self-custody, and verifiable settlement, probably not. If execution transparency matters most, it probably does. Cryptographic Order Batching no longer looks like a scaling technique to me. It looks like the mechanism that lets a Hybrid Exchange separate execution from verification without separating performance from trust.
@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
Voir la traduction
Ten operators do not necessarily mean ten independent decisions.
That is the assumption I began questioning while studying Newton Protocol. We often measure decentralization by counting operators, yet an authorization network is secured not by node count, but by how many independent paths can reach the same authorization decision.
In Newton, operators execute the same Rego Policy compiled to WASM against the same Intent and PolicyData before Execution proceeds. Replicating computation is easy. Demonstrating that independent participants reach the same authorization boundary is what actually builds trust.
That is why infrastructure diversity matters more than operator count. If most operators share the same cloud provider, they also share the same failure domain. A single infrastructure outage could disrupt Policy evaluation across many operators, making Authorization depend not only on Policy, but also on infrastructure outside the protocol.
To me, this is not a weakness of Newton. It is the standard an authorization protocol must satisfy. Once Policy becomes the gate between Intent and Execution, no single failure domain should be able to influence that gate. Otherwise, decentralization exists in topology, but not in Authorization.
Newton’s fail-closed design reflects exactly that philosophy. If Authorization cannot be established with sufficient confidence, Execution stops. The protocol deliberately prefers temporary unavailability over an authorization decision that cannot be trusted.
Viewed this way, operator diversity is no longer an operational optimization. It is part of Newton’s security model. The real question is not how many operators are online, but whether any single failure domain can decide when Authorization exists. If the answer is yes, the network has multiplied operators without truly multiplying trust.
@NewtonProtocol $NEWT #Newt $LAB
That is the assumption I began questioning while studying Newton Protocol. We often measure decentralization by counting operators, yet an authorization network is secured not by node count, but by how many independent paths can reach the same authorization decision.
In Newton, operators execute the same Rego Policy compiled to WASM against the same Intent and PolicyData before Execution proceeds. Replicating computation is easy. Demonstrating that independent participants reach the same authorization boundary is what actually builds trust.
That is why infrastructure diversity matters more than operator count. If most operators share the same cloud provider, they also share the same failure domain. A single infrastructure outage could disrupt Policy evaluation across many operators, making Authorization depend not only on Policy, but also on infrastructure outside the protocol.
To me, this is not a weakness of Newton. It is the standard an authorization protocol must satisfy. Once Policy becomes the gate between Intent and Execution, no single failure domain should be able to influence that gate. Otherwise, decentralization exists in topology, but not in Authorization.
Newton’s fail-closed design reflects exactly that philosophy. If Authorization cannot be established with sufficient confidence, Execution stops. The protocol deliberately prefers temporary unavailability over an authorization decision that cannot be trusted.
Viewed this way, operator diversity is no longer an operational optimization. It is part of Newton’s security model. The real question is not how many operators are online, but whether any single failure domain can decide when Authorization exists. If the answer is yes, the network has multiplied operators without truly multiplying trust.
@NewtonProtocol $NEWT #Newt $LAB
Voir la traduction
Some paths begin with only a few footprints. But after thousands have walked them, no one remembers why they were created. People keep following because they assume those before them already found the best way.
While reading about @NewtonProtocol is Policy Marketplace, I realized a policy may gain value the same way.
At first, I thought value came from quality. The more accurate, secure, and adaptable a policy is, the more protocols should adopt it. If so, Policy Marketplace would become a market where knowledge is rewarded.
But markets rarely work that way.
In technology, people often adopt trust before quality. Quality can create trust, but over time, trust begins to reinforce itself.
A policy used by thousands of protocols gains more audits, tooling, and implementation history. Developers may no longer choose it because they studied it carefully. They choose it because everyone else already has.
That is when value changes.
A policy is no longer valued only for its quality.
It is valued for the trust accumulated around it.
This is the paradox I see in Policy Marketplace. A good policy creates network effects. But once those effects become strong enough, they make better policies harder to replace. The market starts rewarding popularity more than improvement.
If that happens, Policy Marketplace will stop discovering the best policies.
It will preserve the most established ones.
That is the real challenge Newton must solve.
The marketplace should not only make policies reusable. It must also make trust continuously earnable. A policy should not stay valuable simply because it has existed for years. It should keep proving itself through performance, adaptability, and real-world results.
Otherwise, network effects will replace quality.
But if Newton can build a system where reputation is refreshed by evidence instead of inherited from history, Policy Marketplace will become more than a place to exchange policies.
It will become a market where trust itself competes.
And perhaps that is what blockchain has been missing.
$NEWT #Newt $LAB $TAC
While reading about @NewtonProtocol is Policy Marketplace, I realized a policy may gain value the same way.
At first, I thought value came from quality. The more accurate, secure, and adaptable a policy is, the more protocols should adopt it. If so, Policy Marketplace would become a market where knowledge is rewarded.
But markets rarely work that way.
In technology, people often adopt trust before quality. Quality can create trust, but over time, trust begins to reinforce itself.
A policy used by thousands of protocols gains more audits, tooling, and implementation history. Developers may no longer choose it because they studied it carefully. They choose it because everyone else already has.
That is when value changes.
A policy is no longer valued only for its quality.
It is valued for the trust accumulated around it.
This is the paradox I see in Policy Marketplace. A good policy creates network effects. But once those effects become strong enough, they make better policies harder to replace. The market starts rewarding popularity more than improvement.
If that happens, Policy Marketplace will stop discovering the best policies.
It will preserve the most established ones.
That is the real challenge Newton must solve.
The marketplace should not only make policies reusable. It must also make trust continuously earnable. A policy should not stay valuable simply because it has existed for years. It should keep proving itself through performance, adaptability, and real-world results.
Otherwise, network effects will replace quality.
But if Newton can build a system where reputation is refreshed by evidence instead of inherited from history, Policy Marketplace will become more than a place to exchange policies.
It will become a market where trust itself competes.
And perhaps that is what blockchain has been missing.
$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