Binance Square
HASEEB_CRPTO
4.5k 投稿

HASEEB_CRPTO

The perfect plan is not about luck,its is about perfect strategy.
取引を発注
高頻度トレーダー
1.2年
888 フォロー
33.5K+ フォロワー
16.1K+ いいね
投稿
ポートフォリオ
·
--
ブリッシュ
確認済み
翻訳参照
I’ve been watching this space long enough to spot when something's just a wrapper versus when it's a rebuild. Most people throw around "tokenization" like it's the answer to everything. But here's what I've noticed tokenization takes an asset that lives off-chain with a custodian and wraps a token around it. The asset's still in the old world. If the custodian fails, that token's a claim on a broken process. You still need reconciliation between the chain and reality. Native issuance is different. The asset is created and managed entirely on-chain issuance, transfers, settlement, corporate actions all happen around the ledger. No reconciliation needed because there's only one version of the truth. NPEX is what made this click for me. It's a Dutch stock exchange regulated by the AFM, and they've facilitated over €200 million in financing for 100+ SMEs. They're pursuing a DLT-TSS license under the EU Pilot Regime to natively issue securities on Dusk. Dusk's mainnet went live on January 7, 2026, after six years of development. They've integrated Chainlink for real-time pricing and Quantoz's MiCA-compliant EURQ stablecoin. The privacy piece is what actually makes this viable for institutions. Dusk uses zero-knowledge proofs to protect transaction data while staying compliant with MiFID II and MiCA. That's the gap that's kept TradFi and DeFi apart not technology, but privacy and regulation. If post-trade disappears, what happens to the trillion-dollar industry built around it? I don't have the answer. But NPEX and Dusk are running an experiment that makes that question less hypothetical by the day. @Dusk_Foundation #dusk $DUSK $BR $AKE
I’ve been watching this space long enough to spot when something's just a wrapper versus when it's a rebuild.

Most people throw around "tokenization" like it's the answer to everything. But here's what I've noticed tokenization takes an asset that lives off-chain with a custodian and wraps a token around it. The asset's still in the old world. If the custodian fails, that token's a claim on a broken process. You still need reconciliation between the chain and reality.

Native issuance is different. The asset is created and managed entirely on-chain issuance, transfers, settlement, corporate actions all happen around the ledger. No reconciliation needed because there's only one version of the truth.

NPEX is what made this click for me. It's a Dutch stock exchange regulated by the AFM, and they've facilitated over €200 million in financing for 100+ SMEs. They're pursuing a DLT-TSS license under the EU Pilot Regime to natively issue securities on Dusk. Dusk's mainnet went live on January 7, 2026, after six years of development. They've integrated Chainlink for real-time pricing and Quantoz's MiCA-compliant EURQ stablecoin.

The privacy piece is what actually makes this viable for institutions. Dusk uses zero-knowledge proofs to protect transaction data while staying compliant with MiFID II and MiCA. That's the gap that's kept TradFi and DeFi apart not technology, but privacy and regulation.

If post-trade disappears, what happens to the trillion-dollar industry built around it? I don't have the answer. But NPEX and Dusk are running an experiment that makes that question less hypothetical by the day.
@Dusk #dusk $DUSK $BR $AKE
native issuance
tokenization
npex and dusk
dlt-tss
10 残り時間
率直に言うと、私がバビロンの切り捨て(slashing)に関するドキュメントを最初に読み込んだとき、ある点がどうしても腑に落ちませんでした。プロトコルは明確に、切り捨ては同一人物による矛盾(ダブルサイン)――つまり equivocation(二重署名)の場合にのみ行う、としています。ダウンタイム? 逃した投票? 罰則なし。最終性チェックポイントへの署名に失敗した場合も切り捨てはありません。 そして、誰も語っていないゲーム理論があります。最終性プロバイダー(Finality Provider)は、100 BTC をステークして委任(delegations)を受け入れ、利回り(yield)を得た上で、BSN 向けの最終性署名をそのまま停止できます。BSN はビットコインで担保された最終性を失いますが、FP の BTC は? まったく危険にさらされません。彼らは矛盾した署名をしていないのです。単に無言(沈黈)になっただけです。 ヴィジランティ(Vigilante)ネットワークは? 悪意のある equivocation を監視します。ビットコインのスクリプトはダウンタイムの証明をサポートしていないため、沈黈に対して「切り捨て(slash)」はできません。バビロンは、この盲点をビットコイン自身から引き継いでいます。署名した内容を罰することはできても、いつ署名したか(署名のタイミング)を罰することはできないのです。 これにより、「パススルー・パラサイト(Passthrough Parasite)」戦略が成立します。セキュリティ出力をゼロにしながら利回りを稼ぐ。2日間のアンボンド(unbonding)猶予をやり過ごし、きれいに引き出して、また繰り返す。51% の正直な FP によって確保されていた BSN は、彼らが「ライブネスへの打撃(liveness strike)」を連携して行えば、瞬時にセキュリティを 0% へ劣化させ得ます。切り捨てなし、損失なし。最終性に依存する DeFi ポジションを清算(liquidate)し得る一時的なブラックアウトが起きるだけです。 プロトコルは、スライディングウィンドウ(滑動窓)によってライブネスを追跡し、投票の欠落が多すぎるとジャイル(jailing)します。しかし、プロバイダーはアクティブ集合(active set)の境界付近で離脱し、ジャイルが発動される前に見逃しカウンターをリセットできてしまいます。 他のステーキング・プロトコルにこの“完全に同じ”抜け穴がないのは、オンチェーンのハートビート機構によってアップタイムに罰則を課しているからです。バビロンにはそれができません。ビットコインの限られたスクリプティングに依存しているからです。つまりバビロンのセキュリティ層は、本質的に「自発的なライブネス」によって成り立っています。微妙ですが致命的な違いです。 @babylonlabs_io $BABY #baby $BLESS $ELON
率直に言うと、私がバビロンの切り捨て(slashing)に関するドキュメントを最初に読み込んだとき、ある点がどうしても腑に落ちませんでした。プロトコルは明確に、切り捨ては同一人物による矛盾(ダブルサイン)――つまり equivocation(二重署名)の場合にのみ行う、としています。ダウンタイム? 逃した投票? 罰則なし。最終性チェックポイントへの署名に失敗した場合も切り捨てはありません。

そして、誰も語っていないゲーム理論があります。最終性プロバイダー(Finality Provider)は、100 BTC をステークして委任(delegations)を受け入れ、利回り(yield)を得た上で、BSN 向けの最終性署名をそのまま停止できます。BSN はビットコインで担保された最終性を失いますが、FP の BTC は? まったく危険にさらされません。彼らは矛盾した署名をしていないのです。単に無言(沈黈)になっただけです。

ヴィジランティ(Vigilante)ネットワークは? 悪意のある equivocation を監視します。ビットコインのスクリプトはダウンタイムの証明をサポートしていないため、沈黈に対して「切り捨て(slash)」はできません。バビロンは、この盲点をビットコイン自身から引き継いでいます。署名した内容を罰することはできても、いつ署名したか(署名のタイミング)を罰することはできないのです。

これにより、「パススルー・パラサイト(Passthrough Parasite)」戦略が成立します。セキュリティ出力をゼロにしながら利回りを稼ぐ。2日間のアンボンド(unbonding)猶予をやり過ごし、きれいに引き出して、また繰り返す。51% の正直な FP によって確保されていた BSN は、彼らが「ライブネスへの打撃(liveness strike)」を連携して行えば、瞬時にセキュリティを 0% へ劣化させ得ます。切り捨てなし、損失なし。最終性に依存する DeFi ポジションを清算(liquidate)し得る一時的なブラックアウトが起きるだけです。

プロトコルは、スライディングウィンドウ(滑動窓)によってライブネスを追跡し、投票の欠落が多すぎるとジャイル(jailing)します。しかし、プロバイダーはアクティブ集合(active set)の境界付近で離脱し、ジャイルが発動される前に見逃しカウンターをリセットできてしまいます。

他のステーキング・プロトコルにこの“完全に同じ”抜け穴がないのは、オンチェーンのハートビート機構によってアップタイムに罰則を課しているからです。バビロンにはそれができません。ビットコインの限られたスクリプティングに依存しているからです。つまりバビロンのセキュリティ層は、本質的に「自発的なライブネス」によって成り立っています。微妙ですが致命的な違いです。

@BabylonLabs_io $BABY #baby $BLESS $ELON
·
--
ブリッシュ
確認済み
正直に言うと、バビロンの金庫がビットコインでイーサリアムの状態を直接検証できるという話を最初に読んだとき、それは「机上では素晴らしい」系の主張の一つだと思いました。ところがドキュメントを掘り下げてみると、実はどこにも見たことがないことをやっていると気づいたのです。 私の心を一番震わせたのはここです。金庫の作成時、預託者はタップルート(Taproot)スクリプトに対して共同署名します。このスクリプトには、イーサリアムの状態に対する暗号学的なコミットメントが含まれています。償還のタイミングになると、金庫プロバイダは単に署名するだけではありません。イーサリアムの状態(ブロックハッシュ、コラテラル比率、償還フラグ)が有効であることを、ビットコインで検証可能な形で証明する必要があります。このスクリプトは、ビットコインの既存のオペコードを使って、その証明を検証します。証明が通ればBTCはアンロックされます。通らなければ、ビットコイン自身のコンセンサスがその支払い(ススペンド)を拒否します。オラクルなし。マルチシグなし。信頼できる第三者なし。 本当の天才性は? その証明は、ガーブレッド回路を用いたカット&チョーズ(cut-and-choose)プロトコルであるBABEによって圧縮され、タップルート経由でビットコイン上で検証されます。これにより、ビットコインのUTXOが、他のチェーンの状態に基づいて「支払い可能性」をゲートする自己検証型のコントラクトになります。ビットコインのネイティブなスクリプト機能だけで実現しているのです。WBTCはカストディアンを使います。tBTCはしきい値署名を使います。バビロンは、クロスチェーンの真実を最終的に裁定する存在として、ビットコイン・スクリプトを使っています。そして、これが今テストネット上で動いているという事実は? それはホワイトペーパーの話ではなく、インフラです。@babylonlabs_io #baby $BABY $1000RATS $BTW
正直に言うと、バビロンの金庫がビットコインでイーサリアムの状態を直接検証できるという話を最初に読んだとき、それは「机上では素晴らしい」系の主張の一つだと思いました。ところがドキュメントを掘り下げてみると、実はどこにも見たことがないことをやっていると気づいたのです。

私の心を一番震わせたのはここです。金庫の作成時、預託者はタップルート(Taproot)スクリプトに対して共同署名します。このスクリプトには、イーサリアムの状態に対する暗号学的なコミットメントが含まれています。償還のタイミングになると、金庫プロバイダは単に署名するだけではありません。イーサリアムの状態(ブロックハッシュ、コラテラル比率、償還フラグ)が有効であることを、ビットコインで検証可能な形で証明する必要があります。このスクリプトは、ビットコインの既存のオペコードを使って、その証明を検証します。証明が通ればBTCはアンロックされます。通らなければ、ビットコイン自身のコンセンサスがその支払い(ススペンド)を拒否します。オラクルなし。マルチシグなし。信頼できる第三者なし。

本当の天才性は? その証明は、ガーブレッド回路を用いたカット&チョーズ(cut-and-choose)プロトコルであるBABEによって圧縮され、タップルート経由でビットコイン上で検証されます。これにより、ビットコインのUTXOが、他のチェーンの状態に基づいて「支払い可能性」をゲートする自己検証型のコントラクトになります。ビットコインのネイティブなスクリプト機能だけで実現しているのです。WBTCはカストディアンを使います。tBTCはしきい値署名を使います。バビロンは、クロスチェーンの真実を最終的に裁定する存在として、ビットコイン・スクリプトを使っています。そして、これが今テストネット上で動いているという事実は? それはホワイトペーパーの話ではなく、インフラです。@BabylonLabs_io #baby $BABY $1000RATS $BTW
Bitcoin-verifiable proof
0%
Taproot script
0%
opcodes
0%
0 投票 • 投票は終了しました
·
--
ブリッシュ
一部該当
正直に言うと、バビロンはチェックポイントの安全性のためにバリデータの1/3で足りるだけだと最初に読んだとき、思わず二度見しました。暗号の世界では、セキュリティの“魔法の数字”は2/3だと考えるように学ばされます。でも、2022年のチェックポイントに関するブログを掘り下げるほど、彼らがまったく別のゲームをしているのだと気づきました。 ここがひねりです。バビロンはエポックの間、バリデータ集合を固定します。エポックが終わるまで、ステークは出入りしません。Vigilanteリレイヤーが、少なくとも1/3のバリデータから集約したBLS署名を取得して、OP_RETURN経由でBitcoinへ投入します。ただし、その1/3のチェックポイントはまだ“最終確定”ではなく、単なる候補です。決着をつける本当の審判は、Bitcoinのプルーフ・オブ・ワーク(PoW)です。もし悪意のある2/3の超多数が偽のチェックポイントを押し通そうとしても、正直な1/3の少数派は自分たちのバージョンをBitcoinに提出すればいい。不可逆的な深さ(6ブロック以上)に到達した最初のチェックポイントが、正規のアンカー(基準点)になります。 これにより、セキュリティモデル全体がひっくり返ります。アンボンド(解除)の速さは、もはやバリデータの投票権にボトルネックされません。ボトルネックになるのはBitcoinのブロック時間です。だからバビロンは、年間$10k未満のコストを保ちながら、50時間未満のアンボンドを実現できるのです。プロトコルは数学的に、回転するバリデータ集合の2/3を待つことのほうが、固定された集合の1/3を、Bitcoinの不変チェーンに署名させて待つことより実際にはセキュリティが低いと証明しています。これは、私が「時間ベースのビザンチン合意」と呼びたいものの最初の実装です。バリデータはデータを提出するために使われ、あとはNakamoto Consensusに重い作業を任せる。@babylonlabs_io #baby $BABY $MMT $KOMA
正直に言うと、バビロンはチェックポイントの安全性のためにバリデータの1/3で足りるだけだと最初に読んだとき、思わず二度見しました。暗号の世界では、セキュリティの“魔法の数字”は2/3だと考えるように学ばされます。でも、2022年のチェックポイントに関するブログを掘り下げるほど、彼らがまったく別のゲームをしているのだと気づきました。

ここがひねりです。バビロンはエポックの間、バリデータ集合を固定します。エポックが終わるまで、ステークは出入りしません。Vigilanteリレイヤーが、少なくとも1/3のバリデータから集約したBLS署名を取得して、OP_RETURN経由でBitcoinへ投入します。ただし、その1/3のチェックポイントはまだ“最終確定”ではなく、単なる候補です。決着をつける本当の審判は、Bitcoinのプルーフ・オブ・ワーク(PoW)です。もし悪意のある2/3の超多数が偽のチェックポイントを押し通そうとしても、正直な1/3の少数派は自分たちのバージョンをBitcoinに提出すればいい。不可逆的な深さ(6ブロック以上)に到達した最初のチェックポイントが、正規のアンカー(基準点)になります。

これにより、セキュリティモデル全体がひっくり返ります。アンボンド(解除)の速さは、もはやバリデータの投票権にボトルネックされません。ボトルネックになるのはBitcoinのブロック時間です。だからバビロンは、年間$10k未満のコストを保ちながら、50時間未満のアンボンドを実現できるのです。プロトコルは数学的に、回転するバリデータ集合の2/3を待つことのほうが、固定された集合の1/3を、Bitcoinの不変チェーンに署名させて待つことより実際にはセキュリティが低いと証明しています。これは、私が「時間ベースのビザンチン合意」と呼びたいものの最初の実装です。バリデータはデータを提出するために使われ、あとはNakamoto Consensusに重い作業を任せる。@BabylonLabs_io #baby $BABY $MMT $KOMA
1/3 of validators
100%
Nakamoto Consensus
0%
Vigilante relayer
0%
Bitcoin’s proof-of-work.
0%
1 投票 • 投票は終了しました
·
--
ブリッシュ
一部該当
率直に言うと、バビロンが7月にBTCのアンボンディング期間を1008ブロックから301ブロックへ引き下げたとき、たいていの人はそれをUXの勝利だと言って次に進みました。しかしドキュメントを掘り下げるほど、真の革新は速さではなく非対称性だと気づきました。 見落とされているメカニズムがあります。プロトコルは、アンボンディング遅延がチェックポイントの最終化タイムアウトを上回ることを要求する不変条件を強制しています。設定されているのは300 BTCブロックです。Vigilante Relayerは、エポックごと(約1時間)にBLS集約されたチェックポイントをBitcoinのOP_RETURNへ送信します。万一Finality Providerが二重署名すれば、EOTSの秘密鍵が露出し、投票権は即座にゼロになります。ただしBitcoinのPoWは確率的です。深いリオーグ(再編成)が理論上、そのチェックポイントを無効化する可能性はあります。 301と1008ブロックの不一致は、「時間的スラッシング・バッファー」を生みます。プロトコルは、BTCステークのスラッシングを最終化する前に、絶対的なBitcoinの最終性が得られるのを待ちます。もしリオーグが起きても、バビロンはパニック的に即スラッシュせず、停止します。長いBTCロックを、深い決済用の金庫として使うのです。これは、主観的な最終性ガジェットなしに、時間のディレーションによる非対称性を使ってnothing-at-stakeの誤謬を排除する実装として、私が見た最初のものです。そして、より速いイグジットよりずっと面白い。@babylonlabs_io #baby $BABY $DEXE $ON
率直に言うと、バビロンが7月にBTCのアンボンディング期間を1008ブロックから301ブロックへ引き下げたとき、たいていの人はそれをUXの勝利だと言って次に進みました。しかしドキュメントを掘り下げるほど、真の革新は速さではなく非対称性だと気づきました。

見落とされているメカニズムがあります。プロトコルは、アンボンディング遅延がチェックポイントの最終化タイムアウトを上回ることを要求する不変条件を強制しています。設定されているのは300 BTCブロックです。Vigilante Relayerは、エポックごと(約1時間)にBLS集約されたチェックポイントをBitcoinのOP_RETURNへ送信します。万一Finality Providerが二重署名すれば、EOTSの秘密鍵が露出し、投票権は即座にゼロになります。ただしBitcoinのPoWは確率的です。深いリオーグ(再編成)が理論上、そのチェックポイントを無効化する可能性はあります。

301と1008ブロックの不一致は、「時間的スラッシング・バッファー」を生みます。プロトコルは、BTCステークのスラッシングを最終化する前に、絶対的なBitcoinの最終性が得られるのを待ちます。もしリオーグが起きても、バビロンはパニック的に即スラッシュせず、停止します。長いBTCロックを、深い決済用の金庫として使うのです。これは、主観的な最終性ガジェットなしに、時間のディレーションによる非対称性を使ってnothing-at-stakeの誤謬を排除する実装として、私が見た最初のものです。そして、より速いイグジットよりずっと面白い。@BabylonLabs_io #baby $BABY $DEXE $ON
finality provider
0%
etos
0%
btc staking
0%
0 投票 • 投票は終了しました
·
--
ブリッシュ
一部該当
最初にバビロンが「ジェネシス」を“コントロール・プレーン”だと言ったと聞いたときは、正直ちょっと目を白黒させました。マーケティングっぽい言い回しに聞こえたんです。でも、メインネットが4月10日にローンチされてからこれが進化していくのを見ていると、今なら分かります。多くのL1は「目的地」になりたい。そこに行って、アプリを使って、出ていく。でもジェネシスはそれを目指していません。目的地の“裏側”にあるインフラ、つまり目的地を支える基盤です。 その裏付けになるのが数字です。フェーズ1では、135,000人以上の参加者から57,000BTC超(当時約46億ドル)を引き込みました。ブリッジも、ラップド・アセットもなく、ネイティブのビットコインを自己保管でロックしただけです。7月までに、ジェネシスは最初のBSN群をすでに発表していました。オズモーシス、スイ、マンタ、BOB、プルーム、そして他にもいくつか。これらはいずれも、セキュリティのルーティングとファイナリティの調整のためにジェネシスへ手数料を支払うことになります。つまり、収益モデルはスーパ線形にスケールする。BSNが増えるほど需要が増え、BABYを通じて流れる価値が増えるんです。 6月のV2アップグレードでは、多段(マルチホップ)の転送を可能にするIBC Packet Forwarding Middlewareと、24時間のアウトフローをBABY供給量の10%に上限を設けるIBC Rate Limitingが追加されました。派手な機能ではありません。防御的で、インフラ寄りの“手”です。そしてQ4にはEVMサポートがメインネットに入る予定で、Solidity開発者と、エンタープライズ規模のイーサリアムDeFiのプレイブック全体に道が開けます。 私が見続けている理由は、長期戦です。バビロンのロードマップは3つのフェーズ。供給側を構築する(完了、57K BTC)。そしてジェネシスを最初のBSNとして立ち上げる(完了)。最後に、需要側を完成させるための追加BSNをローンチする。ジェネシスは単に自分自身を確保しているだけではなく、ビットコインでセキュアされたWeb3の“中央のスイッチボード”になろうとしています。この構想がうまくいけば、BABYは単なるガバナンストークンではありません。暗号資産スタック全体の、まったく新しいレイヤーを動かす燃料になる。これは私自身も、かなり注意深く見ています。@babylonlabs_io #baby $BABY $DEXE $COTI
最初にバビロンが「ジェネシス」を“コントロール・プレーン”だと言ったと聞いたときは、正直ちょっと目を白黒させました。マーケティングっぽい言い回しに聞こえたんです。でも、メインネットが4月10日にローンチされてからこれが進化していくのを見ていると、今なら分かります。多くのL1は「目的地」になりたい。そこに行って、アプリを使って、出ていく。でもジェネシスはそれを目指していません。目的地の“裏側”にあるインフラ、つまり目的地を支える基盤です。

その裏付けになるのが数字です。フェーズ1では、135,000人以上の参加者から57,000BTC超(当時約46億ドル)を引き込みました。ブリッジも、ラップド・アセットもなく、ネイティブのビットコインを自己保管でロックしただけです。7月までに、ジェネシスは最初のBSN群をすでに発表していました。オズモーシス、スイ、マンタ、BOB、プルーム、そして他にもいくつか。これらはいずれも、セキュリティのルーティングとファイナリティの調整のためにジェネシスへ手数料を支払うことになります。つまり、収益モデルはスーパ線形にスケールする。BSNが増えるほど需要が増え、BABYを通じて流れる価値が増えるんです。

6月のV2アップグレードでは、多段(マルチホップ)の転送を可能にするIBC Packet Forwarding Middlewareと、24時間のアウトフローをBABY供給量の10%に上限を設けるIBC Rate Limitingが追加されました。派手な機能ではありません。防御的で、インフラ寄りの“手”です。そしてQ4にはEVMサポートがメインネットに入る予定で、Solidity開発者と、エンタープライズ規模のイーサリアムDeFiのプレイブック全体に道が開けます。

私が見続けている理由は、長期戦です。バビロンのロードマップは3つのフェーズ。供給側を構築する(完了、57K BTC)。そしてジェネシスを最初のBSNとして立ち上げる(完了)。最後に、需要側を完成させるための追加BSNをローンチする。ジェネシスは単に自分自身を確保しているだけではなく、ビットコインでセキュアされたWeb3の“中央のスイッチボード”になろうとしています。この構想がうまくいけば、BABYは単なるガバナンストークンではありません。暗号資産スタック全体の、まったく新しいレイヤーを動かす燃料になる。これは私自身も、かなり注意深く見ています。@BabylonLabs_io #baby $BABY $DEXE $COTI
Babylon genius
100%
etos
0%
finality provider
0%
4 投票 • 投票は終了しました
·
--
ブリッシュ
確認済み
ほとんどのステーキング・システムでは、署名を通常の投票と同じように扱います。Babylon のファイナリティ・プロバイダーの設計は、良い意味で少し手厳しいです 😅。そのドキュメントによると、ファイナリティ・プロバイダーはスタンドアロンの EOTS マネージャーを使って秘密鍵を安全に保ち、EOTS の公開ランダムネスをコミットし、ブロックのファイナリティ投票を送信します。つまり、その署名は単なる「参加しました」のサインではなく、署名者そのものを監視するために作られたセキュリティ・システムの一部なのです。 ここがひねりです。Babylon は、ファイナリティ・プロバイダーが二重署名すると、投票権がゼロに落ち、プロバイダーはトゥームストーン(無効化)され、露出した秘密鍵は、委任されたステークのすべてに対するスラッシング(罰則)トランザクションを完全に署名するために使えるようになります。言い換えると、悪い署名そのものが、証拠になり得るということです。これは、通常のバリデータ罰則とはまったく別のモデルです。 だから私は「自己実刑(自己帰罪)型のファイナリティ」と呼びたいです。署名する行為は、もはや単なる参加ではありません。負債(リスク)を伴うアクションです。同じ高さで互いに矛盾する 2 つのブロックに署名した場合、暗号がその不正を、曖昧なオフチェーンの主張や面倒な解釈に頼らずに暴きます。Babylon は、基本的に不正行為を自己認証的な証明へと変えているわけです。 そして、ここは見逃してはいけません。Babylon のセットアップ手順は、登録、EOTS 鍵の作成、そして理由のある制御されたオペレーションを中心に組み立てられています。この仕組みは、「事後に悪い行いを罰するだけ」ではなく、暗号学的レイヤーでファイナリティを説明責任あるものにしようとしています。これはより強いセキュリティの物語であり、正直なところ、ずっと面白いものです。 🔐 @babylonlabs_io #baby $BABY $DEXE $BTW
ほとんどのステーキング・システムでは、署名を通常の投票と同じように扱います。Babylon のファイナリティ・プロバイダーの設計は、良い意味で少し手厳しいです 😅。そのドキュメントによると、ファイナリティ・プロバイダーはスタンドアロンの EOTS マネージャーを使って秘密鍵を安全に保ち、EOTS の公開ランダムネスをコミットし、ブロックのファイナリティ投票を送信します。つまり、その署名は単なる「参加しました」のサインではなく、署名者そのものを監視するために作られたセキュリティ・システムの一部なのです。

ここがひねりです。Babylon は、ファイナリティ・プロバイダーが二重署名すると、投票権がゼロに落ち、プロバイダーはトゥームストーン(無効化)され、露出した秘密鍵は、委任されたステークのすべてに対するスラッシング(罰則)トランザクションを完全に署名するために使えるようになります。言い換えると、悪い署名そのものが、証拠になり得るということです。これは、通常のバリデータ罰則とはまったく別のモデルです。

だから私は「自己実刑(自己帰罪)型のファイナリティ」と呼びたいです。署名する行為は、もはや単なる参加ではありません。負債(リスク)を伴うアクションです。同じ高さで互いに矛盾する 2 つのブロックに署名した場合、暗号がその不正を、曖昧なオフチェーンの主張や面倒な解釈に頼らずに暴きます。Babylon は、基本的に不正行為を自己認証的な証明へと変えているわけです。

そして、ここは見逃してはいけません。Babylon のセットアップ手順は、登録、EOTS 鍵の作成、そして理由のある制御されたオペレーションを中心に組み立てられています。この仕組みは、「事後に悪い行いを罰するだけ」ではなく、暗号学的レイヤーでファイナリティを説明責任あるものにしようとしています。これはより強いセキュリティの物語であり、正直なところ、ずっと面白いものです。 🔐

@BabylonLabs_io #baby $BABY $DEXE $BTW
finality provider
0%
etos
0%
btc staking
0%
0 投票 • 投票は終了しました
·
--
ブリッシュ
バビロンの過小評価されたセキュリティ層は「スラッシング」ではない。運用規律だ。 私たちは通常、バビロンのファイナリティ・プロバイダをこう語りがちだ: ノードを動かす。ファイナリティに署名する。不正に振る舞わない。 簡単でしょう? でも、実際はそうでもない。 現実のインフラで難しいのは、もっと面白味のない問題であることが多い: 人的ミス + ぐちゃぐちゃした運用 + 一貫しないセットアップ。 誤った設定。 壊れたRPC。 不適切なインデックス。 鍵管理のミス。 バージョン不一致。 これらはどれも、派手には聞こえない。 しかしセキュリティシステムでは、小さな運用ミスが非常に現実的な結果を生み得る。 だからこそ、私はバビロンのファイナリティ・プロバイダ設定に興味を持っている。 FPのワークフローは、特定の手順に沿って構成されている:ツールをインストールする、EOTSキーを作成する、EOTSサービスを実行する、FPキーを作成する、プロバイダを設定する、登録する、そしてデプロイを検証する。 またドキュメントは、専用インフラ、信頼できるRPC接続、トランザクションのインデックス、重複投票の監視、状態遷移、定義されたアンジャイル手順といった運用面の詳細も強調している。 私には、ここからもっと大きな考えが見えてくる: 運用エントロピーの最小化。 バビロンの公式用語ではない—私自身の枠組みだ。 目的は、何かが起きた後に悪い挙動を検知することだけではない。 避けられるミスが起きにくいほど、運用環境を予測可能にすることだ。 たとえば航空機のコクピットを考えてほしい。 安全性は、良いパイロットがいることだけに依存しない。チェックリスト、標準手順、監視、そして再現可能なシステムにも依存する。 ファイナリティ・プロバイダにも同じ考え方が必要だ。 なぜならFPがセキュリティシステムの一部になると、「うちのサーバでは動く」では十分ではないからだ。 セットアップは、再現可能で、観測可能で、そして退屈であるべきだ。 正直、インフラにおける「退屈さ」は過小評価されている。😅 より深い @babylonlabs_io の物語は、たぶんこうだ: 安全なファイナリティ・プロバイダとは、ブロックに署名するだけのマシンではない。 それは、ソフトウェア・鍵・人間のプロセスがすべて一貫して振る舞わなければならない、細心に運用されるセキュリティ装置だ。 そうしてはじめて、運用上の混乱に転ばずにセキュリティをスケールできる。 #baby $BABY $DEXE $BANK
バビロンの過小評価されたセキュリティ層は「スラッシング」ではない。運用規律だ。

私たちは通常、バビロンのファイナリティ・プロバイダをこう語りがちだ:

ノードを動かす。ファイナリティに署名する。不正に振る舞わない。

簡単でしょう?

でも、実際はそうでもない。

現実のインフラで難しいのは、もっと面白味のない問題であることが多い:

人的ミス + ぐちゃぐちゃした運用 + 一貫しないセットアップ。

誤った設定。
壊れたRPC。
不適切なインデックス。
鍵管理のミス。
バージョン不一致。

これらはどれも、派手には聞こえない。

しかしセキュリティシステムでは、小さな運用ミスが非常に現実的な結果を生み得る。

だからこそ、私はバビロンのファイナリティ・プロバイダ設定に興味を持っている。

FPのワークフローは、特定の手順に沿って構成されている:ツールをインストールする、EOTSキーを作成する、EOTSサービスを実行する、FPキーを作成する、プロバイダを設定する、登録する、そしてデプロイを検証する。

またドキュメントは、専用インフラ、信頼できるRPC接続、トランザクションのインデックス、重複投票の監視、状態遷移、定義されたアンジャイル手順といった運用面の詳細も強調している。

私には、ここからもっと大きな考えが見えてくる:

運用エントロピーの最小化。

バビロンの公式用語ではない—私自身の枠組みだ。

目的は、何かが起きた後に悪い挙動を検知することだけではない。

避けられるミスが起きにくいほど、運用環境を予測可能にすることだ。

たとえば航空機のコクピットを考えてほしい。

安全性は、良いパイロットがいることだけに依存しない。チェックリスト、標準手順、監視、そして再現可能なシステムにも依存する。

ファイナリティ・プロバイダにも同じ考え方が必要だ。

なぜならFPがセキュリティシステムの一部になると、「うちのサーバでは動く」では十分ではないからだ。

セットアップは、再現可能で、観測可能で、そして退屈であるべきだ。

正直、インフラにおける「退屈さ」は過小評価されている。😅

より深い @BabylonLabs_io の物語は、たぶんこうだ:

安全なファイナリティ・プロバイダとは、ブロックに署名するだけのマシンではない。

それは、ソフトウェア・鍵・人間のプロセスがすべて一貫して振る舞わなければならない、細心に運用されるセキュリティ装置だ。

そうしてはじめて、運用上の混乱に転ばずにセキュリティをスケールできる。
#baby $BABY $DEXE $BANK
finality provider
40%
eots
40%
Bitcoin security
20%
5 投票 • 投票は終了しました
·
--
ブリッシュ
以前は、自主保管(セルフ・カストディー)がかなり単純な方程式だと思っていました: 秘密鍵=所有。 鍵を失えば?終わり。 でも、@babylonlabs_io TBVがその方程式を別の見方にしてくれました。 BTCがビットコインから出ていくからではありません。出ていません。 面白いのは、BTCの周りで何が起きるかです。 Trustless Bitcoin Vaults(トラストレス・ビットコイン・ボールト)では、ビットコインはタップルート型のボールト内にあり、あらかじめ定義された支払い条件が設定されています。つまり、ユーザーは自分のビットコイン鍵を引き続き管理している一方で、資産はより複雑な暗号学的状態の中で動作しています。 そして、ここが本題で面白いところです。 預託者は、WOTS鍵の素材やクレイマーのアーティファクトなど、追加の回復用素材を持てます。これらが、フォールバックによる自己請求や、チャレンジ(異議申し立て)プロセスを支えるのです。 そこで私は、Recovery Sovereignty(回復の主権)という概念を考え始めました。 バビロンの製品用語ではありません。私自身の枠組みです。 考え方はシンプルです: 自主保管は、鍵を持っていることだけではありません。回復権を行使できる情報を保持することでもあるのです。 家を所有しているように考えてください。 あなたは玄関の鍵を持っています。 でも、特別なアクセスコードでしか作動しない非常口が他にもあるとしたら? あなたはそれでも家を所有しています。 しかし、独力でアクセスを回復できるかどうかは、複数の情報に依存します。 これが、TBVがもたらす微妙な転換です。 もしボールト・プロバイダーが通常どおり動作するなら、標準の償還フローがそのプロセスを処理できます。 しかし、何かがうまくいかず、フォールバック経路が必要になった場合、そうした回復用アーティファクトの重要性が一気に高まります。 そして、それこそが私が「ビットコインDeFi」が十分に語ってこなかった部分だと思うところです。 私たちは何年も問い続けてきました: 「誰が秘密鍵を管理しているのか?」 次の問いは、もしかするとこうかもしれません: 「誰が回復能力を管理しているのか?」 なぜなら、状態を持つビットコイン・ボールトでは、主権は単に鍵の保管だけではないからです。 それは情報の保管でもあります。 そして正直なところ、それははるかに難しい問題です。 あなたのシードフレーズは紙に収まるかもしれません。 あなたの回復の主権は、暗号学的な知識の“仕組み”そのものを必要とするかもしれません。 #baby $BABY $DEXE $BEAT
以前は、自主保管(セルフ・カストディー)がかなり単純な方程式だと思っていました:

秘密鍵=所有。

鍵を失えば?終わり。

でも、@BabylonLabs_io TBVがその方程式を別の見方にしてくれました。

BTCがビットコインから出ていくからではありません。出ていません。

面白いのは、BTCの周りで何が起きるかです。

Trustless Bitcoin Vaults(トラストレス・ビットコイン・ボールト)では、ビットコインはタップルート型のボールト内にあり、あらかじめ定義された支払い条件が設定されています。つまり、ユーザーは自分のビットコイン鍵を引き続き管理している一方で、資産はより複雑な暗号学的状態の中で動作しています。

そして、ここが本題で面白いところです。

預託者は、WOTS鍵の素材やクレイマーのアーティファクトなど、追加の回復用素材を持てます。これらが、フォールバックによる自己請求や、チャレンジ(異議申し立て)プロセスを支えるのです。

そこで私は、Recovery Sovereignty(回復の主権)という概念を考え始めました。

バビロンの製品用語ではありません。私自身の枠組みです。

考え方はシンプルです:

自主保管は、鍵を持っていることだけではありません。回復権を行使できる情報を保持することでもあるのです。

家を所有しているように考えてください。
あなたは玄関の鍵を持っています。

でも、特別なアクセスコードでしか作動しない非常口が他にもあるとしたら?

あなたはそれでも家を所有しています。

しかし、独力でアクセスを回復できるかどうかは、複数の情報に依存します。

これが、TBVがもたらす微妙な転換です。

もしボールト・プロバイダーが通常どおり動作するなら、標準の償還フローがそのプロセスを処理できます。

しかし、何かがうまくいかず、フォールバック経路が必要になった場合、そうした回復用アーティファクトの重要性が一気に高まります。

そして、それこそが私が「ビットコインDeFi」が十分に語ってこなかった部分だと思うところです。

私たちは何年も問い続けてきました:

「誰が秘密鍵を管理しているのか?」

次の問いは、もしかするとこうかもしれません:

「誰が回復能力を管理しているのか?」

なぜなら、状態を持つビットコイン・ボールトでは、主権は単に鍵の保管だけではないからです。

それは情報の保管でもあります。

そして正直なところ、それははるかに難しい問題です。

あなたのシードフレーズは紙に収まるかもしれません。

あなたの回復の主権は、暗号学的な知識の“仕組み”そのものを必要とするかもしれません。
#baby $BABY $DEXE $BEAT
·
--
ブリッシュ
確認済み
#baby $BABY TBVパラドックス:なぜビットコイン最大の「欠陥」がその秘密兵器になるのか 今週ずっとBTCFiのデータを眺めていて、なにか引っかかっています。 現時点でビットコインの約1%しかDeFiに置かれていません。残りの99%は?ただ…そこにあります。正直、理由もわかります。 「BTCを働かせよう」という選択肢を見ていると、いつも同じ売り文句です。ラップする、ブリッジする、誰かに預ける。お断りです。ブリッジが爆散するのを十分に見てきたので、あのゲームは自分には合いません。 でもバビロンのTBVの仕組みは、頭の中をかき乱しています。 ひねりはこうです。ビットコインをどこかへ動かそうとしているわけではありません。あなたのBTCはビットコイン上にそのまま置かれ、Taproot UTXOにロックされます。イーサリアムはただ見ているだけ。借り入れるときの償還には、ゼロ知識証明が必要で、それはBABEというものを通じて検証されるそうです。しかもコストを1,000×も削減するとのこと。UCバークレーで開発され、査読付きで、CCS 2026に向けて準備中。 ただ、ここからが本当に変です。 通常のDeFiプロトコルなら、あなたのポジションの37%を清算できてしまいます。TBVはできません。ビットコインのUTXOは分割できないからです。あなたは、金庫(ボールト)丸ごとを差し押さえるか、何もしないかのどちらか。多くの人はこれを制限だと見ます。私は、今の暗号資産で最も面白い制約だと見ています。 解決策は?清算(リクイデーション)の流動性プロバイダーです。イーサリアム上で即時に決済し、BTCの償還はバックグラウンドで進めます。ガサついている?たぶん。けれど誠実です。ビットコインの性質に逆らうのではなく、受け入れて機能します。 Aaveの創設者はすでにこの提案を後押ししています。バビロンはステークされたBTCを4B+持っています。もはや適当なテストネット実験ではありません。 BTCFiの未来は、「ビットコインをイーサリアムのように振る舞わせる」ことではないかもしれません。ビットコイン本来の“分割できない状態”を核に、信用(クレジット)を組み立てることかもしれません。 @babylonlabs_io $DEXE $BANK
#baby $BABY
TBVパラドックス:なぜビットコイン最大の「欠陥」がその秘密兵器になるのか

今週ずっとBTCFiのデータを眺めていて、なにか引っかかっています。

現時点でビットコインの約1%しかDeFiに置かれていません。残りの99%は?ただ…そこにあります。正直、理由もわかります。

「BTCを働かせよう」という選択肢を見ていると、いつも同じ売り文句です。ラップする、ブリッジする、誰かに預ける。お断りです。ブリッジが爆散するのを十分に見てきたので、あのゲームは自分には合いません。

でもバビロンのTBVの仕組みは、頭の中をかき乱しています。

ひねりはこうです。ビットコインをどこかへ動かそうとしているわけではありません。あなたのBTCはビットコイン上にそのまま置かれ、Taproot UTXOにロックされます。イーサリアムはただ見ているだけ。借り入れるときの償還には、ゼロ知識証明が必要で、それはBABEというものを通じて検証されるそうです。しかもコストを1,000×も削減するとのこと。UCバークレーで開発され、査読付きで、CCS 2026に向けて準備中。

ただ、ここからが本当に変です。

通常のDeFiプロトコルなら、あなたのポジションの37%を清算できてしまいます。TBVはできません。ビットコインのUTXOは分割できないからです。あなたは、金庫(ボールト)丸ごとを差し押さえるか、何もしないかのどちらか。多くの人はこれを制限だと見ます。私は、今の暗号資産で最も面白い制約だと見ています。

解決策は?清算(リクイデーション)の流動性プロバイダーです。イーサリアム上で即時に決済し、BTCの償還はバックグラウンドで進めます。ガサついている?たぶん。けれど誠実です。ビットコインの性質に逆らうのではなく、受け入れて機能します。

Aaveの創設者はすでにこの提案を後押ししています。バビロンはステークされたBTCを4B+持っています。もはや適当なテストネット実験ではありません。

BTCFiの未来は、「ビットコインをイーサリアムのように振る舞わせる」ことではないかもしれません。ビットコイン本来の“分割できない状態”を核に、信用(クレジット)を組み立てることかもしれません。
@BabylonLabs_io $DEXE $BANK
tbv
25%
Bitcoin slashing
50%
taproot utx
25%
btc collateral engine
0%
4 投票 • 投票は終了しました
·
--
弱気相場
$B で高い確度のセットアップを確認しています。 価格が0.26ドルから0.25ドルのゾーンにタップ(到達)する場合、そのゾーンでベア(弱気)のサインを見たときに限り、0.1ドルまで下落する可能性が高いです。
$B で高い確度のセットアップを確認しています。
価格が0.26ドルから0.25ドルのゾーンにタップ(到達)する場合、そのゾーンでベア(弱気)のサインを見たときに限り、0.1ドルまで下落する可能性が高いです。
·
--
ブリッシュ
以前は取引よりも清算(リキデーション)レベルをよく眺めていました... でもGRVTがどのようにリスクを扱うのか読んでから考えが変わったんです。🤔 暗号資産の長年の経験で身についた習慣として、エントリーをじっと見つめることはほとんどなくなりました。代わりに、トレーダーがどこで崩れ得るのかを見るんです。だいたい、そこでこそ本当の物語が動いています。 GRVTのアーキテクチャを読んで、その習慣を見直すきっかけになりました。 GRVTに関する会話の多くは「プライバシー」に止まっています。でも、私にとっていちばん面白いのはそこではありません。特に印象的だったのは、プラットフォームがリスクの執行(enforcement)と、公開される可視性を分離している点です。 GRVTのドキュメントによると、マッチングはオフチェーンで行われる一方、決済とマージン管理はオンチェーンに根付いています。また、ZKsync Validiumは、ポジションや取引詳細のようなセンシティブな取引情報を公開チェーンに露出させない一方で、Ethereumは状態遷移の有効性を引き続き検証すると書かれています。 私にとってそれは、市場の情報の「見え方」を変えます。 リスクは消えません。清算ルールは存在し続けます。マージンも依然として重要です。ですが、センシティブなポジションデータが公にブロードキャストされないなら、他の参加者はすべてのトレーダーが脆い瞬間に直面するたび、その様子をリアルタイムで学習することができません。ここには大きな違いがあります。 私はこの方向性、実は好ましいと思っています。暗号資産ではときどき「透明性」と「すべてをさらけ出すこと」が混同されてしまうからです。それらは必ずしも同じではありません。すべてのポジションを公開のインテリジェンスに変えなくても、市場は検証可能であり得ます。 GRVTの設計から得た最大の学びはそこです。取引を隠すことが主眼というより、「証明されるべきもの」と「公開データにする必要がないもの」をどう決めるか、という話だと感じました。 もしこのバランスが意図どおりに機能するなら、それはリスクを消すから面白いのではなく、どれだけそのリスクが他の全員に見えるようになるのかを変えるからこそ、ハイブリッド取引所のアーキテクチャにおけるより興味深いアイデアの一つになり得ると思います。@grvt_io #grvt
以前は取引よりも清算(リキデーション)レベルをよく眺めていました... でもGRVTがどのようにリスクを扱うのか読んでから考えが変わったんです。🤔

暗号資産の長年の経験で身についた習慣として、エントリーをじっと見つめることはほとんどなくなりました。代わりに、トレーダーがどこで崩れ得るのかを見るんです。だいたい、そこでこそ本当の物語が動いています。

GRVTのアーキテクチャを読んで、その習慣を見直すきっかけになりました。

GRVTに関する会話の多くは「プライバシー」に止まっています。でも、私にとっていちばん面白いのはそこではありません。特に印象的だったのは、プラットフォームがリスクの執行(enforcement)と、公開される可視性を分離している点です。
GRVTのドキュメントによると、マッチングはオフチェーンで行われる一方、決済とマージン管理はオンチェーンに根付いています。また、ZKsync Validiumは、ポジションや取引詳細のようなセンシティブな取引情報を公開チェーンに露出させない一方で、Ethereumは状態遷移の有効性を引き続き検証すると書かれています。

私にとってそれは、市場の情報の「見え方」を変えます。

リスクは消えません。清算ルールは存在し続けます。マージンも依然として重要です。ですが、センシティブなポジションデータが公にブロードキャストされないなら、他の参加者はすべてのトレーダーが脆い瞬間に直面するたび、その様子をリアルタイムで学習することができません。ここには大きな違いがあります。
私はこの方向性、実は好ましいと思っています。暗号資産ではときどき「透明性」と「すべてをさらけ出すこと」が混同されてしまうからです。それらは必ずしも同じではありません。すべてのポジションを公開のインテリジェンスに変えなくても、市場は検証可能であり得ます。

GRVTの設計から得た最大の学びはそこです。取引を隠すことが主眼というより、「証明されるべきもの」と「公開データにする必要がないもの」をどう決めるか、という話だと感じました。

もしこのバランスが意図どおりに機能するなら、それはリスクを消すから面白いのではなく、どれだけそのリスクが他の全員に見えるようになるのかを変えるからこそ、ハイブリッド取引所のアーキテクチャにおけるより興味深いアイデアの一つになり得ると思います。@grvt_io #grvt
·
--
ブリッシュ
@grvt_io #grvt GRVTについて私が惹かれたのは「利回り(yield)」という言葉そのものではありませんでした。そこにある“配管”――仕組みのほうです。 暗号資産のプロダクトがAPYを追いかけるのをよく見ますが、それが物語の全てだとでもいうように。しかしGRVTは、もっと厄介で、そしてより実用的なもの――遊休の取引所リザーブを、生産的に活かしつつ、出金を痛みに変えないこと――を狙っています。GRVTのヘルプセンターによると、Yield Layer(利回りレイヤー)は、最初にAave V3のUSDTプールから始めて、ほとんどの遊休の取引所リザーブを自動的にEthereum L1のDeFiへデプロイし、取引レイヤー側では日常の出金に備えるための小さめの運用残高を維持するとのことです。 それは別の発想です。「資金をロックして、利回りを期待する」といったものではなく、DeFiエンジンを取り付けた“準備金管理”に近い。さらにGRVTは、ほとんどの出金は即時のままで、チェーン対応された出金はブリッジ・パートナーによりほぼ即時を維持し、非常に大きなEthereum L1の出金だけが、時々短いキューに入る可能性があると言っています。この細部は、人々が考えるよりずっと重要です。流動性は、動かそうと思えばまだ速く動けるときにこそ本物に感じられるからです。$DODO ここから見て、これはGRVTの本当の主張だと思います。1つの残高で複数の役割を果たせるべきだということ。取引もし、稼ぎもでき、それでもアクセスしやすいままでいること。その考え方は、GRVTが書いてきたより大きな方向性とも合致しています。すなわち、資本生産性の高いDEX、一つの残高の設計、そして、遊んで死んだままの資金が存在しない資本ライフサイクルです。$JCT 私はそれを“魔法”だと言っているわけではありません。もっと綺麗な問いだと言っています。取引所は、ユーザーが閉じ込められた感覚を持たないようにしながら、フロート(預かり資金)で稼げるのか? GRVTの答え、少なくとも紙の上では、流動性を“弾力的(elastic)”にすることです。そして率直に言えば、その点こそが注目に値します。
@grvt_io #grvt

GRVTについて私が惹かれたのは「利回り(yield)」という言葉そのものではありませんでした。そこにある“配管”――仕組みのほうです。

暗号資産のプロダクトがAPYを追いかけるのをよく見ますが、それが物語の全てだとでもいうように。しかしGRVTは、もっと厄介で、そしてより実用的なもの――遊休の取引所リザーブを、生産的に活かしつつ、出金を痛みに変えないこと――を狙っています。GRVTのヘルプセンターによると、Yield Layer(利回りレイヤー)は、最初にAave V3のUSDTプールから始めて、ほとんどの遊休の取引所リザーブを自動的にEthereum L1のDeFiへデプロイし、取引レイヤー側では日常の出金に備えるための小さめの運用残高を維持するとのことです。

それは別の発想です。「資金をロックして、利回りを期待する」といったものではなく、DeFiエンジンを取り付けた“準備金管理”に近い。さらにGRVTは、ほとんどの出金は即時のままで、チェーン対応された出金はブリッジ・パートナーによりほぼ即時を維持し、非常に大きなEthereum L1の出金だけが、時々短いキューに入る可能性があると言っています。この細部は、人々が考えるよりずっと重要です。流動性は、動かそうと思えばまだ速く動けるときにこそ本物に感じられるからです。$DODO
ここから見て、これはGRVTの本当の主張だと思います。1つの残高で複数の役割を果たせるべきだということ。取引もし、稼ぎもでき、それでもアクセスしやすいままでいること。その考え方は、GRVTが書いてきたより大きな方向性とも合致しています。すなわち、資本生産性の高いDEX、一つの残高の設計、そして、遊んで死んだままの資金が存在しない資本ライフサイクルです。$JCT

私はそれを“魔法”だと言っているわけではありません。もっと綺麗な問いだと言っています。取引所は、ユーザーが閉じ込められた感覚を持たないようにしながら、フロート(預かり資金)で稼げるのか? GRVTの答え、少なくとも紙の上では、流動性を“弾力的(elastic)”にすることです。そして率直に言えば、その点こそが注目に値します。
Mining
67%
Token supply
0%
liquidity
33%
gass fees
0%
3 投票 • 投票は終了しました
·
--
ブリッシュ
先日、ポートフォリオを見つめている自分に気づいて、あることを理解しました……。私の最大のポジションが損失を出していたわけではなかったんです。 それは、ただ完全に何もしないでいることでした。 これは暗号資産では妙な現実です。1つの残高は証拠金になります。別の残高はイールド・ボルトに置かれます。現物資産は次の動きを待ちます。すべてのドルに1つの仕事が割り当てられ、残りの可能性は駐車場みたいに滞在してしまう。 GRVTの公式ドキュメントを読むことで、これを別の見方で捉えるようになりました。 彼らの「One Unified Balance」は、単にインターフェースをスッキリさせるためだけのものではありません。GRVTは、同じ対象となる残高で統合証拠金を通じた取引を支えつつ、同時に利回りを得られるとも言っています。また、資金を分断された接続不能な口座にばらけさせずに、投資商品へアクセスできる。要するに、資金の移動が速くなる話ではなく、経済的にアイドル状態のまま過ごす時間を減らすことなんです。 この違いが私に刺さりました。 私はそれを「資本の回転速度(capital velocity)」として考え始めています。「いくら担保があるか?」ではなく、「この1ドルは今日、どれだけ役に立つ仕事をこなしているか?」 視点の小さな変化ですが、プラットフォームの評価の仕方が変わります。 もし2つの取引所が、同じ量のユーザー入金を引き付けるなら、より重要な問いは『どちらがより多くの資産を抱えているか』ではありません。『どちらが、その資産をより長く生産的な状態に保つのを助けるか』です。それは、取引所がトレーディング以外にも、利回り提供、投資、そしてトークン化された実世界資産へと拡張していく中で、ますます重要になってきています。 もちろん、アーキテクチャだけで成功が保証されるわけではありません。このモデルが実際に機能するかどうかは、採用(アドプション)次第です。 それでも、私はこの方向性が良いと思っています。 長年、暗号資産は「お金がどれだけ速く動けるか」を最適化してきました。 次の課題は、そもそもお金が働くのを止めなくて済むようにすることなのかもしれません。 取引所設計の未来にとって、何が最も重要だと思いますか? @grvt_io #grvt $TUSD $LAB
先日、ポートフォリオを見つめている自分に気づいて、あることを理解しました……。私の最大のポジションが損失を出していたわけではなかったんです。
それは、ただ完全に何もしないでいることでした。
これは暗号資産では妙な現実です。1つの残高は証拠金になります。別の残高はイールド・ボルトに置かれます。現物資産は次の動きを待ちます。すべてのドルに1つの仕事が割り当てられ、残りの可能性は駐車場みたいに滞在してしまう。
GRVTの公式ドキュメントを読むことで、これを別の見方で捉えるようになりました。
彼らの「One Unified Balance」は、単にインターフェースをスッキリさせるためだけのものではありません。GRVTは、同じ対象となる残高で統合証拠金を通じた取引を支えつつ、同時に利回りを得られるとも言っています。また、資金を分断された接続不能な口座にばらけさせずに、投資商品へアクセスできる。要するに、資金の移動が速くなる話ではなく、経済的にアイドル状態のまま過ごす時間を減らすことなんです。
この違いが私に刺さりました。
私はそれを「資本の回転速度(capital velocity)」として考え始めています。「いくら担保があるか?」ではなく、「この1ドルは今日、どれだけ役に立つ仕事をこなしているか?」
視点の小さな変化ですが、プラットフォームの評価の仕方が変わります。
もし2つの取引所が、同じ量のユーザー入金を引き付けるなら、より重要な問いは『どちらがより多くの資産を抱えているか』ではありません。『どちらが、その資産をより長く生産的な状態に保つのを助けるか』です。それは、取引所がトレーディング以外にも、利回り提供、投資、そしてトークン化された実世界資産へと拡張していく中で、ますます重要になってきています。
もちろん、アーキテクチャだけで成功が保証されるわけではありません。このモデルが実際に機能するかどうかは、採用(アドプション)次第です。
それでも、私はこの方向性が良いと思っています。
長年、暗号資産は「お金がどれだけ速く動けるか」を最適化してきました。
次の課題は、そもそもお金が働くのを止めなくて済むようにすることなのかもしれません。
取引所設計の未来にとって、何が最も重要だと思いますか?

@grvt_io #grvt $TUSD $LAB
Faster trading execution
100%
Higher capital efficiency
0%
Lower trading fees.
0%
Keeping one balance productive
0%
3 投票 • 投票は終了しました
·
--
ブリッシュ
確認済み
GRVTを初めて詳しく見たとき、私は「自己保管」をスローガンとして考えるのをやめました。これはむしろ制御システムのように読めます。 GRVTは、自己保管とは自分で自分の資金を保持することであり、あなたを含めない限り、Grvtを含む誰もあなたの同意なしに資金を動かせないと述べています。そして、その資金はオンチェーンのスマートコントラクトに預けられており、あなたの鍵に署名があったときだけそれが開きます。Grvtは決してあなたの鍵を保有しません。 そして、私にとって景色を変えたのがSecureKeyです。GRVTは、SecureKeyは取引機能のためのWeb3クレデンシャルであり、秘密鍵を持っているのはユーザーだけで、資産の所有権を変更するようなあらゆる操作にはSecureKeyの署名が必要だと言っています。 次にアドレス帳(Address Book)があります。GRVTは、資金口座のアセットが移動できる宛先を、事前に承認された受取人に限定します。さらにビジネスアカウントでは、アドレスの追加に際して、資金管理者(Funding Admins)が、アクティブなマルチシグネチャのしきい値の下でサインオフを行う必要があります。 出金にはもう一段の層があります。ビジネスアカウントでは、GRVTは2FAとSecureKey署名を要求し、アドレス帳にアドレスを追加して承認するにはそれが必要です。そして管理者が複数いる場合は、まずマルチシグネチャのしきい値を満たさなければなりません。 だから私は、GRVTを「生の自己保管」ではなく、「ポリシーでロックされたカストディ・スタック」と表現するでしょう。署名者が許可し、コントラクトが保持し、許可リストが送付先を絞り込み、必要に応じて管理者レイヤーが追加の承認を加えられます。GRVTはまた、自社のオンチェーン・システムがEthereumメインネット上でLayer 2のコントラクトとして動作し、自己保管、決済、マージン管理、リスクエンジン、出金リクエストをカバーしているとも述べています。 私の見立ては?その構成は「コントロールは欲しいが、混乱は欲しくない」人のために作られているように感じます。 @grvt_io #grvt $XPIN $BEAT あなたにとって最も大切なのは何ですか?
GRVTを初めて詳しく見たとき、私は「自己保管」をスローガンとして考えるのをやめました。これはむしろ制御システムのように読めます。
GRVTは、自己保管とは自分で自分の資金を保持することであり、あなたを含めない限り、Grvtを含む誰もあなたの同意なしに資金を動かせないと述べています。そして、その資金はオンチェーンのスマートコントラクトに預けられており、あなたの鍵に署名があったときだけそれが開きます。Grvtは決してあなたの鍵を保有しません。
そして、私にとって景色を変えたのがSecureKeyです。GRVTは、SecureKeyは取引機能のためのWeb3クレデンシャルであり、秘密鍵を持っているのはユーザーだけで、資産の所有権を変更するようなあらゆる操作にはSecureKeyの署名が必要だと言っています。
次にアドレス帳(Address Book)があります。GRVTは、資金口座のアセットが移動できる宛先を、事前に承認された受取人に限定します。さらにビジネスアカウントでは、アドレスの追加に際して、資金管理者(Funding Admins)が、アクティブなマルチシグネチャのしきい値の下でサインオフを行う必要があります。
出金にはもう一段の層があります。ビジネスアカウントでは、GRVTは2FAとSecureKey署名を要求し、アドレス帳にアドレスを追加して承認するにはそれが必要です。そして管理者が複数いる場合は、まずマルチシグネチャのしきい値を満たさなければなりません。
だから私は、GRVTを「生の自己保管」ではなく、「ポリシーでロックされたカストディ・スタック」と表現するでしょう。署名者が許可し、コントラクトが保持し、許可リストが送付先を絞り込み、必要に応じて管理者レイヤーが追加の承認を加えられます。GRVTはまた、自社のオンチェーン・システムがEthereumメインネット上でLayer 2のコントラクトとして動作し、自己保管、決済、マージン管理、リスクエンジン、出金リクエストをカバーしているとも述べています。
私の見立ては?その構成は「コントロールは欲しいが、混乱は欲しくない」人のために作られているように感じます。

@grvt_io #grvt $XPIN $BEAT
あなたにとって最も大切なのは何ですか?
Multi-signature approvals
0%
Address Book
0%
Smart-contract custody
0%
security key
100%
1 投票 • 投票は終了しました
·
--
ブリッシュ
確認済み
#grvt @grvt_io $SKL 一部の取引所は「スピードか信頼か」を選ばせようとしているように感じます。その点は、ずっと少し気になっていました。 仮想通貨の現場で十分な時間を過ごしてきたので分かりますが、そのトレードオフはたいてい“きれいなUIの裏”に隠されています。片側では高速マッチング、別のところではカストディと決済。そしてその間には摩擦が大量にある。GRVTの公式ドキュメントは別の道を取っています。スピードのためにオフチェーンで注文をマッチしつつ、決済、カストディ、リスク管理は検証可能性とセルフカストディのためにオンチェーンに保つのです。 だから私はGRVTを「2つの時計を持つ市場」だと考え続けています。1つの時計は価格発見と執行のため。もう1つは証明、最終性、そしてコントロールのため。これらは同じ仕事ではなく、同一だとみなしてしまうと、ぎこちないプロダクトになりがちです。 私がいちばん“今っぽい”と感じるのは「1つの残高(one balance)」の発想です。GRVTのロードマップやプロダクトページには、分離したサイロの中で資本を遊ばせることなく、稼ぐ・取引する・投資することができる、単一のプログラマブル残高が記されています。これは市場が向かっている方向とも一致しています。人々は担保を、ただ待機させる以上のことに使いたいのです。 またGRVTは、下限ミリ秒未満のレイテンシーと高いスループットを前提にインフラを構築しているとも述べています。市場がにぎやかになったときに、優雅な理論が崩れてしまうのは誰も望んでいないからです。 私の見解は?本当の物語は「ハイブリッド取引所」ではありません。スピードと信頼の役割を、よりすっきり分けただけです。それのほうがより誠実な設計で、正直言って、より面白い設計でもあります。 $TAC どの観点が一番重要だと思いますか?
#grvt @grvt_io $SKL
一部の取引所は「スピードか信頼か」を選ばせようとしているように感じます。その点は、ずっと少し気になっていました。

仮想通貨の現場で十分な時間を過ごしてきたので分かりますが、そのトレードオフはたいてい“きれいなUIの裏”に隠されています。片側では高速マッチング、別のところではカストディと決済。そしてその間には摩擦が大量にある。GRVTの公式ドキュメントは別の道を取っています。スピードのためにオフチェーンで注文をマッチしつつ、決済、カストディ、リスク管理は検証可能性とセルフカストディのためにオンチェーンに保つのです。

だから私はGRVTを「2つの時計を持つ市場」だと考え続けています。1つの時計は価格発見と執行のため。もう1つは証明、最終性、そしてコントロールのため。これらは同じ仕事ではなく、同一だとみなしてしまうと、ぎこちないプロダクトになりがちです。

私がいちばん“今っぽい”と感じるのは「1つの残高(one balance)」の発想です。GRVTのロードマップやプロダクトページには、分離したサイロの中で資本を遊ばせることなく、稼ぐ・取引する・投資することができる、単一のプログラマブル残高が記されています。これは市場が向かっている方向とも一致しています。人々は担保を、ただ待機させる以上のことに使いたいのです。

またGRVTは、下限ミリ秒未満のレイテンシーと高いスループットを前提にインフラを構築しているとも述べています。市場がにぎやかになったときに、優雅な理論が崩れてしまうのは誰も望んでいないからです。

私の見解は?本当の物語は「ハイブリッド取引所」ではありません。スピードと信頼の役割を、よりすっきり分けただけです。それのほうがより誠実な設計で、正直言って、より面白い設計でもあります。
$TAC
どの観点が一番重要だと思いますか?
Off-chain execution speed
100%
Onchain finality /selfcustody
0%
One-balance capital efficiency
0%
The mix of all three
0%
1 投票 • 投票は終了しました
確認済み
Newtonは認可をステーク担保型の真実マーケットに変えようとしているあなたも、あの法廷ドラマを見たことある? 聖書に誓って証言してるのを見て、「…いや、それ本当?」って思っちゃう感じ。📺 もし嘘だったらどうするの? だって当事者じゃないんでしょ? その考えが、ある夜にニュートンのアーキテクチャを掘り返していたとき、いつもと違って響いた。これは普通の「権限を確認します」系のプロトコルではないからだ。 たいていの人はニュートンを見ると——ポリシーエンジン、コンプライアンス層、EigenLayer上のAVSだと思う。もちろん技術的にはその通り。でも、実際に裏で起きていることを見落としてる気がする。 つまりこういうこと。

Newtonは認可をステーク担保型の真実マーケットに変えようとしている

あなたも、あの法廷ドラマを見たことある? 聖書に誓って証言してるのを見て、「…いや、それ本当?」って思っちゃう感じ。📺 もし嘘だったらどうするの? だって当事者じゃないんでしょ?
その考えが、ある夜にニュートンのアーキテクチャを掘り返していたとき、いつもと違って響いた。これは普通の「権限を確認します」系のプロトコルではないからだ。
たいていの人はニュートンを見ると——ポリシーエンジン、コンプライアンス層、EigenLayer上のAVSだと思う。もちろん技術的にはその通り。でも、実際に裏で起きていることを見落としてる気がする。
つまりこういうこと。
·
--
ブリッシュ
私は、橋が壊れた信頼モデルに対する単なる絆創膏にすぎないと気づいたあの日のことを決して忘れません。みんなトークンを動かすことに夢中で、本当の価値がその背後にある認可にあることを忘れています。🤯 ニュートンのアーキテクチャを公式に読み進めたことで、私の中で「橋」という発想は完全に消えました。クリプトを移すことが目的ではなく、承認の「スタンプ」を移すことが目的なんです。ニュートンは基本的に、イーサリアムを巨大な信頼キャッシュに変えます。私の理解ではこうです。各チェーンが高額でリスクもある自前のセキュリティガードを雇うのではなく、イーサリアムの本部から届いた、動的に更新されるIDカードを照会するだけです。 それらの送り先チェーンは自前のコンセンサスを動かしているわけではありません。同期されたオペレーター・テーブルに対して、BN254の証明書を検証しているだけです。これは大きいです。ブリッジのコードが完璧であるように祈る必要がなくなります。頼るのは、イーサリアムの経済的セキュリティのキャッシュされた状態だけです。 私にとって、これはマルチチェーンにおける「信じてくれ、bro」問題を丸ごと解決します。ニュートンが、実際の「作業」は他の場所どこでもできるようにしつつ、キャッシュされた信頼を同期する技術として一歩踏み出しているのを見るのはかっこいいですね。相互運用性の悪夢なしで済む。みなさんもドキュメントでそれに気づきましたか?👇 @NewtonProtocol #Newt $NEWT $TAC $SKL
私は、橋が壊れた信頼モデルに対する単なる絆創膏にすぎないと気づいたあの日のことを決して忘れません。みんなトークンを動かすことに夢中で、本当の価値がその背後にある認可にあることを忘れています。🤯

ニュートンのアーキテクチャを公式に読み進めたことで、私の中で「橋」という発想は完全に消えました。クリプトを移すことが目的ではなく、承認の「スタンプ」を移すことが目的なんです。ニュートンは基本的に、イーサリアムを巨大な信頼キャッシュに変えます。私の理解ではこうです。各チェーンが高額でリスクもある自前のセキュリティガードを雇うのではなく、イーサリアムの本部から届いた、動的に更新されるIDカードを照会するだけです。

それらの送り先チェーンは自前のコンセンサスを動かしているわけではありません。同期されたオペレーター・テーブルに対して、BN254の証明書を検証しているだけです。これは大きいです。ブリッジのコードが完璧であるように祈る必要がなくなります。頼るのは、イーサリアムの経済的セキュリティのキャッシュされた状態だけです。

私にとって、これはマルチチェーンにおける「信じてくれ、bro」問題を丸ごと解決します。ニュートンが、実際の「作業」は他の場所どこでもできるようにしつつ、キャッシュされた信頼を同期する技術として一歩踏み出しているのを見るのはかっこいいですね。相互運用性の悪夢なしで済む。みなさんもドキュメントでそれに気づきましたか?👇
@NewtonProtocol #Newt $NEWT $TAC $SKL
bn254
0%
bls
0%
evm cache
0%
0 投票 • 投票は終了しました
Newton Is Creating Replay-Resistant Privacy Domains数年前、私は、優れたセキュリティとはデータを閉じ込めておくことだと思っていました。 つまり?それは仕事の半分にすぎないと思います。 資金をウォレット間であちこち移し替えるのに夜を使いすぎ、かろうじて思い出せるような承認に署名し、何か見落としていないか確認するために取引履歴までチェックした結果、真の厄介さは必ずしもデータの露出そのものではないと気づきました。問題は、関係ないはずの場所にデータが現れることなんです。 だからこそ、ニュートンのプライバシー・アーキテクチャにある1つの細部が私の心に残りました。 このプロジェクトは、機密情報が送信される前にクライアント側で暗号化されることを文書化しています。これは確かにそのとおりで、十分に納得できます。ですが、私の注意を引いたのはもう少し見えにくい点でした。暗号化されたSecureEnvelopeが、Additional Authenticated Data(AAD)を通じて特定のpolicy_clientとchain_idに結び付けられていることです。

Newton Is Creating Replay-Resistant Privacy Domains

数年前、私は、優れたセキュリティとはデータを閉じ込めておくことだと思っていました。
つまり?それは仕事の半分にすぎないと思います。
資金をウォレット間であちこち移し替えるのに夜を使いすぎ、かろうじて思い出せるような承認に署名し、何か見落としていないか確認するために取引履歴までチェックした結果、真の厄介さは必ずしもデータの露出そのものではないと気づきました。問題は、関係ないはずの場所にデータが現れることなんです。
だからこそ、ニュートンのプライバシー・アーキテクチャにある1つの細部が私の心に残りました。
このプロジェクトは、機密情報が送信される前にクライアント側で暗号化されることを文書化しています。これは確かにそのとおりで、十分に納得できます。ですが、私の注意を引いたのはもう少し見えにくい点でした。暗号化されたSecureEnvelopeが、Additional Authenticated Data(AAD)を通じて特定のpolicy_clientとchain_idに結び付けられていることです。
オンチェーンのプライバシーとなると、「砂の上に建てているみたいだな」と感じたことありませんか?😅 以前、(文字通りではないけれど)痛い目を見ました。機微なデータが、本来そうあるべきでない形で使い回されているのを見てしまったんです。何かを暗号化して「これで安全だ」と思ったのに、同じ暗号文ペイロードが理屈の上では別の文脈にコピペされ得ると気づく。すると、あなたの「プライベート」なデータは、急にそれほどプライベートではなくなってしまいます。まるで、あなたが持つすべてのアカウントで使えるパスワードがあるようなもの。良くないですよね? だからこそ、ニュートンのアプローチに注目しました。彼らはHPKEでデータを暗号化して終わりではありません。AAD(追加認証データ)を使って、その暗号文を特定のポリシー文脈に結びつけているんです。つまり、あなたのアイデンティティ情報、オラクル入力、または制裁チェックは、隠されるだけでなく、特定のchain_idとpolicy_clientに「ロック」される。生の同じデータを、別の場所に気軽にリプレイ(再送)することはできません。 たとえば、ある国への入国スタンプが「その1回の入国」「その行き先」「その時刻」でしか有効でないようなものです。コピーして再利用することはできない。ニュートンが認可(authorization)レイヤーで機微な入力に対してやっているのは、まさにそれです。 自律エージェントがより多くのオンチェーン業務を扱うようになると、これはこれまで以上に重要です。もしエージェントのプライベートな入力が、文脈をまたいで持ち上げられて再利用できてしまうなら、深刻な問題になります。ニュートンは、それが起きないようにしています。派手ではないけれど、堅実。🛡️ @NewtonProtocol #Newt $NEWT $VANRY $LAB
オンチェーンのプライバシーとなると、「砂の上に建てているみたいだな」と感じたことありませんか?😅

以前、(文字通りではないけれど)痛い目を見ました。機微なデータが、本来そうあるべきでない形で使い回されているのを見てしまったんです。何かを暗号化して「これで安全だ」と思ったのに、同じ暗号文ペイロードが理屈の上では別の文脈にコピペされ得ると気づく。すると、あなたの「プライベート」なデータは、急にそれほどプライベートではなくなってしまいます。まるで、あなたが持つすべてのアカウントで使えるパスワードがあるようなもの。良くないですよね?

だからこそ、ニュートンのアプローチに注目しました。彼らはHPKEでデータを暗号化して終わりではありません。AAD(追加認証データ)を使って、その暗号文を特定のポリシー文脈に結びつけているんです。つまり、あなたのアイデンティティ情報、オラクル入力、または制裁チェックは、隠されるだけでなく、特定のchain_idとpolicy_clientに「ロック」される。生の同じデータを、別の場所に気軽にリプレイ(再送)することはできません。

たとえば、ある国への入国スタンプが「その1回の入国」「その行き先」「その時刻」でしか有効でないようなものです。コピーして再利用することはできない。ニュートンが認可(authorization)レイヤーで機微な入力に対してやっているのは、まさにそれです。

自律エージェントがより多くのオンチェーン業務を扱うようになると、これはこれまで以上に重要です。もしエージェントのプライベートな入力が、文脈をまたいで持ち上げられて再利用できてしまうなら、深刻な問題になります。ニュートンは、それが起きないようにしています。派手ではないけれど、堅実。🛡️
@NewtonProtocol #Newt $NEWT $VANRY $LAB
non fungile
100%
hkpe
0%
2 投票 • 投票は終了しました
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約