彭鱼宴啊

#dusk $DUSK @Dusk 夕暮れの処罰メカニズムには、ひとつ別途で自分の見解を述べたい設定があります。ノードの切断、出すべきブロックが出せなかったといった行為は、悪意とは言えないものの足を引っ張るもので、その対応はまず警告し、次に一部の担保を一時的に無効化状態へ移す、というものです。元本は1分たりとも焼かれません。ただし、報酬が一時的に受け取れず、一定期間コンセンサスから除外されます。本当にお金が燃えるのは、二重署名やブロックの偽造など、悪意がはっきり立証できる行為だけです。
この設計の意図は理解しています。最低担保のハードルがわずか千枚で、切断が一度起きるだけで元本をそのまま差し引いてしまうと、多くの「真剣に参加したいが技術条件が一般的には揃わない」小規模ノードが怖がって離れてしまい、結果としてネットワークの参加が最終的に少数の専門機関に集中しやすくなる。痛くない“ソフトな”罰で、より幅広い参加を得るというこの釣り合い自体は、筋が通っています。
ただ、私の見立てでは、この論理には明示されていない隠れた前提がひとつあります。それは「ネットワーク内で真剣にノードを運用する人が十分に多い」という想定です。ソフト罰なら、ネットワークの実際の運転効率を傷つけないはずだ、という前提です。仮にいつか大量のノードが同じクラウドサービス事業者、同じデータセンターに集中し始めたら、その一群の基盤に障害が起きた瞬間に、大量のノードが同時にソフト罰を発動し、同時にコンセンサスから一時的に除外されることになります。このとき「元本を燃やさない」ことが、逆に皆が自分のノードの安定性にあまり気を配らなくてもいい“容認”の要因になってしまう可能性があります。つまり、落ちても痛くないなら、誰が本当に極限までオンライン率を保証するために、厳しい投資や努力をするでしょうか。ハード罰のネットワークでは、このコスト感が運営者に対して基盤へのより真剣な対応を促します。ソフト罰がもたらす寛容さは、長期的には、ネットワーク全体の「真面目な運用」を重視する度合いを、ひそかに下げているのではないか――私は、これは継続的に観察すべきテーマであり、パラメータ表を一度見ただけで結論を出せる問題ではないと思います。

#dusk $DUSK @Dusk ずっと気になっていた具体的なシナリオがあるんです。誰かがブロックを生成する番になったとき、その人のノードがちょうど詰まってしまったりオフラインになったりしたら、ネットワークはそのまま待ち続けるのか、それとも自動で切り替える仕組みがあるのか？今回は、Duskのコンセンサス手順のこの部分がどう設計されているかを調べてみました。
Duskのブロック生成は3つのステップで進みます。まず、選ばれたノードがブロックを提案し、次に一群のノードが署名による投票でそのブロックが有効であることを確認し、さらに別の一群のノードが2回目の投票を行って、前の結果を集約し、最終的に正式に合意に到達します。この3ステップが完了すると1ラウンドです。選ばれた提案者ノードが定められた時間内に正常に提出できなかった場合、または途中の投票で必要な数が集まらなかった場合、そのラウンドはタイムアウトして失敗し、次のラウンドの反復に進みます。つまり、別の人に入れ替えて再挑戦し、真に合意が達成されるまでこのループが続きます。
当初私は、この「タイムアウトしたらやり直す」という仕組みは固定的で、毎回タイムアウトすると同じ一定の時間を待ってから再実行されるものだと思っていました。ところが開発ログを確認するとそうではありませんでした。そこには「自適応タイムアウトを実装する」という変更が明記されていて、さらに「より低いラウンドのブロックへフォールバックできるようにする」といった記述もありました。つまり、この仕組みは最初から最後まで同じ固定待機時間で動くのではなく、ネットワークの実状に応じて待機ウィンドウを調整し、「前の段階でより早いラウンドのブロックがすでに皆に受け入れられているなら、この後のラウンドでわざわざ無駄にやり直さない」といったケースにも対応している、ということです。この細かな点は、彼らのある開発サイクルの更新記録を見て初めて気づきました。プロトコル名やステップの説明だけでは、このような動的調整の層があることはまったく分かりません。
私にとって、この仕組みが解決しているのはかなり現実的な問題です。ネットワーク上のノード数が多くなると、必ず誰かがネットワークの揺らぎ（ジッター）や切断（オフライン）に見舞われます。この自動的な再選と動的なタイムアウト調整の仕組みがなければ、たまたま反応できないノードが出ただけでネットワークがそこで止まってしまう可能性があります。とはいえ、具体的な過去データまでは見つけられていません。たとえば現時点までに、このタイムアウトによる再選が実際のメインネットで何回トリガーされたのか、またトリガーされた後に平均でどれくらいで通常のブロック生成に戻ったのか、といった検証に使える情報は、現時点では調べきれていません

#dusk $DUSK @Dusk Dusk 里には2種類の口座体系があります。1つは公開して確認できる通常の口座、もう1つは暗号化して隠したプライバシー口座です。以前から、この2つは相互に変換できると聞いていました。今回は特に、その変換機能が実際にどう操作するのかを試してみました。他はひとまず置いておきます。
具体的な流れはこうです。Dusk の基盤には、送金ロジックを担当する専用のコントラクトがあります。同一のトークンを「隠し状態」から「公開状態」にする、あるいはその逆を行うとき、どちらもそのコントラクト内の“変換操作”を通ります。単純に「隠し口座の資金を先に引き出して、それから公開口座にあらためて入金する」ような乱暴なやり方ではなく、同じ資産が1回の操作で直接ステータス切り替えを完了し、その途中に、外部から個別に観測できるような中間ステップはありません。
自分でテストネット上で操作したとき、最初は方向を間違えてしまいました。本当は隠し口座から公開口座へ変換したかったのに、逆に「公開→隠し」になるように入力してしまい、お金は送金成功したものの、意図していた結果とはまったく違いました。しばらくいじってようやく気づいたのですが、変換機能そのものが壊れていたのではなく、操作画面上で2つの方向を取り違えていただけでした。
試した後の感想としては、この変換機能自体がかなりスムーズで、一発で完了します。中には、同様の切り替えを行うために、一度中継アドレスを経由しないと完了できない方式もありますが、このケースはそうではありません。ただ、見落とされがちな点も1つありました――この変換はお金“そのもの”のステータス切り替えだけを扱います。もし、法令順守のルールに紐づいた証券系の資産（たとえば名簿の審査が必要、特定の譲渡ルールを通す必要がある種類のもの）であれば、完全に別の仕組みで処理され、この変換機能をそのまま適用して対応することはできません。両者は別々に設計されています。最初は無意識に、すべての資産が同じように変換できるのだと思い込んでいましたが、あとから勘違いだと確認しました。

#dusk $DUSK @Dusk ずっと Dusk の「“プログラマブルなプライバシー”」という言葉を聞いてきましたが、言及されるたびに、いくつかの特徴をまとめて語られているように感じていました。今回は、そのうち「“選択的開示”」だけを取り出して見て、具体的にそれが何を指しているのかをはっきりさせたいと思っています。ほかのことはひとまず後回しにします。
私の理解では、選択的開示は次のような場面に対応しています。1つの取引が通常の状態では、外部からは金額や参加者が見えない――それがプライバシーの部分です。しかし、規制当局や監査側が確認する必要がある場合、すべての人に公開せずとも、ユーザーまたは機関が、権限を与えた相手だけが見たい情報を個別に見られるようにする手段を持っているべきです。これは「すべて公開するか、すべて隠すか」という古い発想とは違って、この2つの両極端の間に、制御可能な通り道を無理やり1本作るようなものです。
最初は、この「選択性」はチェーン外の人手による操作で実現しているのだと思っていました。つまり、問題が起きたらオフラインの手順で取引記録を取り出して規制当局に見せる、といった形です。資料を調べてようやく、それがそうではないと分かりました。公式の説明では、この能力は暗号学的なツールを使ってプロトコルの中に直接組み込まれており、ユーザーまたは機関自身が、特定の対象が閲覧できる証明書を生成するかどうかを決めるため、事後に誰かにバックエンドのデータベースを呼び出してもらう必要はありません。この理解のズレは、2回説明を読み返したことで初めて修正できました。最初は確かに、考えが単純すぎました。
ただ正直に言うと、公式資料には「“この開示要求を行う権限があるのは誰か”」「“この証明書で具体的にどれくらい細かい情報まで見えるのか”」といった実行上の細部がかなり大まかにしか書かれていません。具体的な手順としてそのままなぞって実行できるような説明がないのです。これはつまり、「選択的開示」は現時点では、プロトコル層としてはすでに備わっている能力である可能性が高い一方で、実際のある特定のシーンでどう使うのか、誰が起動するのか、承認プロセスにどれくらい時間がかかるのか、といった点は、今後 NPEX のような協力パートナーと一緒に実際に展開されるプロダクトの詳細次第かもしれません。今回、すでにうまく動いている具体的な事例を調べきれなかったので、その能力が実運用で使いやすいかどうかは評価できません。いま確認できるのは、その能力が存在するということだけです。

#dusk $DUSK @Dusk ずっと気になっていたんだけど、Duskのエコシステムにある開発基金って具体的にどう運用されているの？チームが自分たちで決めるのか、それとも外部の人でも申請できるような仕組み（プロセス）があるのか。統治（ガバナンス）に関する説明を一通り調べてみたら、最初に想像していたよりもずっと正式なプロセスだと分かった。
この基金の資金源はとてもシンプルだ。メインネットでブロックが1つ生成されるたび、報酬の中から一定割合が固定で切り出され、長期的にこの基金プールへ積み立てられる。つまり、単発の寄付募集やチームの持ち出しで賄うのではなく、後続のエコシステム開発や研究活動を支えるために用意されたものだ。
実際に権限が分かれているのは、承認プロセスの部分にある。たとえば、プロトコルそのものに関係する修正――ある具体的な技術改善提案などは、「提出→審査→採用するかどうか決定」という流れで処理される。フォーマットとしてもかなり整った書式が求められていて、正式な技術提議書のような体裁でなければならない。「適当に投稿して済む」というわけではない。一方で、プロトコルコードと直接結びつかない支出――たとえばあるウォレットツールの開発、特定の課題に関する研究費のようなものは、別の承認ラインになる。これらは、当該の資金配分を担当するガバナンス小委員会が評価して決定する。理論上は、外部コミュニティのメンバーも、その小委員会の選挙プロセスに参加することで、承認プロセスそのものに関わることができる。
私は当初、これは「チーム内部の承認」というブラックボックス的な手続きだと思っていた。だが説明を読んで分かったのは、少なくとも文書上では、この2つのラインがかなり明確に切り分けられているということだ。それに加えて、外部の人が申請を提出したり、審査に参加したりできる入口も両方に用意されていて、完全に閉ざされているわけではない。ただし、文書上の説明と実際の運用は別物だ。ここ数年でどんなプロジェクトが承認されたのか、承認率はおおよそどれくらいなのか、外部からの申請がどの程度の割合を占めているのか、といった具体的な実行データは、現時点では手元で確認できていない。この点については、少なくともプロセス設計としてはオープンだと言える一方で、実際の運用がどれほど透明かどうかは、より多くの過去記録によって検証する必要があり、現時点では確定的な判断を下せない。

#dusk $DUSK @Dusk 最初、私は「質押 DUSK をプロビジョナー（provisioner）として行う」という話について、想像がかなり単純でした――少しコインを入れて、ノードを立ち上げて、報酬を受け取るのを待つだけだろう、と。ところが、公式の安全な運用ガイドラインを真面目に調べて、手順どおりに実際に準備してみたら、私の思っていたよりもハードルはかなり高いことが分かりました。
ガイドラインで推奨されているのは、質押権限を持つ owner key を、日常的にネットに接続している PC のハードディスクに置くのではなく、LUKS で暗号化した USB デバイスに直接生成する、というやり方です。具体的には、まず cryptsetup を使って USB メモリを LUKS のフルディスク暗号化にし、強固なパスワードを設定します。そのうえで、ウォレットの保有者鍵（持ち主の鍵）を、その暗号化パーティション内に直接生成します。普段は USB を挿さず、質押を解除する、あるいは報酬を引き出す必要があるときだけ挿して、1 回だけ使用します。この方法の狙いは、仮にその USB が紛失したり盗まれたりしても、パスワードがなければ中身を読み取れないようにしておくことです。日常のノード運用では、さらに権限の低い別の鍵を使い、本当に質押元本を動かせる owner key とは分離するわけです。
この手順に沿って一通りやってみて、いちばんの実感は「これはボタンを数回押すだけではなく、ディスク暗号化やオフライン鍵管理といった運用（オペレーション）レベルの知識を理解することが求められる」という点でした。普段コードを書いてはいるものの、専門の運用担当ではない私にとっては、/dev/sdX のどれに当たるデバイスを入れるべきか、うっかり違うパーティションをフォーマットしてしまわないためにはどうするか――そういった確認だけでも、何度も往復しながらかなり時間がかかりました。
これにより、Dusk の質押への参加度（participation）について改めて考え直しました。最低質押の敷居は 1000 DUSK で、聞こえはかなり低いのですが、公式が推奨する安全基準どおりに実際に運用しようとすると、「1000 枚コインがある」という単純な話では済まず、一定の技術力と、手順を最後までやり切る忍耐が必要になります。おそらくこの条件は、「とにかく楽に質押したい」だけの一般ユーザーを自然とふるい落としてしまうでしょう。残るのは、ノードの安全性をきちんと考えて向き合う人たちが中心――ネットワークの安全性にとっては良いことです。でも「質押参加が十分に分散的である」という目標に対しては、そもそもの操作上のハードル自体が、見落とされがちなフィルターになっている可能性もあります。

#dusk $DUSK @Dusk 先ごろ友人に Dusk のコンセンサス機構について話すとき、つい以前見た話をそのまま持ち出してしまいました——Dusk は Proof of Blind Bid を使っていて、ブロック生成者の身元は匿名で、ゼロ知識証明により、自分のステーク額を隠して出块権を競うのだ、と。話し終えたあと自分の中で疑問が湧きました。これは本当に Dusk が今も採用している仕組みなのか、それともかなり古い資料に書かれていた内容を覚えているだけなのか。調べてみたところ、確かに自分が間違っていました。
初期バージョンの Dusk ホワイトペーパーでは、Proof of Blind Bid は確かにとても工夫のある設計でした。ブロック生成候補者（Block Generator）が「Bid Transaction」を提出し、ステーク額を Poseidon ツリーに格納し、それに対応するゼロ知識証明を生成します。そうすると、外部からは誰が参加しているのか、どれだけ賭けているのかが見えません。この設計の狙いは現実的で、出块人の身元とステーク額が公開されると、攻撃者にとっては「重点的に攻撃すべき対象リスト」ができてしまい、既知の大口の出块人に対してネットワーク層で狙い撃ち攻撃が可能になるからです。匿名での競争は、こうした特定の攻撃への対抗として、Dusk が初期に提示していた暗号学的な解決策でした。
しかし現在の Dusk 公式ドキュメントに記載されているメインネットのコンセンサスは、Succinct Attestation と呼ばれる委員会ベースのステーキ証明設計で、provisioner が決定論的な選挙で候補ブロック生成者と投票委員会を選び出し、その全プロセスの中で「匿名での競争」という概念については触れられていません。言い換えれば、Dusk は初期の設計からメインネットへの実装に至る過程で、「出块人の身元を匿名にする」という特性をこっそり入れ替え、効率と決定的なファイナリティを重視する委員会メカニズムへと転換したのです。
この変化は大々的に説明されたわけではありませんが、意味は小さくありません。初期の Proof of Blind Bid が解決しようとしていた「標的型攻撃を防ぐ」という課題を、Succinct Attestation では別のアプローチで扱うようになり、委員会の規模や選挙の予測不能性により多くを依存する一方で、アイデンティティを完全に隠すことには重点が置かれていません。私にとってこの出来事は、次のことを思い起こさせます。プロジェクトの技術設計は、数年前に書かれた文章だけを根拠に判断してはならない、ということです。Dusk の中核メカニズム自体が継続的に改良されており、当時「とてもクールに見えた」匿名での競争を前提にした設計は、いま実際に稼働している姿とは異なる可能性が高いのです。

ついに待ちに待った $ALIGN TGE が来た

本日北京時間 23:00、Aligned が TGE を開始します。

ZK Proof Verification と Ethereum の検証可能な計算インフラに注力するプロジェクトとして、Aligned はこれまでのプロダクト構築がかなり堅実です。

今日のパフォーマンスに期待し、Aligned の今後のエコシステムがさらに拡大していくことにも期待しています。

さらに、Coinbase など取引プラットフォームにも上場の計画があるので、しっかり“お肉”を食べられるといいですね
$ALIGN 🚀

#dusk $DUSK @Dusk これまで私は Phoenix について、「これは Dusk バージョンの Zcash/Monero」であり、完全に匿名を追求するプライバシー取引モデル——送金当事者の双方が互いを見られない——だと理解していました。しかし最近、2024 年に更新されたホワイトペーパーの公式説明を照らし合わせて見たところ、この理解はすでに古くなっていることに気づきました。
公式の更新説明には、かなりはっきりと書かれています。彼らは Phoenix に「受信者が送信者の身元を認識できる」機能を追加し、さらにこれが Phoenix を匿名プロトコル（anonymity protocol）から、プライバシー保護プロトコル（privacy-preserving protocol）へと改めるものであることを明記しています。目的は、現在の欧州の規制要件に適合することです。同じ説明の中で、Moonlight（透明な口座モデル）を追加する直接の動機についても触れられており、チームが気づいたのは、取引所や機関とスムーズに連携するには、純粋に匿名な口座モデルだけでは不十分だという点でした。彼らは正直に、その理由を「コンプライアンスを維持し、上場廃止のリスクを取り除くため」だと書いています。
この転換は、多くの人が思っている以上に大きいと私は感じます。「匿名」と「プライバシー」という2つの言葉は、暗号のコミュニティでは同義語ではありません。匿名プロトコルは、第三者（受信者を含む）に対して送信者が誰かを特定できないようにすることを目指します。一方、プライバシー保護プロトコルは、無関係な外部者が細部を見られないことを保証しますが、取引当事者間での識別可能性は保持され得ますし、むしろ意図的に設計することさえできます。Dusk は前者を自ら手放し、後者を選びました。これは技術的な妥協ではなく、非常に醒めたプロダクトのポジショニング調整——初期ホワイトペーパーでの Phoenix の野心は、むしろ純粋なプライバシーコインに近いところにあったのに、後から規制の現実にその方向性を引きずられて変えられた、ということです。
私は以前、「匿名」が Phoenix の最も核心的なセールスポイントだと思っていました。しかし振り返ると、この理解自体が、進化した協定を評価するために、過去の古いホワイトペーパーをそのまま手にして判断していたのだと分かります。「Dusk は匿名コインかどうか」という枠組みでそれを判断している人にとっては、この問いそのものが、すでに間違っているのかもしれません。本当に問うべきなのは、「受信者が送信者を識別できる」という前提のもとで、Phoenix のプライバシーの境界線が具体的にどこに引かれているのか、そしてその境界が、Phoenix が想定する機関のコンプライアンス要件のシナリオを十分に支えられるのか——という点です。

#dusk $DUSK @Dusk ずっと前から、Dusk のトークン経済（通証経済）の紹介を見るたびに、同じ一文が何度も出てきます。それは「5億枚のDUSKが、36年の間に段階的にステーカーへ放出される」というものです。この文は、ほとんど体感できないほど緩やかで、インフレ（通貨価値の下落圧力）がほとんどかからないようなリリースカーブを描写しているように聞こえます。私も以前はそう理解していましたが、自分で公式ドキュメントにあるパラメータを計算してみると、話はそれほど単純ではありません。
Dusk の総量上限は 10億枚で、そのうち 5億枚はメインネットに上线する前からすでに流通しています。残りの 5億枚は等比減衰モデルに従って36年かけてステーカーへ放出され、その減衰率は「4年ごとに半減」します。この「4年ごとに半減」が重要なポイントで、減衰の全シーケンスを等比数列として展開すると、最初の4年周期に放出される量は、残り5億枚の“半分”にだいたい相当し、つまり約2.5億枚程度になります。ざっくり計算すると、最初の4年間の平均的な年間放出量は、「5億枚を36年に平らに敷き詰めた」場合に相当する「平均インフレ率」の4倍以上になります。
つまり、「36年かけてゆっくり放出される」という言い方自体は嘘ではないのですが、つい「毎年の増発速度はだいたい同じで、かなりなめらか」と無意識に連想してしまいがちです。実際には、前半のほうが増発の圧力が明確に集中していて、その後は4年ごとに放出スピードが半分ずつに切り詰められていくため、カーブは急カーブに下がっていき、平らな一本線ではありません。ステーキング報酬に対する実際の期待値という観点では、この違いは無視できない細部です。早期に参加した人が受け取るのは、放出速度が最も速い区間の報酬プールであり、後から参加するほど、受け取れる新規発行分はどんどん薄くなっていきます。
私は、これを設計上の欠陥だとは思いません。等比減衰そのものは、多くのPoSネットワークでよく使われる手法で、初期に十分なインセンティブを与えて検証者ネットワークを立ち上げ、後半でインフレを徐々に収束させるためのものです。ただし、「36年」という数字だけを見て通貨インフレ圧力が均一に分散していると決めつけると、実態を見落とす可能性があります。私が次に自分に課した観察ポイントは、2026年以降に数えて最初の4年減衰ノードあたりまでを目安に、実際のオンチェーンでのステーキング報酬の支払いデータを検証し、この等比モデルの理論曲線と一致するか確かめることです。もし一致していれば、チームがホワイトペーパーの経済モデルを安定的に実行していることを意味します。一方で偏差が出るなら、それは再評価が必要な別のシグナルになります。

#termmax @TermMax 私は最初、TermMaxFi のインセンティブ（ポイント）システムを、いわゆる通常のエアドロップのやり方だと思っていました。結局、使えば使うほどポイントが高くなるだけだろうと。ところが公式が、XP と MP は別物だと明確に強調する専用投稿を見て、この設計にはもっと掘り下げるべき課題が隠されていると気づきました――いったいプロトコルは誰に報酬を与えたいのか。
XP は、プロトコルの中でどれだけ深く使ったかに対応しています。預けた量、借りた量、ポジションを開いていた期間など、純粋に利用データです。MP は、プロトコルの外でどれだけの影響力を生み出したかに対応しており、伝播や新規獲得といった貢献により近いものです。この2つの曲線を別々にスコア計算することで、黙々と借りて投稿もしないユーザーと、毎日のように投稿するもののオンチェーン上のポジション規模が小さいユーザーでは、エアドロップの配分ロジックがまったく異なります。
この設計は、私にはかなり誠実に見えます。少なくとも、マーケティングの話題量を「プロトコルの稼働」みたいに見せかけてごまかしてはいません。でも、それは同時に新たな問題も生みます。もし MP の重みが高すぎると、プラットフォームは、実際の借入量に見合う裏付けがない状態でも、ソーシャル上の声量を先に積み上げてしまう可能性があるからです。すると、TVL の数字は見栄えよくなっても、オンチェーンでの実際の約定に基づく固定金利の借入規模が、必ずしも同じように増えるとは限りません。TermMaxFi は今年、TVL が約3500万ドルに近づいたことがありますが、その数字自体は XP によって押し上げられたものなのか、それとも MP による注目がついでに底上げしたのか――分けて見極める価値があります。
これから注目するのは2つです。XP と MP のランキング上位ユーザーの重なりがどれくらい高いのか、そしてポイント（インセンティブ）期間終了後、エアドロップが着地した後に、オンチェーンの借入量がはっきりと一段落するかどうか。エアドロップは活性化は促せても、定着（リテンション）までは必ずしも生みません。

#dusk $DUSK @Dusk 昨年、Dusk と21Xがコラボしているというニュースを見たとき、最初の反応は「Dusk も欧州の DLT パイロット（DLT Pilot Regime）制度のライセンスを取得したんだ」でした。今回はその事実を確認するためにタイムラインを振り返り、ある意味で理解を半分間違えていたと分かりました。

まず背景から。DLTパイロット制度は、欧州がDLT取引の決済基盤インフラ向けに設けた一時的な規制の受け皿で、ある機関が取引の執行（マッチング）と決済の両方を同時に行えるようにし、従来のように中央証券保管機関を別途探す必要がありません。21Xはドイツの企業で、2024年末にこの種の「DLT取引・決済システム」（DLT-TSS）ライセンスを得た最初の機関となり、Polygon上で稼働しています。

そしてDuskと21Xの提携ですが、公式の文言は「Duskは取引参加者（trade participant）として参加する」一方で、「当社は規制上の免除の利用権を得ており、相手は当社の機関レベルのブロックチェーン基盤を得る」というものです。つまり、ライセンスは常に21Xが握っており、Duskは提携を通じてこの規制上の免除を“借りる”形であって、自分自身でDLT-TSSライセンスを取得しているわけではありません。これは、私が最初に抱いた印象とはまったく違います。

さらにさかのぼると、2024年3月の時点でDuskとNPEXはすでにDLTパイロット制度の資格を共同申請する準備を進めていました。つまり、この規制ルートはDuskにとって少なくとも2年以上は検討されていたもので、場当たり的な思いつきではないようです。ただ、私が確認できた最新の公開情報の範囲では、Dusk自身の名義で独立したDLT-TSSライセンスの記録は見当たりません。21Xの公式サイトには、現時点で欧州全体でこのライセンスを保有しているのは21Xと、プラハのCSD Pragueの2機関だけだと明記されています。

私が自分に課した判断基準はこうです。1年以内に、Dusk（またはそれと深く結びついたNPEX）が自分自身の名義で独立したDLT-TSS、または同等のライセンスを取得していることが確認できれば、この規制ルートが本当に機能しているということになります。逆に、ずっと「参加者として他社のライセンスに接続する」という状態にとどまっているなら、この物語の説得力は割り引きが必要で、すでに手元にある“自分のライセンス”というよりは、順番待ちで自分の許可証を取りに行っているようなものに近いと考えざるを得ません。

固定利率の借入契約を見ていたとき、以前はAPYの数字ばかりに注目していました。ところが@TermMax の清算ロジックを掘り下げるまで、本当に考えるべきなのは金利そのものではなく、「期限までに返せない」事態に対してそれがどう処理するかだと気づきました。

従来の借入契約の清算ロジックはかなり乱暴です。担保価値がしきい値を下回ると、担保をそのまま売り払い、ステーブルコインに換える。ボラティリティが高いほどスリッページは大きくなり、借り手と清算担当者の双方が互いに大きな損失を被り得ます。TermMaxは「現物決済（physical delivery）」の発想を使っています。極端な相場や流動性不足のとき、担保はまず市場で叩き売りしてから決済するのではなく、直接貸し手へ引き渡します。狙いは、パニック相場の板で資産を安く売って二次的なダメージを作るよりも、清算を一度で確実な資産引き渡しに変えることです。

その三代トークン構造もこの考え方に沿っています。借り手は担保資産を鋳造してGT（ERC-721で、担保と負債を単一のポジションにパッケージ化）を作り、同時に期限到来時の元本と利息の支払いを表すFTを発行します。FTは元本と利息の2つに分解され、利息部分は売られてXTに換えられます。一方、元本部分は借り手に残されます。複数のプロトコル間で行ったり来たりすることが必要だったループ型の借入は、1本の取引に圧縮されました。

この設計は今では、トークン化株式の担保シーンにも接続されています。BNBチェーン上で一部の資産に対するオプションやカバード戦略の試みを行っており、対応したいのが暗号ネイティブ資産だけではないことを示しています。

ただし、はっきり言っておく必要があります。physical deliveryの仕組みは現時点では、通常のボラティリティの範囲では動作が成立しているものの、真のストレステストは「極端な相場下で担保が問題なく、期限どおりに貸し手へスムーズに引き渡せるか」、そして「クロスチェーン展開で流動性がその一連を支えられるか」です。十分に長い期間のデータは、まだ見えていません。

次に注目するのは2つの指標です。極端な相場下でのGTポジションの実際の引き渡し記録、そして各チェーン上の清算に必要な流動性が同時に追随できているか。固定金利の約束は書きやすい。でも引き渡し能力こそが本当の試験です。#TermMax

私はひとつの癖があって、プロジェクトを見るときはまずKOLがどう言っているかを確認せず、公式サイトに行って検証可能な数字を探します。先週はDuskの公式サイトをじっくり読み返して、いくつかの数字を見つけました。確認した後の感想は、とても複雑でした。
公式には「3億ユーロ以上の確定発行量」「5万人以上の投資家への到達」「2.1億以上のDUSKの質押量」と書かれています。
私の第一反応は興奮ではなく疑念でした。3億ユーロという数字は、どんな基準（口径）なのでしょうか？ 確定発行とは、オンチェーン上で実際に完了した資産発行のことなのか、それとも意向書にサインしただけでまだ上チェーンされていないもののことなのか？ この2つは差がとても大きい。前者は実際に起きたことで、後者はパイプラインの数字にすぎません。
ただ、それを世の中にある「やたらと『兆（万億）級RWAの入口』だ」と叫ぶようなプロジェクトと比べてみると、3億ユーロという数字の面白さは、大きさではなく「追及できる数字であること」にあると感じました。口径は何かを問えるし、この3億にどんな資産が含まれているのかを問えるし、発行後にセカンダリー市場での活動があるのかを問える。こうして追及できる数字は、壮大だけど曖昧な物語よりも情報量が多い。
私の判断を本当に変えたのは、別のことでした。Duskのここ数年のロードマップは、数か月ごとに物語を入れ替えるのではなく、合意レイヤー、実行レイヤー、資産発行、取引、そして規制インターフェースを、段階を追って上に積み上げています。進むペースは遅いけれど、各ステップについてエンジニアリングのアップデートの中で対応する記録を見つけられる。@Dusk
プロジェクトが、熱がない年でも、ライセンス、資産ルール、決済の細部といった、見た目に面白くないことを延々と掘り下げている場合、その目的関数はおそらく短期の注目度ではありません。私はこういうプロジェクトには、少し多めに時間を与えてもいいと思っています。必ず成功するからではなく、もしそれが成功したら、本当に複製しにくいものをやっているからです。
#dusk $DUSK

あの$DUSK のAegisアップグレード、私は当日ずっとノードのパネルを見守りながら徹夜で対応していました――公式の説明はかなり率直で、これが「すべてのノード運用者を対象とした強制アップグレード」です。これに従わないと、ハードフォークが有効化された瞬間に、移行期間なしでネットワークから直接外れてしまい、選択肢はありません。
Rusk v1.7.0の更新ログをざっと見てみると、今回のアップグレードには地味だけどかなり重要な修正が紛れています。dusk-wallet-core に「Phoenix残高の集約がu64のオーバーフローでラップ（巻き戻り）してしまうのを防ぐ」というものです。平たく言えば、元のウォレットのコードがPhoenix（Dusk独自のUTXO暗号化アカウントモデル）の残高を合計するとき、数値がオーバーフローしてから「ごく小さい、あるいは誤った数字に戻ってしまう」理論上のリスクがありましたが、今回のアップグレードでその地雷を塞いだということです。同じ一連の変更には、PLONK証明の検証をV3へ切り替え、HTTPリクエストボディにサイズ制限を追加してメモリDoSを防ぎ、復旧フローで不安全なZIPのパス・トラバーサル書き込みの脆弱性を塞ぐ――といった、いかにも「本番級システムのセキュリティ強化」をするための動きが並んでいます。機能追加ではなく、排雷です。
ノード運用者として私が本当に気にしているのは、アップグレード・ウィンドウそのもののリスクです。Aegisのメインネットでの有効化ブロックは3,590,904、テストネットは2,773,727で、ブロック高に合わせて固定されたハードフォーク点です。「いつアップグレードが完了したらいつ有効になる」というソフトな時間枠ではありません。つまり、一部のノードがそのブロック高までにアップグレード完了できなかった場合、ネットワークが一時的にフォークによるコンセンサス不一致を起こすのではないか？という懸念が残ります。公式の説明は「これはDuskEVMのためのインフラ型アップグレードで、トークン経済学には関わらない」。影響はコントロール可能に聞こえますが、強制的なハードフォークそのものが持つ性質上、分散度が高いとは言いにくくノード数もまだ多くないネットワークにとっては、常に“本物の”協調リスクのテストになります。#dusk
今回のアップグレードは無事に反映されました。ある意味で@Dusk は、正式にDuskEVMを走らせる前に、自分たちの基盤となるコンセンサスとストレージ層に対して先行で負荷テストを行ったようなものです。アップグレード自体に問題はありませんでしたが、「強制ハードフォーク」というこの4文字は、ノードを走らせる準備をしている人、またはDuskの決済における決定性に依存している人に、もう一度よく見てもらう価値があります。

#dusk 多くの人が初めてRWAという言葉に触れると、たいてい「やり方は一つしかない」と思い込んでしまいます。つまり、現実世界の資産を“パッケージ化”してトークンにし、チェーン上で取引するだけだ、と。私も以前はそう理解していましたが、@Dusk が“トークン化”と“ネイティブ発行”を別のものとして分けて捉えているのを見てはじめて、見落とされがちな細部がここに隠れていることに気づきました。
トークン化とは、端的に言えば、すでに存在する資産に対するデジタルの“鏡”の層をかぶせることです。ビル、不動産担保証券、ファンドなどがまず従来の体制の中で存在し、それをある仲介者がチェーン上の証明書として包み込むのです。ここには本質的な「信頼の跳躍」があります。つまり、あなたが信じているのはチェーン上のコードではなく、“包装”を担当する仲介者が誠実に履行するのか、対応する裏付け資産を本当に保有しているのか、という点です。チェーン上がどれほどクリーンでも、この依存の層は消し去れません。
ネイティブ発行は別の道です。資産のライフサイクルを最初からチェーン上で完結させ、発行・流通・決済・権利の配分までを、可能な限り従来システムに回帰する不透明な中間工程を経ずに行います。従来の機関が消えるという話ではありません。機関そのものに適切な資格とプロダクト設計能力がある場合、チェーン上の基盤は、資産本体に本来属する手続きをより多く引き受けられ、事後の“ミラー層”としてだけ機能するのではなくなる、ということです。
Duskが提供する基盤の狙いは、この2つの経路の両方を同時に支えられることにあります。つまり、トークン化のような過渡的な形にも対応し、条件が整えばネイティブ発行のワークフローも引き受けられるのです。この「唯一の答えを前提にしない」という姿勢は、かなり誠実だと感じます。なぜなら、機関ごとのコンプライアンスの進み具合、プロダクト設計、規制当局からの許認可がそれぞれ異なり、すべてのケースに同じテンプレートを当てられるはずがないからです。
ネイティブ発行は遠い目標に聞こえるかもしれませんが、実はとても素朴な問いにつながっています。資産の“真実”は、いったい誰が証明すべきなのか？$DUSK が下したネットワーク上の答えは、「証明のプロセスそのものを、できるだけチェーン上で完結させるべきで、仲介者のただの約束に頼るべきではない」というものです。

#dusk $DUSK 说实话，我一开始对"RWA 上链"这四个字是有点疲惫的——这几年听过太多项目喊这个口号，最后落地的往往只是一张截图和几句愿景陈述，经不起细看，更别说经得起监管层的审视。但这次翻到 @dusk 和荷兰交易所 NPEX 的合作细节时，我的态度改了。
NPEX 不是一个新造的名词，它是受荷兰金融市场管理局（AFM）监管的持牌交易所，同时持有 MTF、经纪商和 ECSP 牌照——这些缩写背后，是真实存在了很多年、经过反复检验的欧洲金融监管体系，不是随手拼凑出来的概念，也不是靠一份白皮书就能自封的资质。这次合作计划把超过 3 亿欧元的资产逐步搬上 Dusk 的链，而承接这些资产的应用层，是 Dusk Trade。
Dusk Trade 被定位成一个"新型券商"，跑在 DuskEVM 之上，目标是把货币市场基金、ETF、债券这类传统金融产品变成可以真正持有、即时结算、还能和 DeFi 组合玩法对接的链上资产。它本身也按照适用的欧盟法规，朝着受监管的 MTF 和投资平台方向去搭建合规架构，而不是先上线再补文件，这种顺序上的选择本身就说明了一些态度。
我意识到，这种叙事和"某个匿名团队发币"完全不是一回事——它更像是传统金融机构在小心翼翼地测试一扇新门，而这扇门的另一边，需要有牌照、有审计、有可追溯的合规链路撑着，@Dusk 想成为这条链路本身，而不是绕开它的捷径，这也是我愿意花时间去理解它的原因。
这不是一夜之间会兑现的故事，欧洲的金融监管从来不是快节奏的游戏，牌照、审计、跨境协调都需要时间，任何跳过这些步骤的承诺都值得多一分怀疑。但当我看到"持牌交易所"和"链上结算"第一次被写进同一份合作公告里，值得持续关注它后续怎么落地，尤其是那 3 亿欧元资产真正迁移的那一天。

$BABY の解除期間の設計について調べてみたところ、それがネットワークのセキュリティとユーザーの流動性の間で、かなり意図的な取捨選択をしていることに気づきました
質押プロトコルにおける解除期間という設計は、しばしばユーザー体験の問題として議論されます。長すぎると面倒ですし、もっと早くしてほしいと思うこともあります。しかし私は@BabylonLabs_io の解除期間ロジックを、安全設計の観点から真剣に見直してみて、流動性の制約以上に深い理由があることを見つけました。そしてこの設計には、きちんと説明されるべきだと感じる「取引（トレードオフ）」が1つあります。
解除期間の最も核心的な役割は、スラッシング（没収）メカニズムが実行されるための時間を確保することです。もし最終性提供者がダブル署名を行った場合、証拠は検出され、チェーンに記録され、その後にスラッシング取引がトリガーされる必要があります。こうした一連の処理はオンチェーンで完了するのに時間がかかります。解除期間がなければ、不正を働く検証者は、証拠が提出される前に質押BTCをすべて引き出してしまい、スラッシングの仕組みは実質的に無意味になります。解除期間は本質的にこう言っているのです――あなたのBTCは出ていってよい。ただしこの時間は待ってください。この時間の間に、あなたが委託した検証者が不正を働いたことが見つかれば、まだ罰を実行する間に合う、と。#baby
この観点から言えば、解除期間はユーザー体験の妥協ではなく、セキュリティ・メカニズム全体が成立するための前提条件です。解除期間がなければ、スラッシングには歯がありません。歯のないスラッシング脅威は本当の脅威ではなくなり、検証者の行動制約は大幅に弱まってしまいます。
ただし、ここには1つ、明らかにされるべき取引（トレードオフ）があると思います。解除期間が長いほど、セキュリティ・ウィンドウは十分になり、スラッシング・メカニズムはより信頼できるものになります。一方、解除期間が短いほど、ユーザーの流動性は向上し、参加に伴う摩擦は低くなります。Babylonは最短の解除期間を約7日としており、この数字は2つの目標の間でバランスを取ったものであって、純粋な技術的制約ではありません。
7日間はBTCを長期保有している人にとってはほとんど影響がありませんが、短期トレーダーにとっては現実の流動性コストです。これは、Babylonの質押がユーザー構成の面で自然に長期保有者を選別し、短期資金ではなくなることを意味します。プロトコルの安定性という観点では、このユーザー選別は有利です。長期保有者は市場の変動時に大量に解除することがないため、TVLの安定性が高くなります。

ビットコイン保有者がBTCに利回りを生み出してほしいと思うなら、$BABY が出現する前は基本的に選択肢は2つしかなかった。BTCを中央集権的な機関に預けて管理してもらうか、BTCをWBTCのような合成資産にラップして、イーサリアムへと架橋するか。これらの選択肢には共通の代償がある。つまり、誰かを信頼しなければならないということだ。WBTCはBitGoを信頼し、cbBTCはCoinbaseを信頼し、クロスチェーンブリッジはマルチシグ委員会を信頼する。業界は何十年もかけてきたが、この問題を避けて通ることはできなかった。
@BabylonLabs_io は、ビットコインのネイティブなスクリプト言語で、この問題をもう一度やり直した。BTCはタイムロック契約にロックされ、契約ロジックはビットコインチェーン上に直接書き込まれる。つまり、いかなる第三者も経由する必要がない。アンロックの条件は、人の保証ではなく、暗号学によって強制執行される。この発想の転換は、技術的には段階的な改良ではなく、方向性そのものが根本的に異なる。 #baby
では、この件には本当の需要があるのか？56853枚のBTCをそこに置いてあることが、最良の答えだ。これは補助金で出てきた数字ではなく、ユーザーが自分のビットコインを自発的にロックすることを選んだ結果であり、しかもロック期間は最短で7〜10日かかってからでないと解除できない。流動性の制約を受け入れる人たちは、このメカニズムへの信頼が本物であることを示している。
入金にかかる時間は、当初の約1日から、現在は約3時間へと圧縮された。オンチェーン手数料も3倍以上に抑えられた。これらはオンチェーンで検証できる、実際の技術的な進歩であり、ホワイトペーパーの約束ではない。Consensus 2026がマイアミで開催された際、Babylonの創設者は、機関投資家が現在話している中核は担保の完全性と資本効率だと述べた。そしてTBVの設計ロジックは、まさにこのニーズにぴったり合致している。
さらに、今年1月にa16zが1500万ドルを追加投資し、Aave V4がネイティブBTC担保を正式に接続した。最終性提供者250名で構成される検証者ネットワークも稼働している。これは“紙の上”の構想ではなく、動いているエコシステムだ。
私が最初にBabylonを研究し始めたときは、その問題点を見つけるために多くの時間を費やした。いくつか見つけて、書き出した。しかし今日は、別のことを伝えたい。私が研究してきた、BTC跨チェーンの信頼問題を解決しようとするあらゆる試みの中で、Babylonは現時点で唯一、ネイティブなステーキングを5億ドル超の規模まで本当に到達させながら、同時に安全性面で大きな問題を起こしていない。これはそれ自体が強いシグナルであり、真剣に受け止める価値がある

GRVTの技術構造

価格は0.2545ドルのサポートと0.2700ドルのレジスタンスの間で揉み合い、MACDヒストグラムがマイナスに転じています。これは買い（ロング）の勢いが弱まっていることを示します。

1時間足では、より高い安値を形成していますが、0.2700ドルを継続的に上抜けできていません。RSIは33まで下落しており、売られ過ぎ状態である可能性は示唆されていますが、出来高による確認が必要です。

重要なトリガー：
終値が0.2700ドルを上回り、かつ出来高が増加するなら、トレンド継続が確認されます。逆に、0.2545ドルを下抜けると、0.2389ドルまで下値を試しに行く可能性があります。$

取引チャンス

短期：出来高が安定している場合、0.2545〜0.2580ドル付近で押し目買いを狙うことができます。目標は、再度0.2700ドルのレジスタンスをテストすることです。

中期：価格が再び0.2700ドルを上回り、MACDが確認した場合は保有を継続でき、直近高値の0.2857ドルを目指します。

長期：0.2389ドルという重要な構造的サポートに注目します。この水準を下回った場合は強気シナリオが否定されます。一方で、継続して守り続けられるなら、建玉（ポジション）を積み増すのに有利です。