Binance Square
NewbieToNode
4.2k 投稿

NewbieToNode

厳選トピック確認済+
Planting tokens 🌱 Waiting for sun 🌞 Watering with hope 💧 Soft degen vibes only
Traders League Badge Expert
Traders League Badge Expert
高頻度トレーダー
4.3年
162 フォロー
33.0K+ フォロワー
27.6K+ いいね
1 バッジ
投稿
·
--
一部該当
翻訳参照
@babylonlabs_io I reread one paragraph in Babylon's TBV paper because it didn't match the mental model I'd built from other BitVM bridge designs. I assumed the challenge window existed to catch invalid proofs. That wasn't what stood out. The paper keeps coming back to a different point. Anyone can challenge a claim, including the vault owner. Some BitVM bridge designs rely on a permissioned challenger set. If that group misses fraud or fails to respond, the security model depends on them. Trustless Bitcoin Vaults (TBV) doesn't make that assumption. The protocol keeps the challenge process open instead of deciding in advance who is responsible for protecting the system. Until then, I'd treated the waiting period as dead time between verification and settlement. After rereading that section, it looked more like part of the security model itself. The waiting period isn't what makes TBV trustless. The permissionless challenge process does. The waiting period gives that mechanism time to work. That's the same trade behind TBV's native Bitcoin-backed borrowing. Native BTC collateral doesn't depend on trusting a designated challenger before settlement can be finalized. Every valid claim waits through the same challenge window. Not because every claim is suspicious, but because the protocol can't know in advance which claim will actually need to be challenged. I'm now watching whether this design still feels practical under real network usage. If the permissionless challenge process continues to hold under load, I'll understand TBV very differently than I did when I first opened the paper. #baby $BABY
@BabylonLabs_io

I reread one paragraph in Babylon's TBV paper because it didn't match the mental model I'd built from other BitVM bridge designs.

I assumed the challenge window existed to catch invalid proofs.

That wasn't what stood out.

The paper keeps coming back to a different point. Anyone can challenge a claim, including the vault owner.

Some BitVM bridge designs rely on a permissioned challenger set. If that group misses fraud or fails to respond, the security model depends on them.

Trustless Bitcoin Vaults (TBV) doesn't make that assumption.

The protocol keeps the challenge process open instead of deciding in advance who is responsible for protecting the system.

Until then, I'd treated the waiting period as dead time between verification and settlement. After rereading that section, it looked more like part of the security model itself.

The waiting period isn't what makes TBV trustless. The permissionless challenge process does. The waiting period gives that mechanism time to work.

That's the same trade behind TBV's native Bitcoin-backed borrowing. Native BTC collateral doesn't depend on trusting a designated challenger before settlement can be finalized.

Every valid claim waits through the same challenge window. Not because every claim is suspicious, but because the protocol can't know in advance which claim will actually need to be challenged.

I'm now watching whether this design still feels practical under real network usage. If the permissionless challenge process continues to hold under load, I'll understand TBV very differently than I did when I first opened the paper.

#baby $BABY
翻訳参照
@babylonlabs_io The first thing I expected from Trustless Bitcoin Vaults (TBV) was that Bitcoin would eventually need to understand Ethereum. If native Bitcoin is being used as self-custodial collateral for borrowing on Ethereum, surely Bitcoin has to verify something about Ethereum's state. I kept reading because I wanted to find where that happened. I never did. TBV is designed so Bitcoin never has to understand Ethereum's state. Bitcoin never runs the verifier for Ethereum's state, and it never learns what that state is. Verification happens off-chain. Bitcoin's role is narrower. It enforces the protocol's settlement conditions without ever interpreting Ethereum's state. The more I followed the architecture, the more one pattern stood out. Nothing in the design asks Bitcoin to interpret Ethereum's state. The architecture consistently preserves Bitcoin's existing validation model. That completely changed what I thought Babylon was optimizing for. I originally assumed the goal was to make Bitcoin capable of securing borrowing on another chain. Now I think the bigger goal is preserving Bitcoin's existing security assumptions while extending what native BTC can be used for. That's why TBV is built around self-custodial borrowing without wrapping BTC, bridging it, or relying on intermediaries. The interesting trade-off is where the complexity goes. The proofs, challenge process, and dispute logic don't disappear. Babylon deliberately keeps them outside Bitcoin, so extending Bitcoin's utility doesn't require changing Bitcoin's validation model. The question I'm left with isn't whether this design works. It's whether Babylon can continue preserving Bitcoin's validation model as TBV expands to support more use cases. #baby $BABY
@BabylonLabs_io

The first thing I expected from Trustless Bitcoin Vaults (TBV) was that Bitcoin would eventually need to understand Ethereum.

If native Bitcoin is being used as self-custodial collateral for borrowing on Ethereum, surely Bitcoin has to verify something about Ethereum's state.

I kept reading because I wanted to find where that happened.

I never did.

TBV is designed so Bitcoin never has to understand Ethereum's state.

Bitcoin never runs the verifier for Ethereum's state, and it never learns what that state is. Verification happens off-chain. Bitcoin's role is narrower. It enforces the protocol's settlement conditions without ever interpreting Ethereum's state.

The more I followed the architecture, the more one pattern stood out. Nothing in the design asks Bitcoin to interpret Ethereum's state. The architecture consistently preserves Bitcoin's existing validation model.

That completely changed what I thought Babylon was optimizing for.

I originally assumed the goal was to make Bitcoin capable of securing borrowing on another chain.

Now I think the bigger goal is preserving Bitcoin's existing security assumptions while extending what native BTC can be used for. That's why TBV is built around self-custodial borrowing without wrapping BTC, bridging it, or relying on intermediaries.

The interesting trade-off is where the complexity goes.

The proofs, challenge process, and dispute logic don't disappear. Babylon deliberately keeps them outside Bitcoin, so extending Bitcoin's utility doesn't require changing Bitcoin's validation model.

The question I'm left with isn't whether this design works. It's whether Babylon can continue preserving Bitcoin's validation model as TBV expands to support more use cases.

#baby $BABY
確認済み
@babylonlabs_io 私は1文でTrustless Bitcoin Vaults(TBV)論文の読みを止めました。 TBVは、ラップやブリッジなしで、ネイティブのBitcoinがEthereum上の借り入れを担保できるようにします。その後の論文では、BitcoinにEthereumを理解させることなく、Ethereumの状態遷移を証明する方法が説明されました。 誤解したのだと思って、3つ前のセクションに戻りました。 でも、誤解ではありませんでした。 BitcoinはSNARK検証者を評価しません。Ethereumの状態を学習することもしません。 BitVM3は、その作業をオフチェーンのチャレンジ手順に移します。主張(claim)がBitcoinに投稿され、チャレンジ・ウィンドウのタイムロックの後ろで待機します。たとえその主張が争われなかったとしても、Bitcoinはそのウィンドウを強制します。誰もその主張をうまく争わなければ、決済は続行されます。争う側が主張が偽であることを証明した場合、さらに別の仕組みとして、その失敗した証明から明らかになった秘密によって起動されるハッシュロックが支払いを防ぎます。 それで、TBVの捉え方が変わりました。 BitcoinはEthereumを検証しているわけではありません。 Bitcoinがやっているのは、主張が決済を許される条件を強制することです。 計算はオフチェーンのままです。Bitcoinの役割は、別のチェーンの状態を解釈することなく、プロトコルのセキュリティ条件を強制することです。 私が今見ているのは、順調な道筋ではありません。 失敗の道筋です。 チャレンジ・ウィンドウが込み合うようになったとき、それは実際にどれくらいの頻度で行使されるのでしょうか。そして、同時に複数の主張が有効になっているとき、TBVのパブリック・テストネットではそれがどのように見えるのでしょう? $BABY は、紛争プロセスが実際のネットワーク条件下でも予測可能なままであるなら、初めて私にとって意味を持ちます。 #baby
@BabylonLabs_io

私は1文でTrustless Bitcoin Vaults(TBV)論文の読みを止めました。

TBVは、ラップやブリッジなしで、ネイティブのBitcoinがEthereum上の借り入れを担保できるようにします。その後の論文では、BitcoinにEthereumを理解させることなく、Ethereumの状態遷移を証明する方法が説明されました。

誤解したのだと思って、3つ前のセクションに戻りました。

でも、誤解ではありませんでした。

BitcoinはSNARK検証者を評価しません。Ethereumの状態を学習することもしません。

BitVM3は、その作業をオフチェーンのチャレンジ手順に移します。主張(claim)がBitcoinに投稿され、チャレンジ・ウィンドウのタイムロックの後ろで待機します。たとえその主張が争われなかったとしても、Bitcoinはそのウィンドウを強制します。誰もその主張をうまく争わなければ、決済は続行されます。争う側が主張が偽であることを証明した場合、さらに別の仕組みとして、その失敗した証明から明らかになった秘密によって起動されるハッシュロックが支払いを防ぎます。

それで、TBVの捉え方が変わりました。

BitcoinはEthereumを検証しているわけではありません。

Bitcoinがやっているのは、主張が決済を許される条件を強制することです。

計算はオフチェーンのままです。Bitcoinの役割は、別のチェーンの状態を解釈することなく、プロトコルのセキュリティ条件を強制することです。

私が今見ているのは、順調な道筋ではありません。

失敗の道筋です。

チャレンジ・ウィンドウが込み合うようになったとき、それは実際にどれくらいの頻度で行使されるのでしょうか。そして、同時に複数の主張が有効になっているとき、TBVのパブリック・テストネットではそれがどのように見えるのでしょう?

$BABY は、紛争プロセスが実際のネットワーク条件下でも予測可能なままであるなら、初めて私にとって意味を持ちます。

#baby
GRVT Boosterキャンペーンで、他のTop 300のクリエイターはこのような状況ですか? 私はグローバル順位 #56 に入っており、資格要件もすべて完了していますが、検証ウィンドウが開いているのに「Verify」ボタンがまだ無効のままです。 アプリをすでに更新し、キャッシュをクリアし、強制停止も行い、さらに同じKeyless Walletを使っていることも確認しました。 同じ問題を他の方も経験していますか?それとも私のアカウントだけでしょうか? #GRVT @grvt_io @BinanceWallet @Binance_Customer_Support
GRVT Boosterキャンペーンで、他のTop 300のクリエイターはこのような状況ですか?

私はグローバル順位 #56 に入っており、資格要件もすべて完了していますが、検証ウィンドウが開いているのに「Verify」ボタンがまだ無効のままです。

アプリをすでに更新し、キャッシュをクリアし、強制停止も行い、さらに同じKeyless Walletを使っていることも確認しました。

同じ問題を他の方も経験していますか?それとも私のアカウントだけでしょうか?

#GRVT @grvt_io @Binance Wallet @Binance Customer Support
🚀 $DODO が40%超上昇 — 強気派が主導権を奪取! 数週間のもみ合いを経て、$DODO は力強い勢いでブレイクし、**42%超**の上昇を記録し、重要なレジスタンス水準を取り戻しました。 📈 サポート:$0.024–0.025 🎯 レジスタンス:$0.030 価格がブレイクアウトのゾーンを上回って維持される限り、強気の構造は健全なままです。**$0.03**を明確に上抜けると、次の上昇局面に火がつく可能性があります。 $DODO を保有していますか?それとも押し目待ちですか?👇 {spot}(DODOUSDT)
🚀 $DODO が40%超上昇 — 強気派が主導権を奪取!

数週間のもみ合いを経て、$DODO は力強い勢いでブレイクし、**42%超**の上昇を記録し、重要なレジスタンス水準を取り戻しました。

📈 サポート:$0.024–0.025
🎯 レジスタンス:$0.030

価格がブレイクアウトのゾーンを上回って維持される限り、強気の構造は健全なままです。**$0.03**を明確に上抜けると、次の上昇局面に火がつく可能性があります。

$DODO を保有していますか?それとも押し目待ちですか?👇
🚀 別のトークン化された株式がBinanceに登場します! AAOIB/USDTは、BinanceのbStocksプラットフォーム上でApplied Optoelectronics(AAOI)を表し、対象となるユーザーに対して、基礎となる株式へのオンチェーンでのエクスポージャーを提供します。 BinanceがbStocksを拡大し続ける中で、トークン化された株式は従来の市場をクリプトにより近づけています。 従来のブローカーを使う代わりに、トークン化された株式を取引しますか?👇 {spot}(AAOIBUSDT)
🚀 別のトークン化された株式がBinanceに登場します!

AAOIB/USDTは、BinanceのbStocksプラットフォーム上でApplied Optoelectronics(AAOI)を表し、対象となるユーザーに対して、基礎となる株式へのオンチェーンでのエクスポージャーを提供します。

BinanceがbStocksを拡大し続ける中で、トークン化された株式は従来の市場をクリプトにより近づけています。

従来のブローカーを使う代わりに、トークン化された株式を取引しますか?👇
確認済み
🧵 今イランで実際に何が起きているのか 「#TrumpMeetsOnWiderIranOffensive が爆発しているのを見た」なら、全体像はこちらです: 背景:米国とイランの間で結ばれた一時的な停戦は、戦闘の再燃によって事実上崩壊しました。米国は、イランが世界でも最重要級のエネルギー海上チョークポイントの一つであるホルムズ海峡で商業船舶を攻撃したと主張しています。これに対しワシントンは軍事攻撃を拡大し、イランの港を狙う海上封鎖を再導入しました。 エスカレーション:トランプは、ホルムズ海峡周辺の作戦を超えて、より大規模なキャンペーンについて議論するため、大統領のフルの国家安全保障チームとともにシチュエーション・ルームで会合を行いました。また、イランが交渉に応じない場合、発電所や橋などの重要インフラが標的になる可能性があるとも警告しています。 不確定要素:米国当局は「Pickaxe Mountain」を厳重に注視しています。これは、核関連施設だと考えられており、バンカー・バスター兵器であっても破壊が難しい可能性がある、強固に要塞化された地下施設です。 市場への影響:ホルムズ海峡は、世界の石油およびLNG出荷の大きな割合を担っています。長引く混乱はエネルギー価格を押し上げ、インフレ懸念を高め、仮想通貨を含む世界の市場でボラティリティを引き起こし得ます。こうした地政学的ショックの際、ビットコインや主要資産はオンチェーンのファンダメンタルズよりも、マクロのリスク心理に反応することがしばしばあります。 状況を見逃さず、見出しを追い、状況に応じてリスクを管理してください。🧠 #TrumpMeetsOnWiderIranOffensive
🧵 今イランで実際に何が起きているのか

#TrumpMeetsOnWiderIranOffensive が爆発しているのを見た」なら、全体像はこちらです:

背景:米国とイランの間で結ばれた一時的な停戦は、戦闘の再燃によって事実上崩壊しました。米国は、イランが世界でも最重要級のエネルギー海上チョークポイントの一つであるホルムズ海峡で商業船舶を攻撃したと主張しています。これに対しワシントンは軍事攻撃を拡大し、イランの港を狙う海上封鎖を再導入しました。

エスカレーション:トランプは、ホルムズ海峡周辺の作戦を超えて、より大規模なキャンペーンについて議論するため、大統領のフルの国家安全保障チームとともにシチュエーション・ルームで会合を行いました。また、イランが交渉に応じない場合、発電所や橋などの重要インフラが標的になる可能性があるとも警告しています。

不確定要素:米国当局は「Pickaxe Mountain」を厳重に注視しています。これは、核関連施設だと考えられており、バンカー・バスター兵器であっても破壊が難しい可能性がある、強固に要塞化された地下施設です。

市場への影響:ホルムズ海峡は、世界の石油およびLNG出荷の大きな割合を担っています。長引く混乱はエネルギー価格を押し上げ、インフレ懸念を高め、仮想通貨を含む世界の市場でボラティリティを引き起こし得ます。こうした地政学的ショックの際、ビットコインや主要資産はオンチェーンのファンダメンタルズよりも、マクロのリスク心理に反応することがしばしばあります。

状況を見逃さず、見出しを追い、状況に応じてリスクを管理してください。🧠

#TrumpMeetsOnWiderIranOffensive
確認済み
記事
Newtonのマーケットプレイスには競合が現れる前からユーザーがいた<c-35/> もっと絞り込んだ質問を持ってモデル・レジストリに戻りました。 以前は、誰がモデルを公開したのかに注目していました。ニュートンのロードマップによると、プロトコル上で最初に構築されたエージェントは、Magic Labs が開発した Recurring Buy Agent です。私はそれを、エコシステムはまだ単に到来していなかったのだと解釈しました。 それはドキュメントに載っていた内容とは少し違っていました。 ニュートンは、Recurring Buy Agent を黙って公開してそのままにしておかなかった。ユーザーが自分のリカーリング購入インスタンスをデプロイできるように、Start Agent のオンボーディング・フローを構築したのです。さらにニュートンは、エージェントをデプロイし、他の人を紹介したユーザーに報酬を与えるために、<c-87/ >の総供給量の0.75%を割り当てるキャンペーンで Kaito と提携しました。そのプログラムは、上位20,000人の参加者を中心に設計されていました。

Newtonのマーケットプレイスには競合が現れる前からユーザーがいた

<c-35/>
もっと絞り込んだ質問を持ってモデル・レジストリに戻りました。
以前は、誰がモデルを公開したのかに注目していました。ニュートンのロードマップによると、プロトコル上で最初に構築されたエージェントは、Magic Labs が開発した Recurring Buy Agent です。私はそれを、エコシステムはまだ単に到来していなかったのだと解釈しました。
それはドキュメントに載っていた内容とは少し違っていました。
ニュートンは、Recurring Buy Agent を黙って公開してそのままにしておかなかった。ユーザーが自分のリカーリング購入インスタンスをデプロイできるように、Start Agent のオンボーディング・フローを構築したのです。さらにニュートンは、エージェントをデプロイし、他の人を紹介したユーザーに報酬を与えるために、<c-87/ >の総供給量の0.75%を割り当てるキャンペーンで Kaito と提携しました。そのプログラムは、上位20,000人の参加者を中心に設計されていました。
確認済み
@NewtonProtocol モデル登録簿に実際に何が入っているのかを確かめようとして見に行きました。 ニュートンはそれを、誰でもエージェントを公開し、発見し、エージェントの群れ(スウォーム)として組み合わせられるオンチェーンのマーケットプレイスだと説明しています。すでに中身が入っているものだと思っていました。複数のチーム。競合するエージェントモデル。私は、レジストリがすでにそうしたエコシステムを支えるために作られているのだと思っていたのです。 しかし、ニュートン自身のロードマップはそうではありません。 プロトコル上で最初に構築されたエージェントは、ニュートンそのもののチームであるMagic Labsが作った「リカーリング・バイ・エージェント」です。 公開、発見、そして合成可能なエージェントのスウォームについては、ロードマップ上では次に来るものとして説明されています。 それは、私が前提としていたあるものを組み替えるきっかけになりました。 レジストリのガバナンスモデルは、すでに文書化されています。ステーキング、登録、そしてオペレーターの説明責任は、独立した参加者によるより広いマーケットプレイスが文書化される前に定義されています。 ガバナンスが、エコシステムに先んじて到来したのです。 ニュートンのMainnet Betaが拡大していくにつれ、今日の文書上の出発点は社内のエージェント1つです。ロードマップでは、今日文書化されているものよりも広いマーケットプレイスについて述べられています。 それが、インセンティブ設計が単に外部参加者を待っているだけなのか、あるいは、単一のチームが作ったエージェントから始めることが、全員に公開する前に仕組みを検証するのにまさに望ましい進め方なのかは分かりません。どちらの読みも、文書に書かれている内容に当てはまります。 Mainnet Betaにおいて1つのエージェントで足りるのかどうかよりも重要なのは、モデルレジストリが、@NewtonProtocol が構築したわけではないオペレーターを統治し始めたときに何が変わるのかです。そこが、マーケットプレイスがロードマップではなくインフラになり始めるポイントです。 $NEWT becomes(この文書では)より興味深く感じられるのは、これらのガバナンスルールが、プロトコル自身の最初の出発点だけでなく、独立した参加者にも適用され始めるときです。 #Newt
@NewtonProtocol

モデル登録簿に実際に何が入っているのかを確かめようとして見に行きました。

ニュートンはそれを、誰でもエージェントを公開し、発見し、エージェントの群れ(スウォーム)として組み合わせられるオンチェーンのマーケットプレイスだと説明しています。すでに中身が入っているものだと思っていました。複数のチーム。競合するエージェントモデル。私は、レジストリがすでにそうしたエコシステムを支えるために作られているのだと思っていたのです。

しかし、ニュートン自身のロードマップはそうではありません。

プロトコル上で最初に構築されたエージェントは、ニュートンそのもののチームであるMagic Labsが作った「リカーリング・バイ・エージェント」です。

公開、発見、そして合成可能なエージェントのスウォームについては、ロードマップ上では次に来るものとして説明されています。

それは、私が前提としていたあるものを組み替えるきっかけになりました。

レジストリのガバナンスモデルは、すでに文書化されています。ステーキング、登録、そしてオペレーターの説明責任は、独立した参加者によるより広いマーケットプレイスが文書化される前に定義されています。

ガバナンスが、エコシステムに先んじて到来したのです。

ニュートンのMainnet Betaが拡大していくにつれ、今日の文書上の出発点は社内のエージェント1つです。ロードマップでは、今日文書化されているものよりも広いマーケットプレイスについて述べられています。

それが、インセンティブ設計が単に外部参加者を待っているだけなのか、あるいは、単一のチームが作ったエージェントから始めることが、全員に公開する前に仕組みを検証するのにまさに望ましい進め方なのかは分かりません。どちらの読みも、文書に書かれている内容に当てはまります。

Mainnet Betaにおいて1つのエージェントで足りるのかどうかよりも重要なのは、モデルレジストリが、@NewtonProtocol が構築したわけではないオペレーターを統治し始めたときに何が変わるのかです。そこが、マーケットプレイスがロードマップではなくインフラになり始めるポイントです。

$NEWT becomes(この文書では)より興味深く感じられるのは、これらのガバナンスルールが、プロトコル自身の最初の出発点だけでなく、独立した参加者にも適用され始めるときです。

#Newt
@grvt_io 「保険ファンド」と読むたびに、そこが清算(リキッド)の物語の終着点だと思っていました。 GRVTのドキュメントはさらに続いていました。 大規模な清算によって保険ファンドが赤字に陥った場合、GRVTは、交換所全体における保険ファンドの赤字を総クライアント資本(Total Client Equity)で割ることで、Socialized Loss Haircut(社会化された損失のヘアカット)を計算します。 この割合が適用されるのは、赤字が存在している間に行われた出金のみです。 そこで読み止めて、実例(worked example)をもう一度さかのぼって見ました。 清算によって、保険ファンドは「総クライアント資本4,000 USDT」に対して「200 USDTだけ」マイナス(アンダーウォーター)になります。その結果、ヘアカットは5%です。チャーリーはその期間中に500 USDTを出金します。彼は475 USDTを受け取り、保険ファンドには残りの25 USDTが入ります。赤字がゼロに戻ると、ヘアカットもそれとともに消えます。 それによって、保険ファンドの理解が変わりました。 私はこれを最後のバッファだと見なしていました。 ドキュメントでは、損失配分の一部として出金のタイミングが組み込まれていることが示されています。 ヘアカットは、その損失を生み出したポジションによって決まるわけではありません。 赤字がまだ存在している間に、誰が出金を選ぶかによって決まります。 この仕組みは、損失を計上するだけではありません。 その損失がどう分配されるかの中に、出口(エグジット)のタイミングまで含めているのです。 私は、相場のストレス局面で、トレーダーが保険ファンドを価格や証拠金と同じように扱い始めるのか、それともほとんどの人が、出金が想定よりわずかに少ない金額で決着してから、この仕組みを初めて知るのかを見ています。 #grvt
@grvt_io

「保険ファンド」と読むたびに、そこが清算(リキッド)の物語の終着点だと思っていました。

GRVTのドキュメントはさらに続いていました。

大規模な清算によって保険ファンドが赤字に陥った場合、GRVTは、交換所全体における保険ファンドの赤字を総クライアント資本(Total Client Equity)で割ることで、Socialized Loss Haircut(社会化された損失のヘアカット)を計算します。

この割合が適用されるのは、赤字が存在している間に行われた出金のみです。

そこで読み止めて、実例(worked example)をもう一度さかのぼって見ました。

清算によって、保険ファンドは「総クライアント資本4,000 USDT」に対して「200 USDTだけ」マイナス(アンダーウォーター)になります。その結果、ヘアカットは5%です。チャーリーはその期間中に500 USDTを出金します。彼は475 USDTを受け取り、保険ファンドには残りの25 USDTが入ります。赤字がゼロに戻ると、ヘアカットもそれとともに消えます。

それによって、保険ファンドの理解が変わりました。

私はこれを最後のバッファだと見なしていました。

ドキュメントでは、損失配分の一部として出金のタイミングが組み込まれていることが示されています。

ヘアカットは、その損失を生み出したポジションによって決まるわけではありません。

赤字がまだ存在している間に、誰が出金を選ぶかによって決まります。

この仕組みは、損失を計上するだけではありません。

その損失がどう分配されるかの中に、出口(エグジット)のタイミングまで含めているのです。

私は、相場のストレス局面で、トレーダーが保険ファンドを価格や証拠金と同じように扱い始めるのか、それともほとんどの人が、出金が想定よりわずかに少ない金額で決着してから、この仕組みを初めて知るのかを見ています。

#grvt
一部該当
記事
ニュートンの第三のポリシーの結末を探しに行った@NewtonProtocol 私は3つ目の結末を探しに行きました。 ライトペーパーには、はっきりと、早い段階で、まるで通りすがりに触れるようにこう書かれています。Newton ポリシーとは、取引を進めるべきか、遅らせるべきか、あるいは拒否すべきかを決める、プログラム可能なルールセットです。 3つの結末。 2つではありません。 最初に読んだとき、私はそれを読み飛ばしていました。まるで定義のように感じて、続くすべてを静かに組み立ててしまう種類の文です。実装もいずれは同じ場所にたどり着くのだろうと思いました。 そこで私はどこかを探しに行きました。 Newton Mainnet Beta は、決済の前に認可(authorization)を行うことを基盤に構築されています。意図(intent)はポリシーに照らして評価されます。オペレーターはクォーラムに到達します。それらの承認が結合して、単一のアテステーション(証明)になります。スマートコントラクトがそれを検証します。取引は進むか、進まないかのどちらかです。

ニュートンの第三のポリシーの結末を探しに行った

@NewtonProtocol
私は3つ目の結末を探しに行きました。
ライトペーパーには、はっきりと、早い段階で、まるで通りすがりに触れるようにこう書かれています。Newton ポリシーとは、取引を進めるべきか、遅らせるべきか、あるいは拒否すべきかを決める、プログラム可能なルールセットです。
3つの結末。
2つではありません。
最初に読んだとき、私はそれを読み飛ばしていました。まるで定義のように感じて、続くすべてを静かに組み立ててしまう種類の文です。実装もいずれは同じ場所にたどり着くのだろうと思いました。
そこで私はどこかを探しに行きました。
Newton Mainnet Beta は、決済の前に認可(authorization)を行うことを基盤に構築されています。意図(intent)はポリシーに照らして評価されます。オペレーターはクォーラムに到達します。それらの承認が結合して、単一のアテステーション(証明)になります。スマートコントラクトがそれを検証します。取引は進むか、進まないかのどちらかです。
確認済み
@NewtonProtocol 「分散化(decentralized)」という言葉を、ひとつのことを指しているかのように読み続けていました。 違いました。 Newton Mainnet Betaが実際にどこでコンセンサスに到達するのかを追いかけてみて、はじめてそれに気づきました。 最初のレイヤーは見覚えのあるものでした。 オペレーターがポリシーを評価します。 アテステーション(証明)を生成します。 これまで私が書いてきたNewtonの投稿は、すべてそのレイヤーの中で生きていました。ドキュメントには、Ethereumのリステーキングによってセキュアな分散型ネットワークだと書かれています。 私は、読むのをやめかけました。 でも、読み進めました。 その下に、別のレイヤーがありました。 私はアーキテクチャを追い、バリデーターにたどり着きました。 そこにも同じ分散化という主張が待っていると、私は思い込んでいました。 まだ、そうではありませんでした。 NewtonのTransparency Report(透明性レポート)によると、ネットワークはまずFoundationが管理するバリデーターから始まり、次に特定の第三者バリデーターの許可制のセットへ移行し、最終的には完全に許可のない(permissionless)バリデーター・セットを目指します。 始まる。 移行する。 目指す。 そこで、私はようやく、自分がひとつの言葉を、ひとつのマイルストーンとして扱っていたのだと気づきました。 ドキュメントは、そうしていません。 オペレーターの分散化と、バリデーターの分散化は、異なるマイルストーンであり、異なるタイムライン上にあります。 Newtonは、インフラを分散化する前に評価を分散化します。 この違いが、私のアーキテクチャの読み方を変えました。 オペレーターネットワークは、誰がポリシーを評価し、誰がアテステーションを生成するのかを説明します。 バリデーター・セットは、現在誰がブロックを生成し、状態を最終確定しているのかを説明します。 それらは異なる信頼の前提であり、異なるスケジュールで進化しています。 私は、人々が「分散化」を単一の性質として読むのをやめ、実際にどのレイヤーの話をしているのかを問うようになると、何が起きるのかを見ています。 ドキュメントはすでに、そのレイヤーを分けています。 Mainnet Betaは、その会話も同じように分けられるのかを示すはずです。 $NEWT は、この2つのタイムラインが収束し始めるにつれて、私にとってより興味深いものになります。 #Newt
@NewtonProtocol

「分散化(decentralized)」という言葉を、ひとつのことを指しているかのように読み続けていました。

違いました。

Newton Mainnet Betaが実際にどこでコンセンサスに到達するのかを追いかけてみて、はじめてそれに気づきました。

最初のレイヤーは見覚えのあるものでした。

オペレーターがポリシーを評価します。

アテステーション(証明)を生成します。

これまで私が書いてきたNewtonの投稿は、すべてそのレイヤーの中で生きていました。ドキュメントには、Ethereumのリステーキングによってセキュアな分散型ネットワークだと書かれています。

私は、読むのをやめかけました。

でも、読み進めました。

その下に、別のレイヤーがありました。

私はアーキテクチャを追い、バリデーターにたどり着きました。

そこにも同じ分散化という主張が待っていると、私は思い込んでいました。

まだ、そうではありませんでした。

NewtonのTransparency Report(透明性レポート)によると、ネットワークはまずFoundationが管理するバリデーターから始まり、次に特定の第三者バリデーターの許可制のセットへ移行し、最終的には完全に許可のない(permissionless)バリデーター・セットを目指します。

始まる。

移行する。

目指す。

そこで、私はようやく、自分がひとつの言葉を、ひとつのマイルストーンとして扱っていたのだと気づきました。

ドキュメントは、そうしていません。

オペレーターの分散化と、バリデーターの分散化は、異なるマイルストーンであり、異なるタイムライン上にあります。

Newtonは、インフラを分散化する前に評価を分散化します。

この違いが、私のアーキテクチャの読み方を変えました。

オペレーターネットワークは、誰がポリシーを評価し、誰がアテステーションを生成するのかを説明します。

バリデーター・セットは、現在誰がブロックを生成し、状態を最終確定しているのかを説明します。

それらは異なる信頼の前提であり、異なるスケジュールで進化しています。

私は、人々が「分散化」を単一の性質として読むのをやめ、実際にどのレイヤーの話をしているのかを問うようになると、何が起きるのかを見ています。

ドキュメントはすでに、そのレイヤーを分けています。

Mainnet Betaは、その会話も同じように分けられるのかを示すはずです。

$NEWT は、この2つのタイムラインが収束し始めるにつれて、私にとってより興味深いものになります。

#Newt
確認済み
@grvt_io 登録が開始されました。 残された判断は、私のトークンを請求するかどうかだけだと思っていました。 でも違いました。 私を引き戻し続けていたのは、登録期間ではありませんでした。Multiplier Plan(マルチプライヤー・プラン)でした。 最初は、マルチプライヤー=より多くのトークンが増えるものだと考えていました。 違います。 GRVTのMultiplier Guideによれば、エアドロップの総配布プールは決して変わりません。Multiplier Planを選ぶことで変わるのは、その固定プールの「分け方」だけです。TGE後に4か月または8か月分、配布を延期する代わりに、より大きい加重配分(weighted share)を得られます。 その時点で、私はそれを「ボーナス」として考えるのをやめました。 もっと流動性(リクイディティ)の判断に近いと感じました。 タイミングが、さらに興味深くしていました。 Multiplier Planは7月17日に締め切られる一方、登録は7月27日まで継続します。加重(weighting)を変える決定は、登録期間そのものが終わる前に行う必要があります。 何もしなければ、自動的にStandard Plan(スタンダード・プラン)にとどまります。TGEで全額配分。マルチプライヤーなし。 参加者は全員、同じ固定プールに対して同じトレードオフを行っています。 即時の流動性。 それとも、待つ代わりにより大きい加重配分。 私がTGE後に注目しているのは、Multplier Planを選んだ人の数ではありません。 この仕組みが本当に保有者の行動を変えるのか、それとも同じ売り圧力を4か月または8か月先にずらすだけなのか——それがポイントです。 #grvt
@grvt_io

登録が開始されました。

残された判断は、私のトークンを請求するかどうかだけだと思っていました。

でも違いました。

私を引き戻し続けていたのは、登録期間ではありませんでした。Multiplier Plan(マルチプライヤー・プラン)でした。

最初は、マルチプライヤー=より多くのトークンが増えるものだと考えていました。

違います。

GRVTのMultiplier Guideによれば、エアドロップの総配布プールは決して変わりません。Multiplier Planを選ぶことで変わるのは、その固定プールの「分け方」だけです。TGE後に4か月または8か月分、配布を延期する代わりに、より大きい加重配分(weighted share)を得られます。

その時点で、私はそれを「ボーナス」として考えるのをやめました。

もっと流動性(リクイディティ)の判断に近いと感じました。

タイミングが、さらに興味深くしていました。

Multiplier Planは7月17日に締め切られる一方、登録は7月27日まで継続します。加重(weighting)を変える決定は、登録期間そのものが終わる前に行う必要があります。

何もしなければ、自動的にStandard Plan(スタンダード・プラン)にとどまります。TGEで全額配分。マルチプライヤーなし。

参加者は全員、同じ固定プールに対して同じトレードオフを行っています。

即時の流動性。

それとも、待つ代わりにより大きい加重配分。

私がTGE後に注目しているのは、Multplier Planを選んだ人の数ではありません。

この仕組みが本当に保有者の行動を変えるのか、それとも同じ売り圧力を4か月または8か月先にずらすだけなのか——それがポイントです。

#grvt
確認済み
記事
ニュートン・プロトコルは実行を証明した。それでもボンドは残った。担保はまだありました。 もう消えていると思っていました。 @NewtonProtocol verifies agent execution。 あらゆるものが状態に到達する前に、TEE(Trusted Execution Environment)とゼロ知識証明、そしてポリシーチェックを。実行が証明可能になった時点で、担保を投稿する要件は冗長に見え始めるだろうと考えていました。証明はそれ自体で立つべきです。 その前提が成り立つかどうかを確かめるために、モデルレジストリのドキュメントを読み直しました。 オペレーターがエージェントのモデルを公開する際も、引き続き $NEWT をステークします。 それでもスラッシュ可能でした。 それを二度読んでから、実際に何がそれを引き起こしているのかを探しに行きました。

ニュートン・プロトコルは実行を証明した。それでもボンドは残った。

担保はまだありました。
もう消えていると思っていました。
@NewtonProtocol verifies agent execution。
あらゆるものが状態に到達する前に、TEE(Trusted Execution Environment)とゼロ知識証明、そしてポリシーチェックを。実行が証明可能になった時点で、担保を投稿する要件は冗長に見え始めるだろうと考えていました。証明はそれ自体で立つべきです。
その前提が成り立つかどうかを確かめるために、モデルレジストリのドキュメントを読み直しました。
オペレーターがエージェントのモデルを公開する際も、引き続き $NEWT をステークします。
それでもスラッシュ可能でした。
それを二度読んでから、実際に何がそれを引き起こしているのかを探しに行きました。
確認済み
私は$DEXE を何日も見続けていた。 毎朝、ブレイクアウトが弱まるのを期待していた。 でも、それは起きなかった。 今日は新しい史上最高値が更新されている。 興味深いのはローソク足そのものじゃない。 ローソク足の前に何が起きたかだ。 新しいウォレットが次々と現れ続けた。 クジラが継続的に積み上げ続けた。 価格は、もはや過去の抵抗が残っていない領域へと踏み込み、あらゆる動きが回復ではなく値動きの発見になっていく。 多くのトレーダーはこれを「FOMO(恐怖の出遅れ)」と呼ぶだろう。 でも、これは雑な分析だと思う。 強いトレンドは、誰もが突然強気になるから始まることは滅多にない。 始まるのは、供給がよりタイトになり、需要が粘り強く維持され、そして下げが来ても売られず吸収され続けるときだ。 だから、最も難しい取引は「高すぎる」ように見えるものになることが多い。 そして今、真の試練が始まる。 $DEXE はこれまでの天井を超えて受け入れ(定着)を作れるのか?それとも、買いの遅れた人よりも売りの遅れた人に報酬を与える、ただの急騰による投機的天井(ブロックオフ・トップ)になるのか? 次の数回のデイリー終値は、今日の強気のローソク足よりもはるかに重要だ。 {spot}(DEXEUSDT)
私は$DEXE を何日も見続けていた。

毎朝、ブレイクアウトが弱まるのを期待していた。

でも、それは起きなかった。

今日は新しい史上最高値が更新されている。

興味深いのはローソク足そのものじゃない。

ローソク足の前に何が起きたかだ。

新しいウォレットが次々と現れ続けた。

クジラが継続的に積み上げ続けた。

価格は、もはや過去の抵抗が残っていない領域へと踏み込み、あらゆる動きが回復ではなく値動きの発見になっていく。

多くのトレーダーはこれを「FOMO(恐怖の出遅れ)」と呼ぶだろう。

でも、これは雑な分析だと思う。

強いトレンドは、誰もが突然強気になるから始まることは滅多にない。

始まるのは、供給がよりタイトになり、需要が粘り強く維持され、そして下げが来ても売られず吸収され続けるときだ。

だから、最も難しい取引は「高すぎる」ように見えるものになることが多い。

そして今、真の試練が始まる。

$DEXE はこれまでの天井を超えて受け入れ(定着)を作れるのか?それとも、買いの遅れた人よりも売りの遅れた人に報酬を与える、ただの急騰による投機的天井(ブロックオフ・トップ)になるのか?

次の数回のデイリー終値は、今日の強気のローソク足よりもはるかに重要だ。
確認済み
絆はまだそこにあった。 もう消えているはずだと思っていた。 @NewtonProtocol は、エージェントの実行が検証可能であることを確認する。TEE、ゼロ知識証明、そして何かが状態に触れる前のポリシーチェック。実行が検証可能になれば、担保要件がいずれ不要になるかもしれないと私は考えた。 しかしそうではなかった。 モデルレジストリにエージェントモデルを公開するオペレータは、いまも$NEWT をステークしている それでもまだスラッシュ可能だ。 何が実際にそれを引き起こすのか探しに行った。 ドキュメントには2つのことが挙げられている。 不正行為(Misbehavior)。 バリデーションの失敗(Failed validation)。 不正行為はすぐに私にも納得できた。 バリデーションの失敗は、そうではなかった。 数ページ進んだところで、ドキュメントの別の部分にたどり着き、ニュートンのポリシーレイヤーは「反応的」ではなく「予防的」だと説明されていた。ポリシーに違反する取引は実行されない。状態は変わらない。資金は動かない。 そこで読んでいるうちに、少しペースが落ちた。 予防モデルは、無効な実行がチェーンに到達してはいけない理由を説明している。 スラッシングモデルは、オペレータが失敗した場合にユーザーが補償を必要とし得る理由を説明している。 私が見つけられなかったのは、この2つの考え方の間にある運用上の境界だった。 またドキュメントには、スラッシュされた担保は、欠陥のある、あるいは不正にふるまうエージェントモデルの影響を受けたユーザーへ再分配できるとも書かれている。 私はずっと「"failed validation(バリデーションの失敗)"」という言葉に戻ってきた。 それは無効な取引を指しているのか? ライブネスの失敗(liveness failure)? 応答しないオペレータ? 届かない証明? わからない。 その境界はドキュメントに明示されておらず、そして私は、その点こそがもっとも面白い疑問だと思う。 たぶん「failed validation」は、悪い実行に価格をつけているわけではない。 たぶん「failed validation」は、そもそも実行が検証可能になる前の瞬間に値付けしているのだ。 Newton Mainnet Beta が本番へ移行するにあたり、「failed validation」が実際に捉えようとしている運用上の出来事は何なのか? その境界はどこから始まるのか? $NEWT onlyは、その境界が本番トラフィックが開示される前に、オペレータが自分たちが何に対してステークしているのかを正確に理解できるほど明確に保たれている場合に限って、私にとって意味を持つ。 #Newt
絆はまだそこにあった。

もう消えているはずだと思っていた。

@NewtonProtocol は、エージェントの実行が検証可能であることを確認する。TEE、ゼロ知識証明、そして何かが状態に触れる前のポリシーチェック。実行が検証可能になれば、担保要件がいずれ不要になるかもしれないと私は考えた。

しかしそうではなかった。

モデルレジストリにエージェントモデルを公開するオペレータは、いまも$NEWT をステークしている

それでもまだスラッシュ可能だ。

何が実際にそれを引き起こすのか探しに行った。

ドキュメントには2つのことが挙げられている。

不正行為(Misbehavior)。

バリデーションの失敗(Failed validation)。

不正行為はすぐに私にも納得できた。

バリデーションの失敗は、そうではなかった。

数ページ進んだところで、ドキュメントの別の部分にたどり着き、ニュートンのポリシーレイヤーは「反応的」ではなく「予防的」だと説明されていた。ポリシーに違反する取引は実行されない。状態は変わらない。資金は動かない。

そこで読んでいるうちに、少しペースが落ちた。

予防モデルは、無効な実行がチェーンに到達してはいけない理由を説明している。

スラッシングモデルは、オペレータが失敗した場合にユーザーが補償を必要とし得る理由を説明している。

私が見つけられなかったのは、この2つの考え方の間にある運用上の境界だった。

またドキュメントには、スラッシュされた担保は、欠陥のある、あるいは不正にふるまうエージェントモデルの影響を受けたユーザーへ再分配できるとも書かれている。

私はずっと「"failed validation(バリデーションの失敗)"」という言葉に戻ってきた。

それは無効な取引を指しているのか?

ライブネスの失敗(liveness failure)?

応答しないオペレータ?

届かない証明?

わからない。

その境界はドキュメントに明示されておらず、そして私は、その点こそがもっとも面白い疑問だと思う。

たぶん「failed validation」は、悪い実行に価格をつけているわけではない。

たぶん「failed validation」は、そもそも実行が検証可能になる前の瞬間に値付けしているのだ。

Newton Mainnet Beta が本番へ移行するにあたり、「failed validation」が実際に捉えようとしている運用上の出来事は何なのか? その境界はどこから始まるのか?

$NEWT onlyは、その境界が本番トラフィックが開示される前に、オペレータが自分たちが何に対してステークしているのかを正確に理解できるほど明確に保たれている場合に限って、私にとって意味を持つ。

#Newt
確認済み
記事
姿を現さなかったニュートンの鍵ニュートンの暗号鍵を探しに行きました。 署名鍵ではありません。 実際にクライアントが暗号化に使うのは、その鍵です。 いずれサーバーか、ゲートウェイか、それを保持する責任のあるオペレーターを見つけられるはずだと思っていました。 わかりません。 すべてのオペレーターに、見覚えのある鍵がありました。 ECDSA。 BLS。 私が聞いていた質問には、どちらも答えてくれませんでした。 何か見落とした気がしました。 それで、プライバシーのセクションをもう一度読み始めました。 答えは別の鍵ではありませんでした。 それは分散鍵生成(Distributed Key Generation)の儀式でした。 その瞬間、アーキテクチャが見覚えのあるものに見えなくなりました。

姿を現さなかったニュートンの鍵

ニュートンの暗号鍵を探しに行きました。
署名鍵ではありません。
実際にクライアントが暗号化に使うのは、その鍵です。
いずれサーバーか、ゲートウェイか、それを保持する責任のあるオペレーターを見つけられるはずだと思っていました。
わかりません。
すべてのオペレーターに、見覚えのある鍵がありました。
ECDSA。
BLS。
私が聞いていた質問には、どちらも答えてくれませんでした。
何か見落とした気がしました。
それで、プライバシーのセクションをもう一度読み始めました。
答えは別の鍵ではありませんでした。
それは分散鍵生成(Distributed Key Generation)の儀式でした。
その瞬間、アーキテクチャが見覚えのあるものに見えなくなりました。
@NewtonProtocol ニュートンのクロスチェーン・アーキテクチャで最初に探したのは、リレーラーではありませんでした。 それは、2つ目のオペレーター登録でした。 私は、すべての接続先チェーンが、自分が信頼するオペレーターについての独自の見方を維持しているものだと想定していました。 しかし見つかりませんでした。 ドキュメントがまだその部分に到達していないだけだと思いました。 それでスクロールし続けました。 しかし、ついに見つかりませんでした。 次に見つけたのは、別のレジストリではありません。BLSで署名されたマークルルートで、イーサリアムから更新されたオペレーター・テーブルを運びます。許可制ではないリレーラーが、この署名済みルートを接続先チェーンへ伝播し、接続先チェーン側のオンチェーン検証者が集約署名を検証した後にローカルのオペレーター・テーブルを更新します。 これによって、私はアーキテクチャの読み方が変わりました。 オペレーター登録は、各チェーンがそれぞれ所有するものだと考えるのをやめました。 実際には、すべてのチェーンが継承するものだったのです。 その同期がなければ、接続先チェーンは、異なるオペレーター・テーブルに対して認可を検証できてしまう可能性があります。代わりに、彼らは同じ同期された見方を検証し続けています。 私が見ているのは、伝播が機能するかどうかではありません。 同期が可視化される最初のオペレーター・ローテーションを見ています。すべての更新が退屈なままであれば、おそらくアーキテクチャは意図どおりにきっちり動いているのでしょう。 $NEWT は、オペレーターの同期が十分に静かにスケールし続けて、接続先チェーンが「誰が認可されているか」という異なる見方に頼るための意味のある時間を決して費やさない限りにおいて、私にとって面白くなります。 #Newt
@NewtonProtocol

ニュートンのクロスチェーン・アーキテクチャで最初に探したのは、リレーラーではありませんでした。

それは、2つ目のオペレーター登録でした。

私は、すべての接続先チェーンが、自分が信頼するオペレーターについての独自の見方を維持しているものだと想定していました。

しかし見つかりませんでした。

ドキュメントがまだその部分に到達していないだけだと思いました。

それでスクロールし続けました。

しかし、ついに見つかりませんでした。

次に見つけたのは、別のレジストリではありません。BLSで署名されたマークルルートで、イーサリアムから更新されたオペレーター・テーブルを運びます。許可制ではないリレーラーが、この署名済みルートを接続先チェーンへ伝播し、接続先チェーン側のオンチェーン検証者が集約署名を検証した後にローカルのオペレーター・テーブルを更新します。

これによって、私はアーキテクチャの読み方が変わりました。

オペレーター登録は、各チェーンがそれぞれ所有するものだと考えるのをやめました。

実際には、すべてのチェーンが継承するものだったのです。

その同期がなければ、接続先チェーンは、異なるオペレーター・テーブルに対して認可を検証できてしまう可能性があります。代わりに、彼らは同じ同期された見方を検証し続けています。

私が見ているのは、伝播が機能するかどうかではありません。

同期が可視化される最初のオペレーター・ローテーションを見ています。すべての更新が退屈なままであれば、おそらくアーキテクチャは意図どおりにきっちり動いているのでしょう。

$NEWT は、オペレーターの同期が十分に静かにスケールし続けて、接続先チェーンが「誰が認可されているか」という異なる見方に頼るための意味のある時間を決して費やさない限りにおいて、私にとって面白くなります。

#Newt
確認済み
@grvt_io 新しい交換APIでまず確認するのは、レイテンシではありません。 本当にチェーンと接触したときに生き残るのは、どのフィールドかです。 GRVTの注文スキーマの途中まで止めて確認しました。 ペイロードは一様に見えました。 しかし違いました。 注文の大部分は、GRVTのHyperchain上で署名され、強制されます。 一方、メタデータは違います。 GRVTのドキュメントには、これらのフィールドは決して署名されず、スマートコントラクトへ送信されることもなく、バックエンドの処理のためにだけ存在すると書かれています。さらに、その部分について「本質的に信頼不要ではない」とも説明されています。 私は上までスクロールし直しました。 私はオブジェクト全体を、ひとつの約束として読んでいました。 ですが違います。 ペイロードは単一に見える。 でも保証は単一ではない。 その分割が、なぜ2つのオブジェクトではなく、1つのオブジェクトの中に存在するのか——ドキュメントは説明していません。 ただの実装上の都合かもしれません。 あるいは、このAPI全体で最も興味深いアーキテクチャ上の判断のひとつなのかもしれない。 でも、どちらなのか私はまだ知りません。 #grvt
@grvt_io

新しい交換APIでまず確認するのは、レイテンシではありません。

本当にチェーンと接触したときに生き残るのは、どのフィールドかです。

GRVTの注文スキーマの途中まで止めて確認しました。

ペイロードは一様に見えました。

しかし違いました。

注文の大部分は、GRVTのHyperchain上で署名され、強制されます。

一方、メタデータは違います。

GRVTのドキュメントには、これらのフィールドは決して署名されず、スマートコントラクトへ送信されることもなく、バックエンドの処理のためにだけ存在すると書かれています。さらに、その部分について「本質的に信頼不要ではない」とも説明されています。

私は上までスクロールし直しました。

私はオブジェクト全体を、ひとつの約束として読んでいました。

ですが違います。

ペイロードは単一に見える。

でも保証は単一ではない。

その分割が、なぜ2つのオブジェクトではなく、1つのオブジェクトの中に存在するのか——ドキュメントは説明していません。

ただの実装上の都合かもしれません。

あるいは、このAPI全体で最も興味深いアーキテクチャ上の判断のひとつなのかもしれない。

でも、どちらなのか私はまだ知りません。

#grvt
一部該当
🚨 停戦は終わった。再び。今回は本当に続きそうにない。 トランプは金曜に確認した。イランが話し合いを続けるよう求め、米国はそれに同意したが、テヘランには停戦そのものが終わっていると突きつけた。脅しではない。声明だ。 ここで重要なのは文脈だ。両者が了解覚書(MoU)に署名してから1か月未満で2度目のエスカレーションになる。今夜のうちに、米軍はイランの約90の目標に攻撃を行った。イランの対応は象徴的なものではなかった。IRGCは、米国の基地が置かれている湾岸2か国、バーレーンとクウェートの米国資産に対してドローンとミサイルを投入した。これは二国間の言い争いというより、地域的な拡大だ。 すでに原油は反応している。ホルムズ海峡のリスクを背景に、再び上昇している。前回ここが崩れたときに原油が急騰したのと同じチョークポイントだ。トランプは海上封鎖の再開を持ち出し、さらにはホルグ島を奪取することまで示唆した。イラン側の交渉担当者は、MoUが完全に崩れるなら「全面防衛」に備える用意があると言っている。 では暗号資産にとって本当の問いは何か。今度はBTCが連動から切り離され、ヘッジのように取引されるのか。それとも6月の最初の局面で起きたように、株式と同じようにただじわじわ下落してしまうのか? 「停戦“終了”」と「“協議は継続”」が同じ文に入っていることが示すのは、これは姿勢であって解決ではないということだ。見出しのリスクはまだ終わっていない。ポジションを“していない”かのように動くな、ということだ。 {spot}(BTCUSDT)
🚨 停戦は終わった。再び。今回は本当に続きそうにない。

トランプは金曜に確認した。イランが話し合いを続けるよう求め、米国はそれに同意したが、テヘランには停戦そのものが終わっていると突きつけた。脅しではない。声明だ。

ここで重要なのは文脈だ。両者が了解覚書(MoU)に署名してから1か月未満で2度目のエスカレーションになる。今夜のうちに、米軍はイランの約90の目標に攻撃を行った。イランの対応は象徴的なものではなかった。IRGCは、米国の基地が置かれている湾岸2か国、バーレーンとクウェートの米国資産に対してドローンとミサイルを投入した。これは二国間の言い争いというより、地域的な拡大だ。

すでに原油は反応している。ホルムズ海峡のリスクを背景に、再び上昇している。前回ここが崩れたときに原油が急騰したのと同じチョークポイントだ。トランプは海上封鎖の再開を持ち出し、さらにはホルグ島を奪取することまで示唆した。イラン側の交渉担当者は、MoUが完全に崩れるなら「全面防衛」に備える用意があると言っている。

では暗号資産にとって本当の問いは何か。今度はBTCが連動から切り離され、ヘッジのように取引されるのか。それとも6月の最初の局面で起きたように、株式と同じようにただじわじわ下落してしまうのか?

「停戦“終了”」と「“協議は継続”」が同じ文に入っていることが示すのは、これは姿勢であって解決ではないということだ。見出しのリスクはまだ終わっていない。ポジションを“していない”かのように動くな、ということだ。
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約