Salman49

WHY 21X’S RULEBOOK MAKES DUSK MORE INTERESTING

I went into the 21X story thinking the interesting part was trading and settlement happening together. Then I started looking at the rules around that setup, and the Dusk connection became more interesting to me.

21X has its own Rulebook, Pre-Trade Controls and Default Management Policy. That tells me something important about what Dusk is actually building for @Dusk Putting a market onchain doesn't remove the rules around the market. Dusk is providing the infrastructure where those rules, trading activity and settlement can work together.

The Pre-Trade Controls are the part I keep coming back to. They check orders before execution. I like that detail because it shows where the blockchain stops being the whole story. Dusk can provide settlement and execution infrastructure, but the market still needs to decide what should be allowed through in the first place.

Then there’s the Default Management Policy. Someone failing to perform doesn't magically disappear because settlement happens onchain. There still has to be a process for dealing with that mess.

And this changes how I see the 21X connection. Dusk isn't replacing the rulebook with code. At least from what I can see, it's trying to put regulated market activity on infrastructure where execution, privacy and settlement can work closer together.

That makes me wonder about the bigger Dusk idea. Maybe the interesting part of regulated finance going onchain isn't removing all the old rules.

Maybe it's making the rules and the transaction live much closer together.

$DUSK #dusk

トークンはオンチェーンだ。だが誰がマーケットを見ている？

私は@Dusk と、NPEX＋Chainlinkの構成を見ていて、見落としやすい“何か”がある気がします。金融資産をオンチェーンにすることで所有の問題は解決できます。しかし情報の問題は解決しません。台帳はその証券の所有者が誰かは把握しています。でも、その証券がチェーンの外でいくらの価値があるのかまでは、自動では分かりません。

では、資産がオンチェーンだとしても、価格はどこか別の場所から来ています。ここでDataLinkが私にはより理にかなっています。Duskは公式のNPEX取引所データをオンチェーンに持ち込むことを意図していると言っています。役に立つのは、単に価格をスマートコントラクトに入れることではありません。資産が存在する市場への“接続”を契約に与えることです。そうしないと、ブロックチェーンが正しいとしても、間違った市場の状況（相場の絵）で動いてしまう可能性があります。

そして、ここでData Streamsが問いを変えます。市場データもオンチェーンに持ち込むのではないでしょうか？ 違いは、その情報がどれだけ速く到着する必要があるかです。Data Streamsは、低レイテンシーかつ高頻度のマーケットデータ向けに作られています。市場が先に動き、データが後から届くなら、トランザクションはプログラムどおりに実行されても、古い（staleな）情報を使ってしまいます。

CCIPはもう一つのパズルのピースを作ります。クロスチェーンの相互運用性を扱い、Cross-Chain Token標準は、バーン＆ミントのメカニズムを通じてDUSKの移動を扱います。つまり、資産はネットワーク間を移動できますが、クロスチェーン移動、価格発見、市場データを“同じ問題”だと見せかける必要はありません。

これで、私にはトークン化が以前より整然として見えなくなりました。まず証券を発行する。所有権を記録する。市場価格を取り込む。その情報を常に最新に保つ。そうしてはじめて、アプリケーションがそれに基づいて動けるようになります。

すると、トークンはもはや自分だけでやれることがそれほど多くないことが分かります。

しばらく私は、トークン化を主に“ブロックチェーンの問題”だと考えていました。しかし今は、それほど確信できていません。難しいのは、資産の金融的な意味を生み出すあらゆるものと、ブロックチェーンをつなぎ続けることかもしれません。

取引が始まって市場が動いたとき、スマートコントラクトは「あとで追いつくよ」とは言えないからです。$DUSK #dusk
$SKYAI $BNB

なぜダスクはイーサリアムの「ブロブ」アイデアを必要としているのか？

EIP-4844は、最初はなかなか見つけられなかったダスクEVMの詳細でした。イーサリアムは、データ可用性をより安くするためにブロブを導入しました。とはいえ、ダスクにはすでに決済とデータ可用性のためのDuskDSがあります。それなら、なぜこの設計をダスクに取り込むのでしょうか？

レイヤー分割が、より良い手がかりをくれます。DuskEVMはEVMの実行を担当し、DuskDSは決済とデータ可用性を担当します。つまり、ブロブにはこの場で特定の役割があります。ブロブによって、実行レイヤーがデータを扱うための標準的な方法を得られ、責任をすべてをダスクEVMに押し付ける必要がなくなるのです。

Ruskは、互換性のチェックボックスとして片づけにくくする形で、実装をより難しくしています。コミットメントまたはハッシュを通じてブロブを取得するためのブロブエンドポイントが用意されています。

Rusk Walletも、ブロブトランザクションをサポートしています。Ruskはプリコンディション（前提条件）のチェック時にもそれらを確認します。ここに私の関心が向きました。というのも、ブロブがEVMが理解する「単なる何か」ではなく、トランザクションの経路の一部になっているからです。

KZGによって、そのつながりはさらに具体的になります。EIP-4844はKZGのコミットメントと証明を使います。ダスクのツールはブロブのコミットメントを検証し、スナップショットのツールは、ブロブオブジェクトを保存する前にKZGの関係をチェックします。

つまり、部品はうまく噛み合っているようです。DuskEVMが実行を担当し、DuskDSが決済とデータ可用性を担当する。ブロブトランザクション、取得、そしてKZG検証が、それらの責任をつなぎ合わせています。

私は、EIP-4844をダスクが単に「イーサリアムに似せるため」に追加したものだとは言いません。そこには、より深いアーキテクチャ上の理由があります。

では、規制された市場を中心に独自のアーキテクチャを築こうとしているネットワークにとって、なぜこの特定のイーサリアム設計なのでしょうか？

#dusk . $DUSK @Dusk

ブロックチェーンの取引が「間違い」ではなく、単に「早すぎる」だけだったら？

私は Rusk v1.7.0 の小さな変更を見ていて、ちょっと立ち止まってしまいました。これは、将来のノンス（nonce）を伴って到着する Moonlight 取引を扱います。Rusk はそれらをただ即座に拒否するのではなく、ノンスのギャップが埋まるまで一時的にキューへ積み上げることができます。

それを考えると、「無効」と「早すぎる」の違いに思い至ります。ノードがまだ前の取引を待っている最中なら、次の取引は単にシーケンスより先に進んでいるだけかもしれません。Rusk はこのための上限付きリトライ・キューを使っています。さらに、取引が待機している間に deferred（延期）イベントも発行します。

私にとっていちばん分かりやすい比較は銀行振込です。振込の2件目が1件目より先にシステムへ届きます。私は、2件目が悪いものだと自動的に決めつけません。まず、システムが単に1件目を待っているだけなのかを知りたいのです。

そして、もうひとつ <@Dusk detail> 興味深い点があります。HTTP API は、取引が伝播（propagate）されたときに 202 Accepted を返せます。しかしそれは、すでにメンプールに入っている、あるいは確定（finalized）していることを意味しません。Dusk のドキュメントでも、ローカルの mempoolTxs 表示は、prequeue に置かれた将来ノンス取引を除外している、と述べられています。

さて、私は deferred の部分で引っかかっています。ウォレットや取引所がこのイベントを見た場合、その取引に対して実際には何をすべきでしょうか。前へ進むのを待つべきなのか、それとも別のシグナルに頼るべきなのか。

私は「様子見」する方向に傾いています。でも、その待機期間を現実の実装ではどう扱っているのかも知りたいところです。<#dusk >

<$METAB $STAR $DUSK >

なぜブロックチェーンのイベントはファイナリティと同じではないのか

以前は、取引所は主に「ブロックチェーンで取引が起きたのはいつか」を把握できればよいのだと思っていました。しかし、Duskを見てそれに疑問を持つようになりました。取引がまだ変わり得るのであれば、その出来事を最終的なお金として取引所が扱うべきかどうか、私は確信が持てません。

そこで、RUES（Rusk Universal Event System）に注目しました。Duskは特に、インフラ、インデクサ、取引所向けにRUESを挙げています。私にとって興味深いのは、イベントを受け取った後、取引所が何をするのかという点です。

Duskのトランザクションのライフサイクルは、included（取り込まれた）、executed（実行された）、confirmed（確定された）、finalized（確定的に確定された）を分けています。ドキュメントでは、executedされたトランザクションを監視し、エラーを確認し、ブロックがfinalizedされていることを確認し、ブロックがリバートされた場合は再度リッスンするように書かれています。これが重要なのは理解できます。取引所に対して早すぎる段階でクレジットすると、一時的な状態が本当の残高になってしまう可能性があるからです。

ここで宅配便の追跡を思い出します。「配達中」と表示されていれば動いているのは分かりますが、まだ「配達済み」とは言いません。もしかすると慎重すぎるのかもしれません。でも、「動いている」から「配達済み」までの、その同じギャップを取引所も必要とするのは分かります。

そして、冪等性（idempotency）の細部が、また私を立ち止まらせました。Duskは、入金スキャナに対してメモではなくDuskのトランザクションIDを冪等性キーとして使い、クレジットとブロックのチェックポイントを書き込みを原子的に行うよう指示しています。つまり、スキャナがクラッシュして同じ範囲をもう一度スキャンしても、そのトランザクションが2回目の入金として扱われるべきではないのです。

さらに今、私はRUESを少し単純に見ていたのではないかと考えています。もし取引所が、イベント、ファイナリティ、リバート、重複処理をそれぞれ別々に考える必要があるなら、ブロックチェーンが「起きた」と言った後に、実際に行われている“本当の作業”のどれだけが残っているのでしょうか。@Dusk #dusk $DUSK

透明性が金融で問題になり得る理由

暗号資産によって「透明性が正解」という感覚が広まりました。誰もが同じ活動を見られるなら、誰もが同じ記録を信頼できる――そう感じられるからです。
しかし、その論理が金融市場でも同じように機能するとは、私には思えません。

誰もが、完了前の大口注文や大きなポジション、あるいは企業の機微な動きを見ることができるなら、その情報によって他の人の行動が変わってしまいます。透明性は市場が何が起きたのかを理解する助けになりますが、見えすぎることは、動きを起こした本人をさらけ出してしまうことにもなり得ます。

だからこそ、Duskのプライバシーの考え方に注目しました。プライバシーを「すべてを隠すこと」だと単純に扱っているようには見えません。公開されるべき活動はそのまま可視のままにしつつ、機微な取引は非公開に保ち、必要があるときは認可された当事者に対して、特定の情報を共有できるようにする――そうした方針です。

Hedgerがこの考え方をさらに面白くしてくれている点にも惹かれます。Duskは、そのための機密なEVMフローを構築しており、機微な活動はプライベートに保ちながら、それでも検証可能であることを目指しています。この方向性では、すべての細部を誰にでも見せるのではなく、よりプライベートな市場活動を取り入れていくことも含まれています。

私の結論はかなりシンプルです：
良い金融市場には、必ずしもさらなる透明性は必要ないかもしれません。誰が何を見ることができるのか、より良いコントロールが必要です。

透明性は、人々が市場を検証するために役立つべきだからです。

そして、透明性がすべての参加者に対して一方的な優位性を自動的に与えてしまうべきではありません。DYOR。
@Dusk #dusk $DUSK

夕暮れには道筋が多すぎると思った。けれど、私は「単純」とは本当のところ何を意味するのかを問い直した。

ブロックチェーンのインフラを読んでいて気づいたことがある。構造が単純に見えると、私たちはそのシステムを「シンプル」だと言いがちだ。1つのチェーン、1つの実行経路、動く部品が少ない。いい響きだ。だが、私は「シンプルなのは誰にとってだ？」と考え始めた。

それが、Duskに引き込まれた理由だ。最初は、EVMの経路とネイティブの経路の両方があることが、不要な複雑さに思えた。なら、どちらか1つにすればよいのではないか？

しかし、その後Dusk独自の比較を見つけた。専用のネイティブ統合は、6〜12か月かかり、EVMデプロイと比べて最大50倍のコストになる一方で、EVMデプロイは数週間で完了できる。

それで、問題の見方が変わった。

ブロックチェーンのコストは、必ずしもブロックチェーンの中にあるとは限らない。多くはその周りにある。ウォレット、取引所、開発ツール、API、社内システムなど、技術の“中身”に誰も興味を持つ前に動かなければならない、面倒なつながりがそこにはある。

そして、私が重要だと思うのはこの部分だ。私たちはここを過小評価している。

チェーンをシンプルにすることが、外部のあらゆるシステムにとって接続をより大変にするのだとしたら、私たちは本当に複雑さを取り除いたのか？ それとも、ただ別の場所に移しただけなのか？

だから今の私は、Duskのアーキテクチャのほうがより面白く感じる。経路が2つあるからではない。むしろ、金融インフラをどう構築すべきかという、より大きな問いを投げかけてくるからだ。

もしかすると、最適なアーキテクチャとは、経路が最も少ないものではない。すでに機能しているものを作り直す人がより少ないものこそが最良なのかもしれない。

DYOR。

$DUSK
@Dusk
#dusk

トークンは代替可能かもしれない。だが、それを保持している人は代替できない。

私はオンチェーン上の規制対象資産について、ある点に何度も引っかかります。

2人が同じ証券を保有できる場合でも、同じ権利が与えられるとは限りません。

Duskの規制対象資産の設計では、適格性、アイデンティティ資格、ウォレットの紐づけ、そして譲渡チェックがワークフローに組み込まれています。だから、トークンを保有しているだけでは不十分なことがあります。受け取る側の人物も、その資産のルールを満たす必要があるかもしれません。

そして、これが私に「流動性」についての語り方を問い直させます。

通常、私はこう聞きます。

「いくらの資金が利用可能なのか？」

でも、もしかするとそれは物語の半分にすぎないのかもしれません。

より良い問いはこうではないでしょうか。

「実際にこの資産を受け取ることを許されている人は何人いるのか？」

表舞台の外で待機している資本はたくさんあるかもしれません。それでも、実際の購入者の母集団はなお小さい可能性があります。

Citadelはもう一段階追加します。参加者は、選択的開示によって、居住地、年齢層、または認定資格などの事実を証明できます。自分についてすべてを開示する必要があるわけではありません。

ここからが、私にとって面白いところです。

トークン化された金融における次の流動性問題は、十分な買い手を見つけることではないのかもしれません。

本当のところは、「実際にオーナーになることを許されている」十分な買い手を見つけることです。

@Dusk #dusk $DUSK

私は「BUY（購入）」ボタンを夕暮れの中に追いかけた。すぐに事がややこしくなった。

Dusk Tradeで「Buy」ボタンを見たとき、正直これはたぶん、ただのトークン化アセットのマーケットプレイスなんだろうと思った。

でも、あのボタンの周りで何が起きる必要があるのかを見てみた。

規制対象のアセットを買う前には、KYC（本人確認）と適格性が必要だ。私のウォレットは接続しなければならない。支払いは、そのアセットに適合していないといけない。ある情報は非公開のままでいる必要があり、一方で別の情報は発行者、取引の場、あるいは別の権限を持つ当事者に届けられる必要がある。そして、それらをすべて終えた後でも、取引はまだ決済（settle）されなければならない。Dusk Tradeはまさにこうしたワークフローを前提に設計されていて、DuskDSはその下で決済と最終性（finality）を扱う。

それで私は一度立ち止まった。

厄介なのは、トークン自体ではない。

誰だって「この証券はもうオンチェーンだ」と言える。問題が始まるのはその後だ。誰がそれを買えるのか？ 誰がそれを譲渡できるのか？ 発行者は何を見られるのか？ 支払いは実際にいつ、そのアセットと照合されるのか？

これがまた、Duskのネイティブ発行という考え方に惹かれた理由でもある。ドキュメントでは、アセットをただ古い仕組みの上に載ったトークンとして扱っていない。発行、保管（custody）、取引、決済、開示、レポーティング——その全ライフサイクルを見て、それがどれくらい実際に台帳（ledger）の周りで完結できるのかを問いかけている。

そしてDusk Tradeはまだプレローンチなので、私はこの市場をすでに使ったふりはしない。私は、彼らが作ろうとしている仕組みを見ている。

なぜなら、その小さな「Buy」ボタンの裏には、意外と大きな問いが隠れているからだ：

金融アセットのルールは、アセットそのものと一緒にオンチェーン上へ移動できるのか？

DYOR. @Dusk #dusk $DUSK

TBVのいちばん面白いアイデアは「借り入れボタン」ではない

私にとってTBVのいちばん興味深い部分は、借り入れボタンではありません。それは清算（リクイデーション）オーダーです。現在のパブリック・テストネットでは、TBVは意図的にバウチャー（vault）を小さく保ちます：最低バウチャーサイズは0.01 BTC、最大バウチャーサイズは0.4 BTC、ポジションは最大10のバウチャーを使用可能、BTC担保ファクターは78%で、ヘルスファクターが1.0を下回ると清算が開始されます。TBVは、ラップやブリッジなしでBitcoin上にBTCをロックし、Aave v4はその上に登録された最初のDeFiアプリです。

私が特に目を引かれたのは、BabylonがBTCそのものをどう構成させようとしているかです。ドキュメントでは、まず「犠牲（サクリファイス）のバウチャー」を用意し、次に「保護されたバウチャー」を用意することが推奨されています。清算が発生した場合、プロトコルはバウチャーを順番に辿り、目標のヘルスファクターを回復するために必要な最小限の量だけを差し押さえます。保護されたバウチャーは無傷のままにできます。さらに、市場環境が変われば後からバウチャーの順序を入れ替えることさえ可能です。これは、よくある「小さく動いただけで全部が終わる」タイプの担保モデルとはまったく違って感じられます。

だからTBVは、私の中では融資デモよりも大きく見えます。BTCバウチャーはpeg-inの時点で1つのアプリのために作成され、その後別のアプリへ移すことはできません。つまり担保は「借りられる」だけのものではなく、目的をもって段階付け（ステージング）されているのです。私は借り入れ画面の“どれだけBTCが使えるか”よりも、その点に何度も立ち返ってしまいます。大事なのは、BTCを使えるかどうかではなく、ポジションが間違った方向へ動き始めたときに、そのうちどれだけが生き残れるのか、ということです。DYOR。

@BabylonLabs_io #baby $BABY

なぜ“トラストレス”はそれでもプロダクトの構造次第なのか

ファンド・アドミニストレーター。

その一文で、私は足を止めました。
バビロンの構想は理解しやすいです。トラストレス・ビットコイン・ボールト（TBV）は、ビットコインをビットコインのまま維持しつつ、ラップしたり、保管を手放したりすることなく、金融アプリケーションで利用できるように設計されています。ここまでは、公式ドキュメントが明確に説明しています。

しかし、その後、計画されているGoMiningの統合に目を向けました。

発表では、機関投資家向けのユーザーがTBVを通じてBTCをロックし、それを担保に借り入れ、その借り入れ資金をGoMiningが管理するマイニング・プロダクトへ割り当てることが想定されていると述べています。また、そのビークル（仕組み）は、独立したファンド・アドミニストレーター、カストディアン、監査人を備えたGoMiningのトークン化ファンドとして構成されることが見込まれているとも書かれています。同時に、小口（リテール）向けの統合は「検討中」に留まっているともあります。

そこで私の疑問が変わりました。

TBVがトラストレスかどうかではありませんでした。ファンドがTBVとどう相互作用するのか、という点でした。

公開の発表は目標を説明していますが、完全なリテール向けのワークフローについては書かれていません。将来のリテール利用者がGoMiningアプリからTBVへどう移行するのか、またその体験が機関向けの構造と異なるのかが、公には示されていません。

おそらく、そのような詳細はリテール・プロダクトがローンチされるときに公表されるでしょう。ですが現時点では、公開ドキュメントからは私にはそれを確認できません。

セルシウスが私の習慣を一つ変えました。ファンド・アドミニストレーターやカストディアンといった言葉を見るたびに、私は報酬のセクションよりも、法的な構造を読む時間を増やします。プロトコル設計と金融商品を組み合わせた製品では、そうした書類はしばしば別の問いに答えるからです。

だから私は、より高いAPYを待っているわけではありません。

アプリの最初のタップから、最終的なBTCのボールトまでのリテール導線を説明するドキュメントを待っています。#baby $BABY @BabylonLabs_io

NFA.DYOR.

なぜBTCステーキング＋ファイナリティ・プロバイダがインフラの評判を測定可能にするのか

先週木曜にBabylonのドキュメントを開いたとき、また「BTCをステークして利回りを得る」といういつもの手口を期待していました。ところが、代わりにファイナリティ・プロバイダに話が逸れました。テストネット上で1つの委任をエンドツーエンドで追跡して、「これは受動的なステーキングではない」と気づきました。ビットコイン保有者が、インフラを運用する相手を自分で選んでいるのです。

あなたのBTCステークは、ロックした瞬間に有効化されません。MsgCreateBTCDelegationが発行され、BTCDelegationRegistryに登録され、さらに6回のBTCコンファームを待ってから、投票権の有効化の前に特定のファイナリティ・プロバイダへ紐づけられます。この紐づけはマーケティングの飾りではありません。プロトコルの状態です。照会できます。

そしてEOTSが腑に落ちました。もしFPがダブルサインしたなら、ガバナンスへの異議申し立てを行う必要はありません。プロトコルが暗号的に、その秘密鍵を抽出します。証拠です。議論ではありません。QueryFinalityProvidersはすでに公開鍵（pubkeys）、投票力、スラッシング状況を公開しています。私は「評判スコア」を探し続けましたが、Babylonは評判スコア自体を必要としていないと分かりました。記録されるのは、生の振る舞いです：稼働率、スラッシュ、委任のフロー。評判はそこから構築されます。

AWSかGCPかを選ぶような感覚です。誰もスローガンを信用しません。インシデント、稼働率、MTTRを確認するんです。Babylonは現時点ではFPを点数評価してはいませんが、Discordの意見ではなく、客観的なデータをオンチェーンに置いています。

その後、BTCの利回りにはあまり関心がなくなりました。代わりに、私のステークがどのFPに紐づくかを見始めました。公開され、検証でき、比較できるからです。これは「約束」ではなく測定できるインフラの説明責任です。$BABY not promise。

出典：Babylon Documentation 2025年11月。金融アドバイスではありません。DYOR。@BabylonLabs_io #baby $BABY

なぜバビロンは、すべてを一度に行うのではなく、検証を専門化された段階に分割するのか

私はビットコインのステーキングを理解したくて、@BabylonLabs_io docsを開きました。奇妙なことに、記憶に残ったのはステーキングではありませんでした。もっと小さな何かに引っかかってしまったのです。私はチェックポイントを追っていて、それが決して直接ビットコインに行かないことに気づきました。プロトコルのある部分から別の部分へと移動し続けていました。

最初は見落としがあるのだと思いました。なぜ1つのコンポーネントに全部やらせないのでしょうか？ しかし、見れば見るほど図が意図的に感じられました。エポック処理が先に終わります。エポックが終わるのを待ち、チェックポイントが作成される前にバリデータ集合を安定させます。ビットコインはブロックを約10分ごとにしか生成しないのですから、あらゆるプロトコルの出来事をそこに押し込むのは、どのみちあまり意味がないでしょう。

その後、チェックポイントはまた動きます。チェックポイントモジュールは、BLS署名を1つのチェックポイントにまとめます。VigilanteがそれをOP_RETURNを使ってビットコインに送ります。後になって、BTCライトクライアントはビットコインのヘッダを独立して確認します。すべてが1箇所に集まる場所があるはずだと期待し続けましたが、バビロンはそのようには機能しません。

残りのアーキテクチャに到達したときも同じことが起きました。BTCステーキングはチェックポイントの検証をしようとしていませんでした。ファイナリティプロバイダは委任を管理していませんでした。EOTSは別のステーキングモジュールではありません。どの要素も、「1つの仕事をして、その後邪魔にならないよう退く」ことに居心地よく収まっているように見えました。プロトコルは、あるコンポーネントに「すべてを知る」ことを求めません。

そして、私はついにアーキテクチャの意味がわかった気がします。別のモジュールを理解したからではなく、メインモジュールを探すのをやめたからです。どのパーツも仕事を終えるたびに、別のものが静かに引き継いでいきます。私は結局、コンポーネントそのものよりも、それらの引き継ぎに時間を費やしてしまいました。

DYOR.

#baby $BABY

なぜビットコインのタイムスタンピング + チェックポイントで「分割ファイナリティ」を2つの層に分けるのか

私はいつも、ファイナリティはシンプルだと思っていました。終わったら終わり。

しかしビットコイン・タイムスタンピング・プロトコルとチェックポイントがどのように連携するのかを読んでみると、ファイナリティに対する見方が変わりました。

どのブロックチェーンも高速な承認を望みます。ユーザーも、履歴が後から書き換わらないという確信を求めます。これら2つを1つの仕組みで両立するのは、思ったより難しいのです。

Babylon Labsは、ビットコインを速くすることを目指していません。ビットコインに別の役割を与えています。

あるエポックがFinality Providersを通じてファイナリティに到達すると、Babylon Chainは走り続けます。すると x/checkpointing モジュールがエポックのMerkle rootを作成します。ビットコイン・タイムスタンピング・プロトコルは、その暗号学的コミットメントだけをOP_RETURNでビットコインに書き込みます。ビットコインは、そのエポックのすべてのブロックや、すべてのトランザクションを必要としません。

その部分が特に興味深かったです。

もし各ステップでビットコインを待たなければならないなら、接続された各チェーンは遅くなります。Babylonは、ネットワーク側を先に進めることでこれを回避します。ビットコインは、後で完成したチェックポイントをアンカーするために使われます。

私にとって、この設計の本質はここです。
チェックポイントは、単にビットコインのブロックスペースを節約するためのものではありません。ビットコインを「いつ関与させるか」を決めることが目的です。迅速な調整はBabylon Chainで行われ、ビットコインは作業がすでに終わった後に、その記録を保護します。

だから私は、ビットコイン・タイムスタンピング・プロトコルとチェックポイントは、単にファイナリティを改善するだけでなく、多くのブロックチェーンが同じプロセスで両立しようとしている2つの異なる仕事を分離しているのだと思います。

DYOR。

#baby $BABY @BabylonLabs_io

誰も準備できていない「ビットコイン保護」争い

私は、あることを理解したくてBabylonのドキュメントを開きました。

「ビットコイン保護」とは実際どういう意味なのでしょうか？

答えは思ったよりシンプルでした。ビットコインはネットワークを守るのに役立ちます。チェーンは、引き続き独自のコード、アプリ、アップグレードを動かします。これは別の仕事です。

そして、もう一つ疑問が浮かびました。

ビットコインの裏付けセキュリティを使っているチェーンがハッキングされたら、評判のダメージを受けるのは誰でしょう？

そのチェーン？

それともビットコイン？

ここがややこしくなるところだと思います。

次のような最初の見出しを想像してみてください。

「ビットコイン保護チェーンがハッキングされた」

多くの人は記事を開かないでしょう。問題がスマートコントラクト由来なのか、チェーン自身のコードなのか、あるいはビットコインの裏付けによるセキュリティ層の問題なのかを確認もしないはずです。覚えるのはたった2つの言葉になるでしょう——「ビットコイン」と「ハッキング」です。

だから私は、最大の課題は技術ではないと思っています。

それは、この2つの言葉の意味です。

ドキュメントでは、ビットコインがネットワークをどのように守るのかが説明されています。ビットコインがあらゆるバグを直したり、開発者がその上に何を構築するかを制御したりするとまでは書かれていません。

それらは別のことです。

技術は、設計どおりに機能し得ます。それでも、見出しがまったく別の物語を語ってしまうことはあり得ます。

たぶん私は先のことを考えすぎているのかもしれません。

でも暗号資産の世界は、コードについてだけ議論してきたことはありません。

私たちは何年も、「本物のビットコイン」「レイヤー2」「分散化」といった言葉をめぐって口論してきました。

「ビットコイン保護」が次にそうなるとしても、驚きません。_DYOR.

#baby $BABY @BabylonLabs_io

罰金を払ったとき誰が儲かる？バビロンは「誰も儲からない」と言う

先週、₹500のチャラン（罰金告知）を切られました。赤信号を無視しました。お金は政府へ行きます。

その後、銀行が₹400を1日分の延滞EMI（元本返済付き利払い）として取っていきました。支払期限は小さな文字で隠されていました。私のミスが彼らの利益になったのです。

その日、私はあることに気づきました。もし誰かが私のミスから稼いでいるなら、彼らは二度とそれを避ける助けはしてくれません。

そこで、私はバビロンを使い始めました。バビロンでは、ビットコインをステークして、他のブロックチェーンのセキュリティを支えることができます。ルールを守れば報酬が得られます。

では、ルールを破ったらどうなるのでしょう？バビロンには「スラッシング（削減）」と呼ばれるペナルティがあります。

バビロンのドキュメントによると、バリデータが不正をした場合、ステークしていたビットコインが削減される（スラッシュされる）とのことです。スラッシュされたビットコインは焼却されます。ドキュメントは明確です。ビットコインはバビロンのチームに行きません。ほかのユーザーにも行きません。永遠に消えます。

これが重要な違いです。

私の交通違反のチャランでは、政府が儲かります。私の銀行では、銀行が儲かります。だから、私が失敗したときに彼らは得をします。

バビロンでは、ペナルティによって誰も儲かりません。ビットコインは破壊されます。だから、ルールの目的はお金を稼ぐためではなく、システムを安全に保つためです。

罰に勝者がいないシステムは、信頼の上に築かれたシステムです。

そこで私は、どのアプリやサービスを使う前にもこう問いかけます。「私がミスをしたら、そのお金を誰が受け取るの？」

答えが「会社」なら、私は信頼しません。

答えが「誰もいない」、バビロンのように、ならルールはきれいだとわかります。#baby $BABY @BabylonLabs_io

私のBTC、私のルール：その5Bドル規模のアンステーキングがそれを証明した

ちょうどBabylonを確認していたところ、14,929 BTCがアンボンディング（非ステーキング）に入っているのを見つけました。あのBTCは実際にはどうやって戻ってくるのか知りたかったのです。

Lombardは新しい最終性提供者（Finality Providers）へ移行しており、BabylonのTVLは$3.97Bから$2.68Bに減っていました。TVLを見て判断する代わりに、ドキュメントを開いて出金手順を確認しました。

ドキュメントによると、BTCは約301のビットコインブロック後、つまりおよそ2日で支出可能になるそうです。Lombardも、BTCはアンボンディング後にのみ新しいプロバイダーへ移動すると述べていました。

次に、スラッシング（没収）のルールを確認しました。プロバイダーが別のプロバイダーへ移っただけではスラッシングされません。スラッシングが起きるのは、同じ高さで2つの異なるブロックに署名した場合だけです。実際にどれかのBTCが焼却（burn）されたのかどうかを確かめたくて、移行（migration）をもう一度見直しました。焼却された形跡は見つかりませんでした。

Babylonにはいまも68,500+ BTCがステークされています。そしてLombardとSolvがその約85%をまだ保有しています。

DYOR。

#baby $BABY @BabylonLabs_io

私はビットコインの共有をやめた

借り入れの仕組みは理解しやすかった。

私はそこに多くの時間を使わなかった。

別の章のたった一文が、代わりに私を引き戻してきた。それは、ビットコインで自分が何をできるのかを説明するものではない。バビロンが、何より先に起きる前提としてそれをどう扱うことを拒否しているのかを説明していた。

文面は平凡に見えた。

「あなたのビットコインは、他人のものと混ざりません。」

私はそれを読んで先へ進み、そしてまた戻ってきた。すべてのユーザーのビットコインを分けることがより多くの作業を生むのなら、それには理由があるはずだ。誰も、見返りなしにシステムを難しくはしない。

ドキュメントは、その疑問に1段落で答えていない。答えているのはアーキテクチャによってだ。すべてのユーザーに、それぞれ別のTaproot（タップルート）保管庫（ボルト）が用意される。裏で共有残高を待機させることはない。

そして、規模の話がその判断の見え方を変え始めた。

56,853 BTC はすでにこの保管庫アーキテクチャの中に収まっている。これは構想ではなく稼働中のシステムだ。同じ頃、a16zは Trustless Bitcoin Vaults を作るために 1,500万ドルを投じた。これらの数字は、設計が正しいと私に教えてくれるわけではない。

設計が、もう一度見直されるべきだと告げている。

そこで私は、最初のところに戻った。

もしそれが借り入れの話だけなら、大きな保管庫ひとつのほうが、もっと簡単に説明できたはずだ。バビロンはその道を選ばなかった。ローンや流動性、その他何かを語る前に、すべてのユーザーのビットコインを分けておくことを選んだ。

私はそれを、保管庫の機能として見なくなった。

その後に続くすべてが、その1つの決定の結果のように見え始めた。@BabylonLabs_io #baby $BABY

バビロンはステーキング・プロトコルを構築しているわけではありません。ビットコインのセキュリティのための市場を構築しているのです。

多くの人はバビロンをビットコインのステーキング・プロトコルだと説明しますが、アーキテクチャを見ていくと、ステーキングが主な話ではないと感じました。

ステーキングは仕組みですが、ゴールではありません。

より大きな構想は、ビットコインを経済的セキュリティへと変え、BTCがビットコイン本体から一度も出ることなく、外部ネットワークがそれを利用できるようにすることです。

ユーザーにBTCをブリッジしたりラップしたりすることを求める代わりに、バビロンはビットコインをネイティブのチェーンに保持したまま、BSNがその経済的セキュリティを継承できるようにします。BTC保有者がセキュリティを供給し、Finality Providersがそれを調整し、BSNがそれを消費します。

この時点で、システムは従来型のステーキング・プロトコルというより、セキュリティ配分のための市場に似てきます。

より面白いのは、バビロンの設計が単純なBTC利回りの生成を超えていることです。より多くのBSNが統合されるにつれ、同じビットコインのステークが、マルチステーキングによって複数のネットワークを最終的に支えることができるようになり、BTCをオンチェーンから移動させることなく追加の報酬ストリームが生まれます。

そのモデルがスケールすれば、ビットコインは休眠中の担保のように振る舞うのをやめ、再利用可能な共有セキュリティとして振る舞い始めます。

それが、多くの人が見落としている部分です。

バビロンを「セキュリティ・マーケットプレイス」と呼ぶのは、公式なプロトコル言語というよりは解釈です。しかし、アーキテクチャはますますその枠組みを支持しています。つまり、バビロン・ジェネシスを通じて、セキュリティ提供者、オペレーター、消費者が分離された形で連携するのです。

この一連の主張は、BSNが実際に規模に応じたビットコイン連動のセキュリティを求めるのかどうかにかかっています。意味のある採用がなければ、そのアーキテクチャは経済的というより、より理論的なままです。

しかし採用が到来すれば、バビロンは最終的に、ステーキング・プロトコルというよりも、より広い暗号経済のためにビットコインを共有セキュリティ基盤へと変えたシステムとして記憶されることになるかもしれません。

出典：The Babylon Thesis 出典：Bitcoin Staking 出典：What is Bitcoin Staking 出典：Babylon: A Game-Changing Approach to Scaling Bitcoin

#baby $BABY @BabylonLabs_io