林木森Woody

#币安夏令营 冲呀

今週 @Dusk のトークノミクスを見直して、前は「上限10億・4年で半減」しか覚えていなかったのに、報酬配分に沿って調べたらブロック生成者は各ブロックで発行される“全額”を持っていかないことに気づきました。現在の最初のサイクルは計画どおり、1ブロックあたり約 19.8574 DUSK が発行され、そこに当該ブロックの取引手数料が加わります。ブロック生成者のベースは70%で、証明書にある credits によって最大さらに10%上乗せされ、開発基金が10%、検証委員会と承認委員会がそれぞれ5%です。配分されなかった分は焼却されます。

この設計が解こうとしているのは単一のAPRではなく、提案・検証・承認という3つのコンセンサス行為すべてに収入があるようにすることです。ただ、問題も変わります。もしオンチェーンの取引手数料が低いなら、安全予算は継続的な発行に大きく依存しますし、ノード参加の品質が不足していれば、追加報酬が満たされず、実際の新規供給が名目のカーブよりも低くなります。だから $DUSK を見るとき、「1ブロック 19.8574」をそのままブロック数に掛けて、誰もが受け取れる固定の払い出しだと考えるのは違います。

公式が提示している長期モデルは、最初の5億から始まり、約36年かけて残りの5億を発行して最大供給10億。4年ごとにブロック発行率を半減します。この上限は明確ですが、「上限がある」ことは短期的に希薄化がないことを意味しません。前半4年は、実は排出（エミッション）が最も集中する期間だからです。一方で、初期の排出がノードや委員会のための安全性を買うことにも確かに役立っており、「インフレ」だけで一筆に片付けるべきではないとも言えます。

私は #dusk の供給が同時に3つを見ていると思います。実際の鋳造、アクティブなストーキング（活発な質押）の比率、そして取引手数料が報酬に占める割合です。手数料と実際の使用が徐々に発行による安全予算を引き継いでいく一方で、半減が単にノードの収入を切るだけにならないようにするわけです。あなたたちは最大供給を固定で書き切ることをより重視していますか、それとも、排出が下がった後でもネットワークが安全コストを払い続けられるかの方を重視していますか？

我把 @Dusk 、NPEX 和 Chainlink 的合作公告拆开看，发现真正要落地的不是一句“RWA 跨链”，而是三种完全不同的数据和资产通道。CCIP 负责链间消息与资产移动，CCT 给 $DUSK 这类代币提供受控的 burn/mint 路径；DataLink 把 NPEX 的公式取引所データ送上链，Data Streams 再处理更低延迟的価格更新。

なぜこの層のデータは「債券を token に鋳造する」よりも厄介なのか？規制対象の資産は、単にあるコントラクト内に一連の持分があることを示すだけでは足りない。二次市場は価格がどこから来ているのか、発行体が依然として支配権を持っているのか、クロスチェーン時のスループット制限やアップグレード権限が誰のものか、異常データが出た場合にどう停止するのかを知る必要がある。発表では Dusk と NPEX がトークン・コントラクトの所有権を保持し、rate limit や upgrade path を設定できると強調されている。これは機関にとってのコントロール能力であり、一般ユーザーにとっても注視すべきガバナンス権限だ。

前向きに見ると、NPEX は実在の発行・取引のシーンを提供し、Chainlink は相互運用性と公式の時価データの入口を補い、Dusk こそが発行、取引、決済、開示を一本のチェーンにつなげられるチャンスがある。逆に、はっきりしている点もある：提携、標準の採用、そして資産が本当に活発であることは、三つの別の事柄だ。検証可能な発行数量、約定、保有者、償還の記録がなければ、「機関が大規模にオンチェーンにする」という話は、まだ開発段階にすぎない。

だから私は次に #dusk を追う。partner logo だけを数えたりはせず、三種類の証拠を待つ：本物の資産コントラクト、連続する市場データ、検証可能な決済フロー。あなたたちは、RWA でいちばん難しいのは資産のクロスチェーンだと思う？それとも、オンチェーンの価格と法的権利、そしてオフチェーンでの償還（現物払い）が常にきちんと一致するように保つことのほうが難しいと思う？

ここ数日で @Dusk の Core Components を描き直して、DuskVM、DuskEVM、DuskDS という 3 つの名前をようやく分けられました。最初は「1つのチェーンで2種類の仮想マシンに対応しているだけ」だと思っていましたが、実際の分担はもっと三層に近いです。DuskDS がコンセンサス、最終性、データの可用性を担当し、DuskVM は Rust/WASM のコントラクトを L1 上でそのまま動かします。DuskEVM は OP Stack に基づく EVM と同等の実行環境で、決済とデータの公開は DuskDS に任せます。

つまり、開発者は無条件に二択を迫られるわけではありません。既存の Solidity コントラクトがあり、EVM ウォレットやツールチェーンに依存しているなら、DuskEVM を選ぶほうがコストが低く済みます。一方で L1 資産に直接触れることや、Phoenix のプライバシーモデル、ゼロ知識の能力、あるいはより低レイヤのプロトコル制御が必要なら、DuskVM がネイティブな入口です。2 つのルートは決済の基盤を共有していますが、機能やセキュリティの前提が完全に同じというわけではありません。

私は「EVM compatible＝エコシステムが自動的に丸ごと移ってくる」という主張にやや警戒的です。互換性はデプロイのハードルを下げるだけで、ウォレット接続、安定した RPC、インデクサ、流動性、そして実際のユーザーを置き換えることはできません。逆に、ネイティブな Rust/ZK だけを強調しても十分ではありません。ツールが硬すぎて、開発者は技術的な純度のためにプロダクト全体を書き換えようとはしないでしょう。

だから私は $DUSK の技術進展を、指標を分解して見ています。DuskEVM にサードパーティの Solidity アプリはあるのか、DuskVM に非公式のコントラクトはあるのか。両者が DuskDS へ決済する経路は安定しているのか。#dusk の堀が成立しているなら、それは「使い慣れたツールで入ってこられ、プライバシーが必要なときには下へ進める」ということであって、3 つの新しい名前を同時に積み上げる話ではないはずです。あなたたちはまず互換性を選びますか、それともネイティブ能力を選びますか？

以前我看到 @Dusk は、Moonlight と Phoenix を同時に扱っていて、「普通の送金」と「プライバシー送金」でそれぞれ機能が重複しているだけなのでは、と感じていました。ところが、取引モデルのドキュメントと取引所の接続手順を一緒に読むと、二つのモデルが“ただの見せ技”ではなく、同じ決済レイヤーの中で主に次のことを能動的に認めていることが分かります。つまり、公開されるべき資金の流れもあれば、すべての人に金額や関係性を晒すべきではない流れもある、ということです。

Moonlight は公開アカウントモデルで、残高・送信者・受信者・金額がすべて見えます。取引所の入金（チャージ）、国庫（トレジャリー）、そして公開の照合が必要なシーンで扱いやすいです。一方 Phoenix は、資金を暗号化された note に入れ、ゼロ知識証明でダブルスペンドがなく資金が足りていることを確認しつつ、傍観者には具体的な金額や対応する note を公開しません。監査が必要なときは、viewing key によって選択的に開示します。

ここでの最大の誤解は、「プライバシーがあるから、ブラウザでは何も見えない」というものです。公式のブラウザでもブロック、取引タイプ、手数料、gas などの公開メタデータは依然として見えます。どこまで見えるかは、取引モデルやコントラクトによって変わります。逆に、取引所が Phoenix を Moonlight のようにそのままスキャン／回収できるわけでもありません。公式の統合ドキュメントでは、入金（チャージ）は Moonlight を使うよう明確に推奨されています。プライバシー残高は、先に公開アカウントへ転送してからでないといけません。保管（トラッキング）やスキャンのロジックは完全に別物です。

したがって $DUSK の難しさは、「プライバシーを証明できるか」ではなく、ユーザーが公開とプライバシーの間で切り替えるときに、間違った経路を辿らないようにすることです。#dusk が本当に規制下の資金フローに入るなら、デフォルトはプライバシーで、必要なときに開示でき、かつ予測可能な托管（トラッキング／保管）も同時に成立していなければなりません。皆さんがより懸念しているのは、全透明によるポジションの漏えいですか？それとも、二つのモデルによってプロダクトの複雑さを上げすぎてしまう点ですか？

私は @TermMax の TMX ホワイトペーパーとインセンティブ資料を一緒に読んでみて、「エアドロップはどれくらいあるのか」より先に聞くべき、もっと重要な問いを見つけました。すなわち、ロードマップに書かれた時期は、そのまま“すでに起きた TGE”として扱えるのか？

答えは、少なくとも現時点で公開されている書類だけでは、イコールで結べません。

2026年3月版のホワイトペーパーでは、TMX はガバナンスおよび実用トークンとして定義され、総供給量は固定で10億。初期の流通見込みは約20%です。配分表には、生態系29%、投資家28%、チーム15%、コミュニティ15%、残りは流動性、基金会、アドバイザーに割り当てると書かれています。ロードマップでは、TGE、取引所の流動性、配分、そしてステーキングプールが 2026年の第2四半期に置かれています。

しかし、同じホワイトペーパーのパラメータ欄では、TGEの日付は依然として「To Be Announced」となっています。プリマイニング資料は、ユーザーが積み上げているのは譲渡不可の上限であり、TGE後に1:1で請求できる、としか述べていません。公式はイーサリアムおよび BNB Chain のトークンアドレスを提示しており、コントラクト準備が公開されていることは示していますが、生成、請求、流通の“すべて”が完了していることを単独では証明できません。

この違いはとても重要です。コントラクトのデプロイは技術イベントで、TGEは配分イベント、取引所の入出金開始と取引はマーケットイベントです。3つは連続して起きることもあれば、かなり間が空くこともあります。「アドレスが存在する」「ロードマップの期限が来た」「ページに数字がある」を一つの文章にまとめて「すでに上場済み」としてしまうと、情報が歪みます。

私はTMXの進捗を、次の4つのシグナルだけで判断します。明確なTGEの日時。正式な請求ページとルール。ブロックエクスプローラー上で配分の説明に合致する流通。取引所自身の上場および入出金に関する告知。どれか一つでも欠けていれば、実際の段階に合わせて記述すべきで、プロジェクトのために後続ステップまで補完してはいけません。

リスクポイントは日付だけではありません。ホワイトペーパーには、チームが12か月のクリフの後に直線的にリリースされることが明記されています。投資家についても同様に12か月のクリフがあり、その後24か月でベスティングされます。市場に実際に影響するのは10億という総数ではなく、各ウィンドウでどれだけ放出されるか、どのアドレスが受け手になるのか、そして公開テーブルと突き合わせられるかどうかです。

だから私は、ロードマップの四半期がすでに過ぎたからといって、#TermMax の TMX を「当然完了した」とは見なしません。ロードマップは計画であり、オンチェーンの配分と公式告知こそが現状です。たった1日分の進捗を推測するより、想像上のバリュエーションを“多めに数える”ほうが役に立つ可能性が高い、というわけです。

私は @Dusk の新しいウォレットと Dusk Connect の説明を照らし合わせて初めてわかりました。追加されたのは「もう一つウォレットのスキンを作ること」ではなく、dApp がずっと欠いていた接続レイヤーだということです。旧 Web Wallet は単独で送金やステーキングはできるものの、アプリ側が統一インターフェースでウォレットを発見し、アカウントを要求し、署名を取り、取引を生成することができません。そのため開発者は、特定のウォレットごとに個別対応を回していくしかありません。

Dusk Connect がやっていることは、この「接着剤」を標準化するのにとても似ています。ウォレットの発見は EIP-6963 の発想を借り、RPC は名前空間でアカウント、署名、取引、ネットワーク要求を扱い、ウォレット実装者のために整合性テストまで用意しています。新しい第一方ウォレットは最初からこの provider インターフェースに沿って作られ、ブラウザ拡張、デスクトップ、モバイルをカバーします。公開・プライベート送金、shield/unshield、ステーキング、報酬の受け取り、DRC-20 と DRC-721 もすべて同じインタラクション経路にまとめられています。

宣伝文が最も人を迷わせやすいのは、「リポジトリ公開」をそのまま「プロダクト成熟」と同一視してしまう点です。公式が現時点で与えている位置づけは、まだ developer preview のままです。秘密鍵のローカル保存、拡張端は PBKDF2 と AES-GCM、ネイティブ端は Stronghold と Argon2――これらは正しい安全性の土台ですが、体験を本当に左右するのは、切断からの復旧、権限の提示、失敗したトランザクションのフィードバック、そして複数端末での状態整合性です。

そしてこれが、私が最近 #dusk を見ているときに、単にプロトコルの用語だけに注目していない理由です。安定したウォレット接続レイヤーがない限り、いくら見栄えのするプライバシー・スマートコントラクトでも、それは開発者デモにすぎません。$DUSK に必要なのは、さらに一枚UIのスクリーンショットを増やすことではなく、サードパーティの dApp が本当に手間なく接続できることです。新しいウォレットが使えるかどうかを判断するとき、あなたたちはまず機能一覧を見るのでしょうか、それとも失敗シナリオでどう振る舞うかを先に見るのでしょうか？

この数日で @Dusk の AEGIS セキュリティ分析を読んだが、最初は「39件の修正、7件のcritical」だけを覚えていた。細部を見て初めて、数字が大きいこと自体は本質ではないと気づいた。最後に7つの重大な問題は、4つの根本原因へ収束した。VMサンドボックス内のエイリアス問題、ホスト側の不安全な逆シリアル化、Phoenixの手数料と払い戻しが完全に紐づいていないこと、そしてBLS署名の偽造パスだ。

なぜ根本原因を見るのか？「脆弱性の件数」だけではだめだから。たとえば同じ信頼境界がうまく設計されていないと、別々のモジュールで問題が繰り返し“芽を出す”。入力の検証が行われる前に逆シリアル化をしてしまうケースは、表面的には1回のパース（解釈）エラーに見えても、実際にはホストのメモリ安全性に触れている可能性がある。Phoenix側の一連の問題も「手数料の計算を少し間違えた」類ではなく、証明・署名・払い戻しの実行が同じ語義（セマンティクス）で語られていないことが問題で、最悪の場合、供給の完全性や資金の安全性に直結しうる。

公式には、現時点でこれらのcriticalが修正前に悪用された形跡は見つかっていないと言われている。私はそれを調査結果として受け止めるが、「絶対に起きていない」とはしない。$DUSK にとってのAEGISのポジティブなシグナルは、チームが内部で見つけたことを根本原因と修正ロジックまで含めて公開した点だ。ネガティブなシグナルも同様に明確で、メインネット投入後のコアスタックには、実行・コンセンサス認証・チェーンの利用可能性に影響し得る重大なギャップが実際に存在したことがある。

だから私は「監査が多い」というだけで #dusk に対して安全の“お墨付き”を直接出さない。より有用な観察は次のとおりだ。次のラウンドで継続して開示があるか、同種の境界について回帰テストが行われるか、外部監査がAEGIS後のコードまでカバーできるか。あなたたちは、プロジェクトがこれまで大問題を出してこなかった点をより重視するのか、それとも出した後に、根本原因・影響・修正までの連鎖をきちんと説明できるかを重視するのか？
$USELESS $BOME

私は @TermMax の固定金利ドキュメントを改めて読み返したのですが、最初につまずいたのは「金利の計算方法」ではなく、もっと根本的な問題でした。オンチェーンの貸借の資金コストは毎日変わっているのに、なぜ債務の金利を満期日に先回りして固定できるのか？

もし答えが「契約で約束されているから変わらない」というだけなら、この固定金利には研究する余地はありません。さらに先を読み、FT、XT、GT の関係を見ると、論理が初めてつながります。

FT は、額面で満期に交換できる債務資産の証明書です。貸し手はディスカウントで FT を買い、満期には額面で償還（リデンプション）されます。差額が、先にロックされたリターンです。XT はその補完部分です。ドキュメントで示されている関係は、任意の時点で 1 FT と 1 XT が 1 口の債務資産に対応するというもの。
借り手は将来返済する金額を FT にし、利息部分は注文に売却します。そうすることで今日流動性を受け取れ、コストも取引が成立した時点で確定します。

GT は、より「ポジションの外装」のような存在です。これは ERC-721 で、担保と債務を記録しますが、自由に流通できる「利回りコイン」を新たに作り直すわけではありません。レバレッジ・ポジションがどれだけ担保を必要とし、FT をいくら抱え、いつ満期になるのか——それらはすべて同じオンチェーンの位置（ポジション）にひとまとめにされます。

直感的に言い換えると、通常の変動金利プールは、借りた後も債務の価格を更新し続けます。TermMax は逆に、「満期にいくら返すか」をまず取引可能な債権にしてから、市場が今日いくらならそれを買うのかを決めさせます。固定されるのは、資産価格でも担保が永遠に安全だということでもなく、取引後にこの債務の時間とコストが確定する点です。

そして、宣伝文句に隠れがちな境界もあります。固定金利は「清算されない」ことと同義ではありません。公式の Market ドキュメントでも MLTV と LLTV を引き続き設定しています。担保価格の下落や債務資産の増価によって LTV が LLTV に到達すれば、ポジションは同様に清算へ移行します。ここで取り除かれるのは「金利が急に跳ね上がる」という不確実性であって、担保の価格変動、オラクル、満期での返済リスクは取り除かれていません。

だから私は今 #TermMax を見るとき、APY が高いかどうかを先に問わず、まず FT の満期日、約定の厚み（ディープさ）、そして GT が清算ラインからどれだけ離れているかを見ます。「固定金利」＝「問題が起きない」と理解してしまうと方向性がずれます。固定されるのは、債務の中で最も予算化しづらい部分の価格だけです。
$CLO $ETH

私は @Dusk を今年の「クロスチェーン・ブリッジ再検証」としてもう一度通して見直しました。いちばん注目すべきなのは「盗まれた」という2文字ではなく、障害が“どの層”で起きたのかです。1月16日に問題が起きたのは、ブリッジサービスが使う署名ウォレットでした。攻撃者は貸出権限を手に入れると、Dusk側から資産を移し、その一部をBSCへ送ったのです。公式には、これは合意の無効化（共識失効）ではなく、L1プロトコルが突き破られた（打ち穿）わけでもないとはっきり言われています。

しかし、だからといって基盤のチェーン自体が無事だという意味ではありません。ユーザーがブリッジのリスクを無視していい、ということにはなりません。旧アーキテクチャでは、イベントの受信、署名、そして資金の解放が一つの経路に押し込まれていました。速いのは速いのですが、署名側が破られると権限の集中が強すぎるのです。後からの作り直しでは、この3つを分離しました。イベントはまずタスクとして記録し、workerがステートマシンに従って処理します。署名済みの元トランザクションは先に保存し、失敗した場合は同じ1件をリプレイします。ホットウォレットには直近に必要な残高だけを残し、しきい値を下回れば停止。コールドウォレットは人手で補充します。

以前の私も、「ブリッジはプロトコルではない」という免責句をつい言い訳として受け取りがちでした。でも今は逆にこう捉えるほうが納得できます。ユーザーがそれを流動性の入口として扱う時点で、ブリッジはすでに $DUSK の“現実の安全境界”に入っています。オンチェーンの合意安全と、資産の出入口の安全——この2つは、どちらも同時に合格しなければならない試験用紙なんです。

今回の是正方針は正しいし、リスクが消えたわけでもありません。鍵の分離が長期的に実行されるのか、しきい値は妥当か、停止や補款が監査可能（ア审査可能）か、これらは引き続き見張る必要があります。#dusk のコミュニティが本来もっと問うべきなのは「チェーンがハッキングされたかどうか」ではなく、「必要以上の権限をまだ持っている“どの鍵”なのか」です。皆さん、クロスチェーン・ブリッジを見るとき、まずコード監査ですか？それとも運用上の権限がどう切り分けられているかから見ますか？
$TREE $ETH

あまりセクシーではないけれど、実際にネットワークが長期で回り続けられるかを決めるもの——$DUSK の発行とステーキングについて。@Dusk の最新ドキュメントを読んで、議論の多くが「最大供給量10億」にばかり目を向けていて、その10億が一度に市場へ入ってくるわけではないことを見落としていると感じました。

Dusk のモデルは、まず初期供給5億を用意し、残りの5億は36年かけてネットワーク報酬として放出します。放出は4年ごとに半減する幾何学的なペースで減衰していきます。トークンの用途は現時点でかなり明確です。Gas の支払い、ステーキングへの参加、そしてコンセンサスの保護です。Provisioner として直接なるには最低でも 1000 DUSK をステークし、さらにノードが継続してオンラインで同期している必要があります。公式が示す基礎構成は過大ではありませんが、報酬はコンセンサス参加や有効ステーク確率によって生み出されるもので、「預ければ固定で利息が入る」わけではありません。

この設計が合理的なのは、ネットワークの利用とセキュリティ予算を結びつけている点です。ブロック報酬は新規発行と取引手数料から構成されます。初期は放出による補助でノードを支え、後期は実際の手数料への依存度が高まります。エコシステムでの呼び出しが伸びれば、セキュリティ予算は「新しいコインを発行する」から「ユーザーがサービスに対して支払う」へ段階的に移行し、ようやくロジックが閉じます。

ただしリスクもはっきりしています。36年の放出ということは、長期的な希薄化を総量のスローガンだけで見てはいけません。最低1000枚に加えて運用要件があるため、直接ステークすることが一部の小口保有者にとっては障壁になります。さらに報酬は確率的なので、安定した年率リターンと誤解されやすい。

そして最も重要なのは、オンチェーン取引やアプリの収益が伸びない場合、手数料が代わりを担えないため、ネットワークのセキュリティは最終的に依然として主に発行の補助に頼ることになる点です。

だから私は #dusk を観察していて、ステーキング比率が高いかどうかだけを見ているのではなく、3つの指標を一緒に見ているはずだと考えています。活発な Provisioner が分散しているか、報酬に占める実取引手数料の割合、そしてノードのアップグレード後も安定してオンラインでいられるか。ロック量だけ見て綺麗に見えても、使われておらず、流動性を隠しているだけだと、それは需要を証明しているわけではありません。

あなたは、新しいネットワークの初期段階で優先してステーキング参加率を上げるべきだと思いますか？それとも先に実際の手数料を作るべきだと思いますか？あなたの並び順を教えてください。
$ETH $RED

我重新看了一遍 @Dusk 的主网迁移指南，有个很容易被忽略的细节：ウォレット内でApproveを押したからといって、$DUSK がすでにDuskメインネットへ移行されたことを意味しません。実際に移行をトリガーするのは、後半のExecute transactionです。2ステップの間でどこかで中断が起きると、ユーザーは資産が「止まっている」と誤解する可能性があります。

公式手順は、イーサリアム上のERC-20、またはBNB Chain上のBEP-20のDUSKを移行コントラクトにロックし、その後、指定されたDuskメインネットのアカウントへ対応するネイティブコインを付与することです。ユーザーは、自己管理のEVMウォレット、Duskアカウント、そして元チェーン側の手数料を支払うためのETHまたはBNBを用意する必要があります。取引を確認した後、通常さらに処理待ちが発生します。取引所のアカウントは、WalletConnectで直接この一連の操作を完結させることができないため、自分で管理するウォレットを先に用意して紐づける必要があります。

仕組み自体は難しくありませんが、落とし穴は操作の境界にあります。第一に、承認（授权）は契約に対して上限額を付与するだけで、自動的にコインが移動されるわけではありません。第二に、元チェーンのトークンは小数点18桁、メインネットのDUSKは小数点9桁であり、移行額は最小単位LUXへ向けて切り捨てられます。1 LUX未満の端数は、元のウォレットに残ります。第三に、残高が反映されない場合は、同じ承認を繰り返す前に、Execute取引が成功しているかをまず確認すべきです。

この「片方向にロックしてから付与する」設計は、ユーザーが自分でブリッジプールを探すよりも分かりやすい一方で、2つのチェーン、2つのウォレット、2回の確認を同じフローに詰め込んでいます。既存ユーザーには単に一度見直すだけで済みますが、新規ユーザーにとっては「承認が成功した＝移行が完了した」と誤って理解してしまう可能性があります。安全メカニズムが画面上で十分に説明されない限り、最終的には人為的ミスになってしまいます。

だから私は #dusk の主网迁移を見るとき、コントラクトに監査があるかどうかだけでなく、ウォレットが現在のステップ、元チェーンのハッシュ、見込みの処理状態、受信アドレスを同時に表示できているかも見ています。公式ドキュメントには検証の手順が明確に示されていて、これは大きな加点項目です。次の一歩として、こうした注意事項を各重要ボタンに組み込むべきで、ユーザーが失敗した後にヘルプセンターを開かせるのは避けるべきです。

あなたが資産を移行するとき、最も怖いのはどの段階ですか？ 承認、ネットワークの選び間違い、それとも着金状況が不透明なこと？あなたが踏んだ操作上の落とし穴を教えてください。$ACE $BTC

完全对照 @Dusk の開発ドキュメントを読んだあとで、いま最も注目すべきなのは、特定のTPSのスローガンというより、開発入口をDuskVMとDuskEVMの2つの環境に分けたことだと気づきました。これは同じことの繰り返しで輪を作っているようにも見えますが、実際には「ネイティブなプライバシー機能」と「既存の開発エコシステム」を同時に一歩で解決できない問題に対処しているのです。

DuskVMはRust/WASMのコントラクトをL1上で直接実行し、Phoenixが取引やゼロ知識機能、ネイティブ資産モデルを隠蔽する仕組みにより近いです。一方、DuskEVMはOP Stackをベースにしており、開発者は引き続きSolidity、Hardhat、Foundry、そして馴染みのあるウォレットツールを使えます。実行結果はDuskDSを通じて決済とデータ可用性へ反映されます。つまり、前者は専門の研究室のように能力は深いが学習のハードルが高く、後者は標準的なインターフェースのように導入が速いものの、レイヤー間の協調を扱う必要があります。

このルートは確かに現実的です。多くのプライバシーチェーン技術は重厚に作られがちで、最終的に「誰も開発しない」ところで詰まってしまいます。普通のEVMチェーンのツールは揃っていても、規制対象資産をネイティブに扱うための秘匿性や選択的開示を、同時にうまく実装するのは難しい。一方でDuskは、両方のタイプの開発者を残すことで、「技術的には正しいのに、エコシステムが空白」という旧来の問題を少なくとも回避しています。

ただし、二つの環境はタダでもらえる“恩恵”ではありません。コントラクトをどの層に置くか、資産をどのようにレイヤー間で渡すか、障害時にどの層が責任を負うか――これらはすべてエンジニアリングの複雑さを増やします。特にDuskEVMはDuskDSの決済とデータ可用性に依存します。ユーザーから見えるのは馴染みのあるEVMの画面ですが、その下は通常のイーサリアムのサイドチェーンとは違います。ドキュメント、ブラウザ、レイヤー間ステータスの表示が追いついていないと、互換性はむしろ新たな理解コストを生みかねません。

私は今、「Solidityに対応している」というだけで #dusk の開発者の成長に結論を出すつもりはありません。次に注視すべきなのは、メインネットで実際に稼働しているコントラクト数、レイヤー間資産のパスがスムーズかどうか、そしてHedgerのような秘匿能力がいつ再利用可能なコンポーネントとして形になるのかです。$DUSK は2つの環境の中でのGasと安全資産としての価値を持ちますが、その最終的な価値はアーキテクチャ図による自己完結ではなく、実際の呼び出し量によって証明されるはずです。

あなたは、双方向の実行環境を賢い役割分担だと思いますか？それとも、メンテナンスの難易度を拡大させているだけだと思いますか？判断をぜひコメントしてください。
$BTW $ETH

私は今年3月に行われた @Dusk のブリッジ復習を改めて読み直した。最も記憶すべきなのは「メインネットのコンセンサスに問題はなかった」ということではなく、さらに痛い別の事実だ。――1つの署名ウォレットの権限が、かつてはブリッジ全体を一緒に沈めるほど大きかった。

1月16日、攻撃者はブリッジサービスのDusk署名ウォレット権限を入手し、まずDusk側で資金を転がした後、その一部をBSCへ送った。公式が開示したシーケンスには、盗まれた $DUSK の枚数として 9,000、89,700、2,743,310、8,068,000 が挙がっている。さらに、2件はブリッジを通過できたが、最後の1件（8,910,000枚）は停止後に試みが失敗した。

これはDuskDSのコンセンサスが突き崩されたわけでもなければ、Phoenixの暗号学がその場で無効になったわけでもない。問題はブリッジの運用パスにある。――署名、イベント処理、ネットワーク接続が同じラインに押し込まれていたのだ。銀行の金庫そのものがこじ開けられたわけではない。だが護送車の運転手が金庫の鍵、ルート表、放出のスタンプまで同時に握っていて、運転手が証憑を1つ落とせば、金庫が分厚くても車は間違った方向へ進んでしまう。

復習を踏まえた改造は確かに的を射ている。署名とイベント処理を分離し、イベントはまずタスクとして着地させ、独立したworkerが実行する。さらに取引の状態を seen、submitted、completed、failed、stuck に分割した。ホットウォレットは最低限の運用残高だけを残し、閾値を下回れば自動停止、あとはコールドウォレットを人手で補充する。要するに「1本の道を通し切る」構造を、いくつかのゲートに切り分けたのだ。

ただし、改修が終わったからといって歴史を読み替えるつもりはない。ブリッジで一番厄介なのは、プロトコルの安全性と運用の安全性が、ユーザーにとっては同じひとまとめとして理解されがちな点だ。同じDUSKを握っていても、見えているブランドは同じでも、引き受けている信頼モデルがまったく別物である可能性がある。チェーン内はコンセンサスに依存し、クロスチェーンの一手は当時は署名パスに依存していた。資産が境界を越えた瞬間、安全性の前提は車ごと置き換わってしまう。

私の判断はこうだ。公開されたタイムラインと根本原因は、「復旧済み」といった曖昧な一文よりはるかに価値がある。しかし、透明な復習は“再計算”のスタート地点にはなるとしても、免責の検査印ではない。#dusk の後続で本当に有用な観察項目は、ブリッジのホットウォレット露出、停止メカニズム、署名の隔離、そして異常処理が、設計どおりに長期運用できているかどうかだ。

だから「Duskは安全か？」という大きく空虚な問いはもうやめよう。聞くべきはこうだ。――あなたが今持っている資産は、どの層にあり、誰が署名し、どのゲートが破られるとお金に影響するのか？ ブリッジはより複雑に修理されている。信頼も本当に細切れになったのか？ コメント欄で続けて。$BTC

私は@Dusk のトークン経済のページをめくっていて、本当に足を止めたのは「10億枚の上限」ではなく、ひっそりした次のルールだった。ノードの最低質押は1,000枚$DUSK だが、最高額は上限なし。

まずは帳尻を合わせる。Duskの初期供給は5億で、計画では36年かけてさらに5億を放出する。最初の4年間は、1ブロックあたり約19.8574枚が追加され、その後はおおむね4年ごとに半減していく。ブロック報酬では、ブロックを作った者が70%を受け取り、さらに証明書にあるcreditsに応じて最大10%上乗せできる。開発基金10%、検証委員会5%、承認委員会5%、そして配分されなかった分は焼却される。

この配分は、会社がボーナスをフロントの営業、リスク管理の再確認、そして本部の予算に分けているようだ。メリットは、各役割がちゃんと報酬を得られること。検証や承認が“情熱だけ”に頼らなくなる。より重要なのは、手数料もブロック報酬に組み込まれている点で、理屈の上ではチェーン上の利用が増えるほど、安全予算が増発だけに依存しなくて済む。

しかし「質押上限なし」という5文字こそが本丸だ。コンセンサスでは、provisionerがランダムに選ばれて提案・検証・承認を行い、その報酬は有効質押と参加度合いに連動する。大口の資金が厚いほど、選ばれる経済的期待値が高くなり、報酬がまた質押に戻って、雪球がさらにしっかり転がっていく可能性がある。ルールが明示的に大口の独占を意図しているわけではないのに、複利が代わりにルールの汚れ仕事を引き受けてしまう。

もちろんDuskには、ソフトな罰とハードな罰がある。オフラインになると停止される可能性があり、さらに一部の有効質押がロック質押に振り替えられる。無効な投票や、二重署名などの立証可能な悪意行為は、場合によっては直接、元本の一部を焼き切ることがある。これは巨大な鯨の金庫に自爆ボタンを付けたようなものだ。ボタンは悪事を抑えることはできるが、権限の集中を自動的に解決はしてくれない。

私の見方はかなりねじれている。36年で減衰する発行は、長期の安全予算をかなり明確に書いていて、思いつきでインフレ調整するよりは筋がいい。とはいえ、その安全予算を誰に配るのかは、総量のカーブよりもずっと注視する価値がある。#dusk が見るべきなのは「10億の上限」という大きな見出しではなく、活発な質押の集中度、ノードのオンライン率、そして報酬が継続的に上位へ回帰しているかどうかだ。

供給上限をそのまま“希少性”に翻訳しないで。質押の収益もそのまま“安全”に翻訳しないで。上限なしのノードのウェイトは、長期投資への報酬なのか、それとも徐々にランダムな委員会が金持ちの常連席になっていくのか。広場で事情をはっきりさせよう。
$VELVET $SNXXB

私は @Dusk の取引モデル文書を2回読みましたが、最も目を引いたのは「プライバシー」という2文字ではなく、同じチェーン上に2種類の台帳が並んでいる点です。Moonlightは公開、Phoenixは秘匿。

平たく言うと、Moonlightはガラス張りのカウンターで、アドレスや送金が見えてしまいます。一方Phoenixは、資金を暗号化されたチケットに詰め、ゼロ知識証明でネットワークに「このお金は合法で二重支払いではない」と伝えるものの、送信者・受信者・金額をすべては開示しません。さらに、1つのアカウント像で、この2種類のアカウントを同時に扱える。まるでお金を透明カードと暗証カードに包んで、支払い時に自分でどちらを渡すか選べるような感じです。

この設計は確かに賢いです。金融機関はすべてのデータを公開できるわけでもなく、監督当局が何も見えない状態を受け入れることもありません。Duskは取引モデルの中に「選択権」を入れました。通常の決済は明細台帳、センシティブな持ち高はプライバシー台帳。監査が必要になったときに閲覧鍵で、選択的開示を行う。プライバシーとコンプライアンスを正面から喧嘩させるのではなく、同じ食卓で別々に食べてもらうわけです。

ただ問題も「二重レール」の中に隠れています。取引所の統合ドキュメントでは、入金はMoonlightを使うよう明確に推奨されています。Phoenixの暗号化チケットには、別の保管およびスキャンのロジックが必要だからです。つまり、プロトコルはプライバシーへの出口を用意したのに、現実の入口は互換性のために全員を透明な通路へ追い返してしまう可能性がある。ホテルが隠しのVIP出入口を作っても、フロントのシステムが正門の身分証しか認めないようなものです。入口は存在しても、客が本当にそこを通れるとは限りません。

では $DUSK はここで何をしているのか？ 2種類の送金はいずれもそれで支払い、さらにコントラクトの実行にもそれが欠かせません。単にプライバシーの物語に貼り付けられた記号ではなく、2つの台帳が共通で使う燃料です。この燃料に需要があるかどうかは、最終的にウォレット、取引所、そしてアプリがPhoenixを本当に引き出してくれるか、ドキュメントにきれいに書かれているだけかで決まります。

私の現時点の判断はこうです。二重モデルは「一律にすべて公開」より現実の金融に近い。ただし複雑性は、チェーン上から“接続側”へ移されている。#dusk が本当に見張るべきなのは、プライバシー機能があるかどうかではなく、追加のスキャン・保管・開示コストを引き受ける入口がどれだけあるかです。

だから「選べるプライバシー」という4文字にだけ、気持ちよく騙されないでください。MoonlightとPhoenixという二車線は、最後にユーザーへ自由なルート選択をもたらすのか、それとも多くの入口が最も手間の少ない透明車線だけを開放するのか。コメント欄で掘り下げていきましょう。
$AKE $ACU

私は @BabylonLabs_io 自身が公開したSCRIPTリスクフレームワークを、TBVテストネットのパラメータと照らし合わせて一通り確認した。いちばん興味深いのは、一方では「担保資産のライフサイクルは無許可であるべき」と書かれているのに、もう一方では 3/5 の Security Council による緊急しきい値が明確に列挙されていることだ。

これは必ずしも矛盾とは限らない。だが、「trustless」の含有量を測るうえで、その境目をちょうど試すポイントではある。

SCRIPT が求めるのは6つのことだ。ユーザーの主権保持、処分ルールの明確化、同意なしの再担保禁止、各ポジションの分離、第三者による審査不可、担保状態の透明性。まるで金庫の受入検査項目を6つ並べるようなものだ。鍵は誰のものか、開錠条件は何か、二重担保に回せるのか、箱は混在していないか、誰が止められるのか、外から残高を確認できるのか。

TBV は分離と透明性についての考え方が非常に明確だ。各ユーザーの BTC は独立した Bitcoin Vault に保持され、外部アプリはその状態を検証し、すべてのコインをひとつのカストディプールに混ぜない。だが、現在公開されているテストネットのパラメータには、Security Council は5席で構成され、3つの署名で CouncilNoPayout のような緊急介入を実行できるとも書かれている。

ここでは境界を明確にしなければならない。3/5 は公開テストネットのパラメータであり、将来のメインネットでもそのまま採用されると直ちに推断することはできない。むしろ、メインネットの答えがまだこのページのパラメータからは確定しないからこそ、委員会の存続・廃止や権限変更を長期的な観察項目として扱うべきであり、プロジェクトの代わりに結論を補ってやるべきではない。

私は、テスト期に緊急ブレーキがあることには現実的価値があると考える。新しいシステムは Bitcoin スクリプト、オフチェーンの調整、Ethereum コントラクトにまたがるため、重大な障害を発見したときに損失を止めるボタンがまったくないよりは、ボタンがあるほうが必ずしも危険とは言えない。問題は、そのボタンが存在する以上、次の問いをさらに追及しなければならないことだ。メンバーは誰か、どんな条件で押せるのか、操作は遅延付きで公開されるのか、ユーザーには委員会に依存しない退出経路があるのか。

これこそが $BABY のガバナンスで本当に注目すべき点でもある。「コミュニティ・ガバナンス」という言葉があるからといって自動的に権限が分散しているとみなすのではなく、将来のメインネットでどの緊急権限が残るのか、誰がしきい値を変更できるのか、各アクションがチェーン上で追跡可能かを見るべきだ。#baby の保有者が投票しているのは抽象的なビジョンではなく、具体的な権限の境界なのである。

私の立場はこうだ。緊急委員会は工事期間中の手すりにはなり得るが、永遠に「安全のため」という一言で検査を免れるべきではない。まず自分で確認すること。あなたは、障害対応のために 3/5 のブレーキを受け入れるのか、それとも無許可システムにそんな総遮断弁は置くべきではないと考えるのか。コメント欄でぜひ率直に語ってほしい。

@BabylonLabs_io と GoMining の提携告知を見て、まず「最大1000枚のBTCをアクティベートする」といった部分に注目する人が多いでしょう。私はむしろ後半の流れに目がいきます。つまり、BTCをロックし、ステーブルコインを借り、その借りた資金を GoMining が運用するマイニング商品に投入するという流れです。

BTCを引き渡していないからといって、取引全体が最初から最後までコードだけを信じれば済むわけではありません。

告知の想定どおりに進めるなら、機関投資家は TBV でネイティブBTCをロックし、その後プログラム化してステーブルコインを借り出し、資金は GoMining のマイニング収益商品に入ります。そしてマイニング報酬は最終的にBTCで決済される。たとえば、権利証（不動産の所有権）がずっと自分の保険箱の中にあるようなものですが、あなたはその権利証を担保にしたローンを組み、その瞬間に他人が運営する鉱山へ投資してしまう。権利証が信託で預けられていないのは、第一関門の名義が変わっていないことを示すだけで、鉱山の電気代、設備、産量、そして経営結果について保証するものではありません。

告知文自体もかなり明確です。関連ツールは「トークン化ファンドの構造を採用する予定」で、独立した第三者のカストディ、管理運営、そして評価（バリュエーション）が付随します。初期段階では「最大1000枚のBTCをアクティベートする可能性がある」。これらの言葉は、まだ“計画のルート”であって、“稼働済みのメインネット収益の実績”ではないことを示しています。上限を在庫とみなし、予想を成約とみなすと、データはすぐに膨らみます。

本当に収益を計算するとき、マイニングのリターンは少なくともステーブルコインの利息、ファンドおよび管理コスト、Vaultの費用、そして清算のためのバッファをカバーできなければなりません。そうでなければ「BTC決済の収益」は、決済通貨が格好いいだけで、純利益がプラスだと意味しません。

私はこの組み合わせのプロダクトロジックは理解できます。長期保有者はBTCを売らなくても、流動性を借りてマイニング収益に参加できるため、資本効率は確かに高い。ですがリスクは「誰が私のBTCを持ち去るのか」から、「借入コスト、マイニングのリターン、そして第三者のファンド運用が同時にそれを上回れるのか」に置き換わっています。BTC価格が下がれば清算に触れ、マイニング収入が下がれば収益が圧迫されます。この2つのプレッシャーが同じ相場サイクルでぶつかる可能性もあります。

$BABY については、告知が成立後の費用がどのように回収されるのかという“確定した式”を提示していません。TBV はより多く使われるはずで、Babylon の基盤インフラ需要が拡大する可能性はありますが、「可能捕捉」はそのまま「すでに増収」とは書けません。#baby は、本当に待つべきなのは、ローンの実投入量、実際の純収益、清算の記録、そして費用の行き先です。

まずは計画と商品を分けて見てください。あなたはこれを、賢いBTC資本効率の連鎖だと思いますか？ それとも、担保リスクとマイニングリスクをつないで、より長い一本の貨車にしてしまう話だと思いますか？ コメント欄で続けましょう。
$ETH $SKYAI

@BabylonLabs_io のTBVテストネットのパラメータを改めて見直したところ、vaultBTC という名前だと勘違いを招きやすいことに気づきました。これは「1 vaultBTC＝1 BTC」で仕訳し、同じく8桁の小数を保持はするものの、自由に送金はできず、Aave v4 のアダプタ内に“内部会計単位”として留まるだけです。

倉庫で発行される電子の引換券みたいなものですが、この券は街中で流通できず、指定のカウンターでのみ担保として精算・計上できます。

ユーザーが Bitcoin 上の Vault にネイティブBTCをロックして起動すると、システムは対応する vaultBTC を鋳造し、Aave 側へ自動供給します。現状の公開テストネットでは、担保係数が78%なので、帳簿上の1枚BTCがそのまま100%の借入能力としては計算されません。このディスカウントは「後ろのBTCが減っている」という意味ではなく、価格変動・異なるシステム間の決済・清算時間に備えるクッションです。

なお、これらはすべてテストネットのパラメータです。単一のポジション上限は最大0.4 BTC、Aaveアプリの総上限は10 BTC。上限は少量のフローでメカニズムを観察するためのもので、大口ポジション、混雑、そして価格急落が同時に起きても、主ネットで同じように滑らかに動くと証明するには足りません。

私は、この制限には価値があると認めています。券をどこでも転がせないことで、セカンダリー市場でのアンカー（価格の乖離）や、重複担保、あるいは他プロトコルで誤って取り込まれる経路が減るからです。システムは vaultBTC をアダプタの中に閉じ込めていて、つまりこう告げています――それは「キャビネットの中に在庫がある」ことを証明する役目であって、どこへでも持ち出して売買できる新しいBTCを“再造”するものではない、と。

ただし問題は「指定されたカウンター」にあります。譲渡不可は組み合わせ時のリスクを下げますが、その代わり、利用可能性を Aave の統合、アダプタのコントラクト、そしてパラメータのガバナンスに結びつけてしまう。キャビネットは Bitcoin にあり、貸借の帳簿は Ethereum にあり、券はその間に挟まれている――どの層の状態が同期していなければ、ユーザーが見ているのは単純な「1コイン＝1コイン」の話とは限らなくなります。

$BABY は、名前だけではここで価値を自動的に得られません。見るべきは Vault の利用で手数料が発生するか、どのパラメータがガバナンスに属するか、そして経済活動が BABY の需要に戻り得るかです。vaultBTC の供給量をそのまま BABY の収入として計算するのは、ショッピングモールの保管証券の総額を不動産の利益のように扱うのと同じくらい不条理です。#baby

私の判断：譲渡制限は安全境界であって、プロダクト上の欠陥ではありません。ただ、安全境界が狭いほど、プロトコルへの依存はより集中します。あなたは、指定カウンターでのみ使える安全な証憑がほしいですか？それとも、自由に組み合わせられるがリスクが波及し得る流通資産がほしいですか？コメント欄で話しましょう。
$BTC $UBER

翻 @BabylonLabs_io 的Genesis V2升级说明时，我盯住了一道不太显眼的闸门：V2上线时给原生 $BABY 设置了IBC流出限额，24小时滑动窗口内最多流出原生供应量的10%。

一条主打跨链组合性的链，先给跨链出口装限流阀？看着拧巴，实际很现实。

V2同时加了IBC Callbacks、Packet Forwarding和Interchain Accounts，目标是让一笔跨链消息能转发、调用合约，甚至控制另一条链上的账户。好比原来只通普通貨物トラック的口岸，突然能跑联运、自动报关和无人集装箱。效率起来了，出事故时货也可能跑得更快，所以先规定一天最多放走一成BABY。

这道闸的价值很直白：如果IBC漏洞、错误路由或异常提现出现，攻击者不能一口气把整池资产抽干，治理和验证者多一点反应时间。安全上，我认这是一种务实保险，而不是承认IBC一定会出事。

官方还留了一个扩展口：其他资产也能通过治理启用保护。这说明限流不是写死在BABY身上的特殊待遇，而是一套可配置的跨链风控工具。可配置的另一面，就是参数不是自然规律；治理调高、调低或追加资产，都可能改变实际通行能力。

可限流不是免费午餐。极端行情里，正常用户和攻击流量挤同一个出口，谁先过、谁被卡、参数由谁调整，都会从技术问题变成治理问题。更关键的是，10%看起来很大，但要结合实际跨链流通量看；日常只用到很小一部分时，它是高高挂着的护栏，真正恐慌时才会突然变成排队口。

所以我看这次升级，不只看“BABY能去更多链”。开放得越多，越要把暂停、限额和恢复规则摊在桌面上。#baby の跨链价值不是能不能出去，而是出去时还能不能把最坏损失关在笼子里。

先核对规则再谈流动性。あなたは、10%の闸門が持ち币人を守るためのものだと思いますか、それとも最も必要なときに避難できるはずの人まで通常ユーザーを門口で止めてしまうのでしょうか？コメント欄で聞かせてください。
$BLESS $STAR