LinhNB
768 投稿
LinhNB
高頻度トレーダー
5.8年
128 フォロー
219 フォロワー
901 いいね
投稿
すべて
引用
翻訳参照
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
翻訳参照
There is one aspect of Newton Protocol that stayed with me after reading the documentation. Contrary to what many assume, the project is not really trying to solve privacy. It is changing what a blockchain needs to know to establish trust.
For years, blockchains have relied on a simple assumption: transparency creates trust. Yet the most valuable information in finance - KYC records, investment strategies, corporate data, and internal risk models can never be made public. If trust depends on exposing sensitive information, blockchain will always struggle to support AI agents, RWAs, and institutional finance.
Newton Protocol takes a different approach. The blockchain does not need to know what the data contains. It only needs proof that the data was used under the correct policy, by the correct authority, and in the correct context before an action was authorized. Newton is not changing how data is protected. It is changing what blockchains are required to verify.
That is why I do not see Privacy-Preserving Workflows as merely an encryption framework. Privacy Envelopes, HPKE, and Distributed Key Generation are only the infrastructure. The real innovation is that no single party can transform private data into an authorized action without satisfying predefined policies. Newton protects not only confidentiality, but the legitimacy of action itself.
This is also where Newton differs from many privacy solutions in Web3. Most focus on hiding information. Newton focuses on proving that authority was exercised correctly. The blockchain no longer needs to read the data; it only needs to verify that the right to act was validated before execution.
To me, this is the real significance of Privacy-Preserving Workflows. The next generation of blockchains may no longer be judged by how much data they store, but by how many legitimate decisions they can verify without ever accessing the underlying data. Newton Protocol is not simply adding another privacy layer. It is redefining how blockchains create trust.
@NewtonProtocol $NEWT #Newt $LAB
For years, blockchains have relied on a simple assumption: transparency creates trust. Yet the most valuable information in finance - KYC records, investment strategies, corporate data, and internal risk models can never be made public. If trust depends on exposing sensitive information, blockchain will always struggle to support AI agents, RWAs, and institutional finance.
Newton Protocol takes a different approach. The blockchain does not need to know what the data contains. It only needs proof that the data was used under the correct policy, by the correct authority, and in the correct context before an action was authorized. Newton is not changing how data is protected. It is changing what blockchains are required to verify.
That is why I do not see Privacy-Preserving Workflows as merely an encryption framework. Privacy Envelopes, HPKE, and Distributed Key Generation are only the infrastructure. The real innovation is that no single party can transform private data into an authorized action without satisfying predefined policies. Newton protects not only confidentiality, but the legitimacy of action itself.
This is also where Newton differs from many privacy solutions in Web3. Most focus on hiding information. Newton focuses on proving that authority was exercised correctly. The blockchain no longer needs to read the data; it only needs to verify that the right to act was validated before execution.
To me, this is the real significance of Privacy-Preserving Workflows. The next generation of blockchains may no longer be judged by how much data they store, but by how many legitimate decisions they can verify without ever accessing the underlying data. Newton Protocol is not simply adding another privacy layer. It is redefining how blockchains create trust.
@NewtonProtocol $NEWT #Newt $LAB
翻訳参照
If Self-Custody Were Put on Trial, I Think It Would Be Wrongfully Convicted.
The accusation sounds convincing.
“A trader can still be liquidated because the system miscalculates margin. So what does self-custody actually protect?”
The more I studied GRVT’s architecture, the more I realized this criticism targets the wrong component.
Self-custody never promised to prevent incorrect liquidations. It simply ensures your assets remain yours, even if the exchange operator becomes insolvent or acts maliciously.
Margin is a different problem entirely.
A Risk Engine does not ask, “Who owns these assets?” It asks, “Given current market conditions, is this collateral still sufficient to support the position?” Ownership verification and risk evaluation solve different problems, so they belong to different architectural layers.
That means a trader can remain the rightful owner of every asset while still being liquidated because collateral valuation, maintenance margin, or portfolio risk was calculated incorrectly. The liquidation is caused by the risk layer—not by the custody layer.
To me, this is GRVT’s real architectural insight.
Instead of building one system responsible for everything, GRVT separates responsibilities. Self-custody protects against operator risk, while Unified Margin and the Risk Engine determine whether a position remains financially safe. Each layer owns a different category of failure.
That separation changes how trust works. Instead of trusting a single black box, users can identify which layer is responsible when something goes wrong.
If I had to deliver the verdict, I would find self-custody not guilty.
Not because it eliminates every risk. But because it never claimed to.
GRVT’s real contribution is not creating a system that never fails. It creates a system where every failure has a clearly accountable architectural layer. And that, in my view, is what makes a Hybrid Exchange genuinely more trustworthy.
@grvt_io #grvt $LAB $BEAT
The accusation sounds convincing.
“A trader can still be liquidated because the system miscalculates margin. So what does self-custody actually protect?”
The more I studied GRVT’s architecture, the more I realized this criticism targets the wrong component.
Self-custody never promised to prevent incorrect liquidations. It simply ensures your assets remain yours, even if the exchange operator becomes insolvent or acts maliciously.
Margin is a different problem entirely.
A Risk Engine does not ask, “Who owns these assets?” It asks, “Given current market conditions, is this collateral still sufficient to support the position?” Ownership verification and risk evaluation solve different problems, so they belong to different architectural layers.
That means a trader can remain the rightful owner of every asset while still being liquidated because collateral valuation, maintenance margin, or portfolio risk was calculated incorrectly. The liquidation is caused by the risk layer—not by the custody layer.
To me, this is GRVT’s real architectural insight.
Instead of building one system responsible for everything, GRVT separates responsibilities. Self-custody protects against operator risk, while Unified Margin and the Risk Engine determine whether a position remains financially safe. Each layer owns a different category of failure.
That separation changes how trust works. Instead of trusting a single black box, users can identify which layer is responsible when something goes wrong.
If I had to deliver the verdict, I would find self-custody not guilty.
Not because it eliminates every risk. But because it never claimed to.
GRVT’s real contribution is not creating a system that never fails. It creates a system where every failure has a clearly accountable architectural layer. And that, in my view, is what makes a Hybrid Exchange genuinely more trustworthy.
@grvt_io #grvt $LAB $BEAT
10のオペレーターがいるからといって、10個の独立した意思決定があるとは限りません。
私はNewton Protocolを学ぶ中で、この前提を疑い始めました。分散性を測るとき、私たちはしばしばオペレーター数を数えます。しかし、認可ネットワークはノード数ではなく、同じ認可判断に到達できる独立した経路がいくつあるかによって確保されます。
Newtonでは、オペレーターは同一のIntentおよびPolicyDataに対して、Executionが進む前に同じRego PolicyをWASMにコンパイルしたものを実行します。計算の複製は簡単です。独立した参加者が同一の認可境界に到達できることを示すことこそが、実際に信頼を築きます。
そのため、オペレーター数よりもインフラの多様性が重要なのです。オペレーターの大半が同じクラウド提供者を共有しているなら、同じ障害ドメインも共有することになります。単一のインフラ障害によって、多くのオペレーターにまたがるPolicy評価が中断され、Authorizationがプロトコル内のPolicyだけでなく、プロトコル外のインフラにも左右される可能性があります。
私にとって、これはNewtonの弱点ではありません。これは、認可プロトコルが満たすべき標準そのものです。PolicyがIntentとExecutionの間にある門（ゲート）になる以上、どの単一の障害ドメインも、その門に影響できてはなりません。そうでなければ、分散性はトポロジ上には存在しても、認可（Authorization）には存在しません。
Newtonのフェイルクローズ設計は、まさにその考え方を反映しています。十分な確信をもってAuthorizationを確立できない場合、Executionは停止します。プロトコルは、信頼できない認可判断よりも、一時的な利用不能を意図的に優先します。
このように見れば、オペレーターの多様性はもはや運用上の最適化ではありません。それはNewtonのセキュリティモデルの一部です。問題は、オンラインのオペレーターが何人いるかではなく、単一の障害ドメインが「Authorizationが存在する」と判断できてしまうのかどうかです。答えが「はい」なら、ネットワークは信頼を本質的に増やすことなくオペレーター数だけを増やしていることになります。@NewtonProtocol $NEWT #Newt $LAB
私はNewton Protocolを学ぶ中で、この前提を疑い始めました。分散性を測るとき、私たちはしばしばオペレーター数を数えます。しかし、認可ネットワークはノード数ではなく、同じ認可判断に到達できる独立した経路がいくつあるかによって確保されます。
Newtonでは、オペレーターは同一のIntentおよびPolicyDataに対して、Executionが進む前に同じRego PolicyをWASMにコンパイルしたものを実行します。計算の複製は簡単です。独立した参加者が同一の認可境界に到達できることを示すことこそが、実際に信頼を築きます。
そのため、オペレーター数よりもインフラの多様性が重要なのです。オペレーターの大半が同じクラウド提供者を共有しているなら、同じ障害ドメインも共有することになります。単一のインフラ障害によって、多くのオペレーターにまたがるPolicy評価が中断され、Authorizationがプロトコル内のPolicyだけでなく、プロトコル外のインフラにも左右される可能性があります。
私にとって、これはNewtonの弱点ではありません。これは、認可プロトコルが満たすべき標準そのものです。PolicyがIntentとExecutionの間にある門（ゲート）になる以上、どの単一の障害ドメインも、その門に影響できてはなりません。そうでなければ、分散性はトポロジ上には存在しても、認可（Authorization）には存在しません。
Newtonのフェイルクローズ設計は、まさにその考え方を反映しています。十分な確信をもってAuthorizationを確立できない場合、Executionは停止します。プロトコルは、信頼できない認可判断よりも、一時的な利用不能を意図的に優先します。
このように見れば、オペレーターの多様性はもはや運用上の最適化ではありません。それはNewtonのセキュリティモデルの一部です。問題は、オンラインのオペレーターが何人いるかではなく、単一の障害ドメインが「Authorizationが存在する」と判断できてしまうのかどうかです。答えが「はい」なら、ネットワークは信頼を本質的に増やすことなくオペレーター数だけを増やしていることになります。@NewtonProtocol $NEWT #Newt $LAB
翻訳参照
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 Isn’t Managing Time. It’s Managing How Long A Decision Can Still Be Trusted.
While reading through Newton’s documentation, I noticed a detail that’s easy to overlook. Most discussions focus on policies, Rego, and PolicyData, but rarely ask a simpler question: how long should an authorization decision remain trustworthy?
Traditional blockchains treat authorization as a permission. Once validated, a decision is generally considered valid until execution. Newton approaches it differently. Every authorization is the result of evaluating a specific set of data at a specific moment, not a truth that should remain valid forever.
This idea appears throughout the architecture. Static parameters in data.params may remain unchanged for months, while observations from PolicyData can change every block. A policy evaluates both together, even though they evolve on different timelines. An authorization therefore depends not only on correct logic, but also on whether the information still reflects the current state of the world.
That’s why I don’t see Decision Lifetime as just an expiration mechanism. It reflects a deeper assumption: every decision begins to age the moment it is created. Not because the policy is wrong, but because markets move, balances change, and external observations continue to evolve.
Newton doesn’t try to extend the lifetime of an authorization. Instead, it limits how long the system should trust an earlier decision before evaluating it again with fresh observations.
Perhaps that’s why time isn’t the real focus of Newton’s architecture.
What Newton is actually managing is how long a decision remains trustworthy.
A perfectly written policy can still produce the wrong outcome if the world it evaluated has already changed. In Newton, security comes not only from making the right decision, but also from knowing when that decision should no longer be trusted.
@NewtonProtocol #Newt $NEWT $LAB $BEE
While reading through Newton’s documentation, I noticed a detail that’s easy to overlook. Most discussions focus on policies, Rego, and PolicyData, but rarely ask a simpler question: how long should an authorization decision remain trustworthy?
Traditional blockchains treat authorization as a permission. Once validated, a decision is generally considered valid until execution. Newton approaches it differently. Every authorization is the result of evaluating a specific set of data at a specific moment, not a truth that should remain valid forever.
This idea appears throughout the architecture. Static parameters in data.params may remain unchanged for months, while observations from PolicyData can change every block. A policy evaluates both together, even though they evolve on different timelines. An authorization therefore depends not only on correct logic, but also on whether the information still reflects the current state of the world.
That’s why I don’t see Decision Lifetime as just an expiration mechanism. It reflects a deeper assumption: every decision begins to age the moment it is created. Not because the policy is wrong, but because markets move, balances change, and external observations continue to evolve.
Newton doesn’t try to extend the lifetime of an authorization. Instead, it limits how long the system should trust an earlier decision before evaluating it again with fresh observations.
Perhaps that’s why time isn’t the real focus of Newton’s architecture.
What Newton is actually managing is how long a decision remains trustworthy.
A perfectly written policy can still produce the wrong outcome if the world it evaluated has already changed. In Newton, security comes not only from making the right decision, but also from knowing when that decision should no longer be trusted.
@NewtonProtocol #Newt $NEWT $LAB $BEE
ブロックチェーンは、ひとつの根本的な問題を解決します――「起きたことを保持する」ことです。トランザクションが確定すると、状態は不変になります。
しかし、@NewtonProtocol は、より深い制約を指摘します。ブロックチェーンは結果を保存するのであって、必ずしも、その背後にある「理由」を保存するわけではないのです。
トランザクションはスマートコントラクトのロジックに従って有効であっても、市場環境、データ、状態が変化することで、そのトランザクションを許可した判断がもはや正当化されなくなる場合があります。
これにより、「実行の正確さ」と「判断の正当性」の間にギャップが生まれます。
従来のブロックチェーンはこう問いかけます：
「このトランザクションはコードに照らして有効ですか？」
ニュートンはこう問いかけます：
「このトランザクションの背後にある判断は、その時点の意図・ポリシー・状態に照らして有効ですか？」
これが、Decision-Centric Security Model（判断中心のセキュリティモデル）の基盤です。
ニュートンは不変性を取り除きません。不変として保たれるべきものと、変化し続けるべきものを切り分けます。
実行には最終確定性が必要です。
判断ロジックには適応性が必要です。
だからこそニュートンは、ポリシーレイヤーを導入します：
Intent（意図）- Policy（ポリシー）- Decision（判断）- Execution（実行）
意図は目的を定義します。ポリシーは認可の境界を定義します。判断は、実行が今なお意図に一致しているかを検証します。
最も難しい問題は、ポリシーを変更することではありません。時間の経過とともに判断の正当性を保ち続けることです。
判断は、ポリシーバージョン、状態、オラクル入力、文脈に依存します。これらがなければ、システムはトランザクションが起きたことを証明できても、なぜ承認されたのかを説明できません。
ここで重要になるのが、Policy Versioning（ポリシーバージョン管理）、Decision Provenance（判断の出自）、Stateful Authorization（状態を踏まえた認可）、Decision Reproducibility（判断の再現可能性）です。
それらにより、意思決定のトレーサビリティが可能になります――承認の背後にある推論経路を再構成できるのです。
ニュートンは、さらに深い概念を導入します――不変な推論です。
ブロックチェーンは最終状態を不変にしました。ニュートンは、判断の文脈を時間を通じて検証可能にします。
分散型金融の未来は、単に不変な実行に依存するだけではありません。
システムが進化していく中でも、判断が説明可能で、再現可能で、信頼できる状態に保たれるかにかかっています。
ニュートン・プロトコルは、ブロックチェーンを不変性の面で弱くしません。
それは、変更をより説明責任のあるものにするのです。$NEWT #Newt $LAB $EVAA
しかし、@NewtonProtocol は、より深い制約を指摘します。ブロックチェーンは結果を保存するのであって、必ずしも、その背後にある「理由」を保存するわけではないのです。
トランザクションはスマートコントラクトのロジックに従って有効であっても、市場環境、データ、状態が変化することで、そのトランザクションを許可した判断がもはや正当化されなくなる場合があります。
これにより、「実行の正確さ」と「判断の正当性」の間にギャップが生まれます。
従来のブロックチェーンはこう問いかけます：
「このトランザクションはコードに照らして有効ですか？」
ニュートンはこう問いかけます：
「このトランザクションの背後にある判断は、その時点の意図・ポリシー・状態に照らして有効ですか？」
これが、Decision-Centric Security Model（判断中心のセキュリティモデル）の基盤です。
ニュートンは不変性を取り除きません。不変として保たれるべきものと、変化し続けるべきものを切り分けます。
実行には最終確定性が必要です。
判断ロジックには適応性が必要です。
だからこそニュートンは、ポリシーレイヤーを導入します：
Intent（意図）- Policy（ポリシー）- Decision（判断）- Execution（実行）
意図は目的を定義します。ポリシーは認可の境界を定義します。判断は、実行が今なお意図に一致しているかを検証します。
最も難しい問題は、ポリシーを変更することではありません。時間の経過とともに判断の正当性を保ち続けることです。
判断は、ポリシーバージョン、状態、オラクル入力、文脈に依存します。これらがなければ、システムはトランザクションが起きたことを証明できても、なぜ承認されたのかを説明できません。
ここで重要になるのが、Policy Versioning（ポリシーバージョン管理）、Decision Provenance（判断の出自）、Stateful Authorization（状態を踏まえた認可）、Decision Reproducibility（判断の再現可能性）です。
それらにより、意思決定のトレーサビリティが可能になります――承認の背後にある推論経路を再構成できるのです。
ニュートンは、さらに深い概念を導入します――不変な推論です。
ブロックチェーンは最終状態を不変にしました。ニュートンは、判断の文脈を時間を通じて検証可能にします。
分散型金融の未来は、単に不変な実行に依存するだけではありません。
システムが進化していく中でも、判断が説明可能で、再現可能で、信頼できる状態に保たれるかにかかっています。
ニュートン・プロトコルは、ブロックチェーンを不変性の面で弱くしません。
それは、変更をより説明責任のあるものにするのです。$NEWT #Newt $LAB $EVAA
かつて私は、@NewtonProtocol が実際にどのように合意（コンセンサス）に依存しているのかを誤解していました
しばらくの間、私はニュートン・プロトコルを純粋に技術的なものだと思っていました。つまり、基盤となるチェーンの合意をそのまま引き継ぐだけだ、と。チェーンが安全ならニュートンも安全——その見立ては一見もっともに聞こえます。しかし実際に起きるオートメーションをより深く見るほど、セキュリティそのものよりも重要な「時間」を見落としていることに気づかされました。
オートメーションは「究極の真実」の上に存在するのではありません。真実が確定する前の猶予期間に存在します。意思（インテント）は、絶対的な最終確定を無限に待てません。待っている間に、経済的な機会がすでに失われてしまうからです。そこでニュートン・プロトコルは、明示的には述べていないにせよ、基盤チェーンの合意が「時間が使える状態でいる」ほど予測可能であることを前提にしています。これは正しさに関する仮定ではなく、レイテンシと最終確定の規則性に関する仮定です。
あまり語られない論点があります。ニュートン・プロトコル上の各インテントは、実質的にリオーグ（再編成）の分布に対する賭けになっている、ということです。Nブロック待つことを選ぶとき、あなたは「Nブロックより深い再編成は許容できるほど稀である」と暗黙に言っています。ドキュメントには、リオーグ時のロールバックが言及されていますが、そのロールバックが十分に稀であることがオートメーションの“アルファ”の大部分を生んでいる、とは書かれていません。リオーグが予測不能になると、オートメーションは「間違う」よりも前に、経済的に意味を失います。
これが、私が長い間抱いていた別の誤解にもつながりました。ニュートン・プロトコルは、基盤チェーンに対して本当に中立ではありません。フォークを選ぶわけではないのは事実です。しかし、ビルダーに対して「時間の使い方」を通じて合意の品質を価格付けさせます。より長く待てば安全を買えます。より早く動けば優位性を買えます。あなたのために、そのトレードオフを下の層が吸収してくれるわけではありません。
つまり、ニュートン・プロトコルをデプロイする際の本当の問いは、「このチェーンはファイナリティ（最終確定）を持っているか？」ではありません。
本当の問いはこうです。『このチェーンの最終確定は、時間そのものを資産として扱えるほど安定しているか？』
もしそうでなければ、ニュートンは動き続けますが、オートメーションはより洗練されたcronジョブに過ぎなくなります。
@NewtonProtocol $NEWT #Newt $LAB $BEAT
しばらくの間、私はニュートン・プロトコルを純粋に技術的なものだと思っていました。つまり、基盤となるチェーンの合意をそのまま引き継ぐだけだ、と。チェーンが安全ならニュートンも安全——その見立ては一見もっともに聞こえます。しかし実際に起きるオートメーションをより深く見るほど、セキュリティそのものよりも重要な「時間」を見落としていることに気づかされました。
オートメーションは「究極の真実」の上に存在するのではありません。真実が確定する前の猶予期間に存在します。意思（インテント）は、絶対的な最終確定を無限に待てません。待っている間に、経済的な機会がすでに失われてしまうからです。そこでニュートン・プロトコルは、明示的には述べていないにせよ、基盤チェーンの合意が「時間が使える状態でいる」ほど予測可能であることを前提にしています。これは正しさに関する仮定ではなく、レイテンシと最終確定の規則性に関する仮定です。
あまり語られない論点があります。ニュートン・プロトコル上の各インテントは、実質的にリオーグ（再編成）の分布に対する賭けになっている、ということです。Nブロック待つことを選ぶとき、あなたは「Nブロックより深い再編成は許容できるほど稀である」と暗黙に言っています。ドキュメントには、リオーグ時のロールバックが言及されていますが、そのロールバックが十分に稀であることがオートメーションの“アルファ”の大部分を生んでいる、とは書かれていません。リオーグが予測不能になると、オートメーションは「間違う」よりも前に、経済的に意味を失います。
これが、私が長い間抱いていた別の誤解にもつながりました。ニュートン・プロトコルは、基盤チェーンに対して本当に中立ではありません。フォークを選ぶわけではないのは事実です。しかし、ビルダーに対して「時間の使い方」を通じて合意の品質を価格付けさせます。より長く待てば安全を買えます。より早く動けば優位性を買えます。あなたのために、そのトレードオフを下の層が吸収してくれるわけではありません。
つまり、ニュートン・プロトコルをデプロイする際の本当の問いは、「このチェーンはファイナリティ（最終確定）を持っているか？」ではありません。
本当の問いはこうです。『このチェーンの最終確定は、時間そのものを資産として扱えるほど安定しているか？』
もしそうでなければ、ニュートンは動き続けますが、オートメーションはより洗練されたcronジョブに過ぎなくなります。
@NewtonProtocol $NEWT #Newt $LAB $BEAT
昨日、散歩中にLyに会った。私たちはニュー トン・プロトコルについて話すために、よくこんなふうに出会う。Lyは私にこう聞いた：
「なぜ @NewtonProtocol は、競合を早期に解消せず、対立を選ぶの？」
私はすぐには答えられなかった。というのも、その問い自体が、システムの中には実際には存在しない何かを前提にしているように感じたからだ。「競合は、残すことも取り除くことも選べるものだ」という考えだ。ニュー トン・プロトコルでは、それは成り立たない。
このシステムでは、推論は結論へ直接は進まない。複数の仮説を同時に生成し、最初は別々の可能性として独立して存在するのではなく、互いに重なり合っている。私たちが「競合」と呼んでいるのは、単に未解決の絡み合いの状態であり、どれかひとつの結果が、それ自体として十分に明確になっていないだけだ。
「解消（Resolve）」は能動的なステップのように聞こえるが、ニュー トン・プロトコルでは必ずしも起こせない。ひとつの枝を選んでも、その背後にある全体の構造を歪めないときにのみ起こる。その条件が満たされないなら、早期に解消することは「より速い進展」ではなく、単なる時期尚早のコミットメントにすぎない。
要点は、ニュー トン・プロトコルは競合を「直すべきもの」として扱わないということだ。扱うのは、それを信号としてだけだ。つまり「まだ決める時ではない」という合図である。競合を別途取り除くための仕組みは存在しない。というのも、妥当な結論の条件が満たされた瞬間に、競合は自然に消えていくからだ。
言い換えれば、このアプローチを選ぶのは、結論に至るスピードを優先しないからだ。優先するのは、タイミングの正しさである。もし早すぎる時点で解消してしまうと、局所的には正しく見えるかもしれないが、それは全体構造のごく狭い一断面を反映しているにすぎない。
Lyの問いを振り返ってみて気づいた。ニュー トン・プロトコルは、競合と解消のあいだに位置するのではない。どちらの前にあるのだ。関心があるのはひとつだけ——あるシステムが、複数の可能性を実際にひとつの確定した結果へ変換することが許されるのは、いつなのか。そして、その瞬間が来るまでは、競合は問題ではなく、システムがまだどんな結論も信頼する準備ができていないという単なる兆しにすぎない。
@NewtonProtocol $NEWT #Newt $LAB $GAIA
「なぜ @NewtonProtocol は、競合を早期に解消せず、対立を選ぶの？」
私はすぐには答えられなかった。というのも、その問い自体が、システムの中には実際には存在しない何かを前提にしているように感じたからだ。「競合は、残すことも取り除くことも選べるものだ」という考えだ。ニュー トン・プロトコルでは、それは成り立たない。
このシステムでは、推論は結論へ直接は進まない。複数の仮説を同時に生成し、最初は別々の可能性として独立して存在するのではなく、互いに重なり合っている。私たちが「競合」と呼んでいるのは、単に未解決の絡み合いの状態であり、どれかひとつの結果が、それ自体として十分に明確になっていないだけだ。
「解消（Resolve）」は能動的なステップのように聞こえるが、ニュー トン・プロトコルでは必ずしも起こせない。ひとつの枝を選んでも、その背後にある全体の構造を歪めないときにのみ起こる。その条件が満たされないなら、早期に解消することは「より速い進展」ではなく、単なる時期尚早のコミットメントにすぎない。
要点は、ニュー トン・プロトコルは競合を「直すべきもの」として扱わないということだ。扱うのは、それを信号としてだけだ。つまり「まだ決める時ではない」という合図である。競合を別途取り除くための仕組みは存在しない。というのも、妥当な結論の条件が満たされた瞬間に、競合は自然に消えていくからだ。
言い換えれば、このアプローチを選ぶのは、結論に至るスピードを優先しないからだ。優先するのは、タイミングの正しさである。もし早すぎる時点で解消してしまうと、局所的には正しく見えるかもしれないが、それは全体構造のごく狭い一断面を反映しているにすぎない。
Lyの問いを振り返ってみて気づいた。ニュー トン・プロトコルは、競合と解消のあいだに位置するのではない。どちらの前にあるのだ。関心があるのはひとつだけ——あるシステムが、複数の可能性を実際にひとつの確定した結果へ変換することが許されるのは、いつなのか。そして、その瞬間が来るまでは、競合は問題ではなく、システムがまだどんな結論も信頼する準備ができていないという単なる兆しにすぎない。
@NewtonProtocol $NEWT #Newt $LAB $GAIA
私は「予測可能な実行（predictable execution）」という言葉を@NewtonProtocol docsで初めて読んだのですが、最初の反応はあまり前向きではありませんでした。あたかもこのシステムが、未来に許される姿を制約しようとしているように聞こえたのです。可能性が何らかの事前フィルタを通されているような、硬すぎる感覚がありました。
しかし、その反応はよく読み直すうちに実際にはあまり持ちこたえませんでした。Newton Protocolが問題にしているのは、結果を制限することではなく、そもそも個人間の信頼を必要としないようにすることです。参加者同士が互いを信頼しないと仮定した瞬間、その負担はシステム側が背負わざるを得なくなる。
通常の実行システムでは、あらゆる行為がその結果についての不確実性を生みます。あなたは単に「この実行は行われるのか」と問うだけでなく、「実行後に自分が得られるものを信頼できるのか」も問います。調整が最も崩れるのは実行そのものではなく、まさにこの二つ目の問いのところです。
「予測可能な実行」は、その依存を構造へと移します。行為者を信頼するのではなく、どんな結果が有効かを定義する共有ルール層を信頼するのです。行為がルールに合致していれば、その結果はもはや信念の問題ではなく、ただの検証になります。
ただし、この転換にはそれ特有の緊張があり、最初は見落としやすい。すべてが共有文法を通過しなければならなくなったとき、その文法で表現できないものは、デフォルトで見えなくなります。必ずしも誤っているわけでも不可能なわけでもない。ただ、認識されないだけ。
それでも、ここでの目的が統制や制限だとは思いません。むしろ、信頼が構造的に欠けている環境でも調整を可能にしようとする試みのように感じます。このシステムは未来を狭めているのではありません。未来を、皆で読める（legible）状態にしようとしているのです。
その観点から見ると、Newton Protocolは「起こり得ること」を形づくることよりも、「起こったこととして正しく合意できること」を定義することに近い。すべてが新規であることをすぐに理解できなくなるとしても、合意のコストは下がります。このトレードオフこそ、おそらくここでの本当の設計空間でしょう。
@NewtonProtocol $NEWT #Newt $BAS $NEX
しかし、その反応はよく読み直すうちに実際にはあまり持ちこたえませんでした。Newton Protocolが問題にしているのは、結果を制限することではなく、そもそも個人間の信頼を必要としないようにすることです。参加者同士が互いを信頼しないと仮定した瞬間、その負担はシステム側が背負わざるを得なくなる。
通常の実行システムでは、あらゆる行為がその結果についての不確実性を生みます。あなたは単に「この実行は行われるのか」と問うだけでなく、「実行後に自分が得られるものを信頼できるのか」も問います。調整が最も崩れるのは実行そのものではなく、まさにこの二つ目の問いのところです。
「予測可能な実行」は、その依存を構造へと移します。行為者を信頼するのではなく、どんな結果が有効かを定義する共有ルール層を信頼するのです。行為がルールに合致していれば、その結果はもはや信念の問題ではなく、ただの検証になります。
ただし、この転換にはそれ特有の緊張があり、最初は見落としやすい。すべてが共有文法を通過しなければならなくなったとき、その文法で表現できないものは、デフォルトで見えなくなります。必ずしも誤っているわけでも不可能なわけでもない。ただ、認識されないだけ。
それでも、ここでの目的が統制や制限だとは思いません。むしろ、信頼が構造的に欠けている環境でも調整を可能にしようとする試みのように感じます。このシステムは未来を狭めているのではありません。未来を、皆で読める（legible）状態にしようとしているのです。
その観点から見ると、Newton Protocolは「起こり得ること」を形づくることよりも、「起こったこととして正しく合意できること」を定義することに近い。すべてが新規であることをすぐに理解できなくなるとしても、合意のコストは下がります。このトレードオフこそ、おそらくここでの本当の設計空間でしょう。
@NewtonProtocol $NEWT #Newt $BAS $NEX
ログインして、さらにコンテンツを読む