$SUI ピーク時TPS説明システムは最大どれくらいのアクションを処理できるのか――ユーザーがより気にしているもう一つの点は、預けたBTCは一体どうすれば取り戻せるのか、ということです。前回はHashiの資金調達目的と資本コミットメントについて話しましたが、今回は設計ドキュメントに沿って、退出（リクエスト後に資産を引き出す）ルートを確認します。読んだ後、私は「BTCをビットコイン・ネットワークに置いておけば、ユーザーがいつでも自由に単独で転送できる」とは直接は理解しません。
新しく重要なのは、資産がどのチェーン上にあるか、誰が支出を承認できるか――これらは同じ問題ではない、という点です。HashiのUser Flowsによれば、ユーザーがBTCを専用のビットコインアドレスに預けると、確認後にSui側でhBTCを受け取ります。通常の支出は2-of-2構造で行われ、片方はHashiのMPC委員会、もう片方はGuardianです。MPCは複数者で協調して署名を完成させ、Guardianが第二段のチェックを提供します。ユーザーが出金リクエストを出したからといって、協定（プロトコル）を回避してBTCを直接転送できる“鍵”を保持しているわけではありません。
このチェックの価値は、脆弱性や悪意ある挙動などの異常時に、資産放出を制約できることです。ただし、安全設計は退出（出金）の速度にも影響します。Limiterドキュメントには、出金には最大容量と継続的に補充される上限額があり、容量が不足すると待つ必要があること、単一リクエストが最大容量を超えるとスキップされ、限度が引き上げられるまで待つこと、またユーザーもルールに従ってリクエストをキャンセルできることが明記されています。通常は先入れ先出しで処理されますが、厳密に保証されるわけではありません。つまり1回の出金で待ち時間が長くなる可能性があり、ただ列に並んでいるだけだから資金が盗まれないと断言できるわけでも、システムに防護があるから即時入金が保証されるわけでもありません。必要なのは、限度（キャパシティ）設定、キュー（待機列）、そして実際の実行状況を一緒に見ることです。
さらに、別途きちんと説明しておくべき“回復（リカバリー）”ルートがあります。Address Schemeドキュメントによれば、通常の支出以外に、スクリプトではMPC委員会がUTXO確認後、60日間の相対時間ロックを経て、単独で追加支出できるようになっています。ここでのUTXOは、まだ消費されていないオンチェーン出力（未使用の出力）と考えられます。この設計は、Guardian鍵の紛失などの状況に備えるための別の回復経路として機能し、計時の開始点はユーザーが出金申請を行った時ではなく、その出力の確認時点です。また、この回復権が各ユーザーに個別に渡されるわけでもありませんし、「すべての出金は最大60日待つ」というサービス保証でもありません。
したがって、私はHashiが約束を果たしているかを、どれだけBTCを預けられるかだけで判断しません。通常の出金がスムーズか、レート制限（リミット）のパラメータがどのように公開されているか、そしてGuardianが機能しない場合の回復と委員会間の引き継ぎがどう検証されるのか――これらも含めて見ます。安全チェックがもう一つ“門”を増やすのか、それともユーザーが単独の完全なコントロール権を保持するのか、これは別種の設計です。適しているかどうかは、これらの退出条件も一緒に織り込んで判断する必要があります。
今回の内容は、現在公開されている設計ドキュメントに基づきます。ページは引き続きTestnetと表示されており、それをもってメインネットが同じパラメータで全面的に稼働していると主張することはできません。10月8日の公告では今月分の段階的なリリースだとされており、今後は実際のデプロイと、実際の退出（出金）記録を用いて改めて検証し直す必要があります。4060万TPSのデモ表示や、5億ドル超の資本コミットメントは、このステップの代わりにはなりません。現時点で追加で見るべき判断は次の通りです。Hashiの価値検証は、「ビジネスとして資金を受け入れられるか」だけでなく、「資産が通常時および異常時に、ルール通りに送り出せるか」も見る必要がある、ということです。出典：Mysten Labs HashiのUser Flows、Guardian、Limiter、Address Scheme；図版は仕組みのイメージ。
新しく重要なのは、資産がどのチェーン上にあるか、誰が支出を承認できるか――これらは同じ問題ではない、という点です。HashiのUser Flowsによれば、ユーザーがBTCを専用のビットコインアドレスに預けると、確認後にSui側でhBTCを受け取ります。通常の支出は2-of-2構造で行われ、片方はHashiのMPC委員会、もう片方はGuardianです。MPCは複数者で協調して署名を完成させ、Guardianが第二段のチェックを提供します。ユーザーが出金リクエストを出したからといって、協定（プロトコル）を回避してBTCを直接転送できる“鍵”を保持しているわけではありません。
このチェックの価値は、脆弱性や悪意ある挙動などの異常時に、資産放出を制約できることです。ただし、安全設計は退出（出金）の速度にも影響します。Limiterドキュメントには、出金には最大容量と継続的に補充される上限額があり、容量が不足すると待つ必要があること、単一リクエストが最大容量を超えるとスキップされ、限度が引き上げられるまで待つこと、またユーザーもルールに従ってリクエストをキャンセルできることが明記されています。通常は先入れ先出しで処理されますが、厳密に保証されるわけではありません。つまり1回の出金で待ち時間が長くなる可能性があり、ただ列に並んでいるだけだから資金が盗まれないと断言できるわけでも、システムに防護があるから即時入金が保証されるわけでもありません。必要なのは、限度（キャパシティ）設定、キュー（待機列）、そして実際の実行状況を一緒に見ることです。
さらに、別途きちんと説明しておくべき“回復（リカバリー）”ルートがあります。Address Schemeドキュメントによれば、通常の支出以外に、スクリプトではMPC委員会がUTXO確認後、60日間の相対時間ロックを経て、単独で追加支出できるようになっています。ここでのUTXOは、まだ消費されていないオンチェーン出力（未使用の出力）と考えられます。この設計は、Guardian鍵の紛失などの状況に備えるための別の回復経路として機能し、計時の開始点はユーザーが出金申請を行った時ではなく、その出力の確認時点です。また、この回復権が各ユーザーに個別に渡されるわけでもありませんし、「すべての出金は最大60日待つ」というサービス保証でもありません。
したがって、私はHashiが約束を果たしているかを、どれだけBTCを預けられるかだけで判断しません。通常の出金がスムーズか、レート制限（リミット）のパラメータがどのように公開されているか、そしてGuardianが機能しない場合の回復と委員会間の引き継ぎがどう検証されるのか――これらも含めて見ます。安全チェックがもう一つ“門”を増やすのか、それともユーザーが単独の完全なコントロール権を保持するのか、これは別種の設計です。適しているかどうかは、これらの退出条件も一緒に織り込んで判断する必要があります。
今回の内容は、現在公開されている設計ドキュメントに基づきます。ページは引き続きTestnetと表示されており、それをもってメインネットが同じパラメータで全面的に稼働していると主張することはできません。10月8日の公告では今月分の段階的なリリースだとされており、今後は実際のデプロイと、実際の退出（出金）記録を用いて改めて検証し直す必要があります。4060万TPSのデモ表示や、5億ドル超の資本コミットメントは、このステップの代わりにはなりません。現時点で追加で見るべき判断は次の通りです。Hashiの価値検証は、「ビジネスとして資金を受け入れられるか」だけでなく、「資産が通常時および異常時に、ルール通りに送り出せるか」も見る必要がある、ということです。出典：Mysten Labs HashiのUser Flows、Guardian、Limiter、Address Scheme；図版は仕組みのイメージ。