私は相手が消えるまでそれを「セルフカストディ」とは呼びません。
すべてが正常に動いている間は、ほぼどんな仕組みも信頼できます。
本当の試練は、オペレーターが返信をやめたときに始まります。
そのため、BabylonのTBV設計の中で、借入の見出しよりも私が重視するのは「預託者の自己主張(セルフクレーム)経路」です。
通常の終了手続きでは、私は債務を返済し、担保を引き出し、そしてVault Providerがビットコインの請求を実行します。
しかし、そのプロバイダーがオフラインになったり、処理を遅らせたり、単に行動を拒否したらどうなるでしょうか?
Babylonは、Vaultが作成されるときに別の退出ルートを用意します。
Vault固有のWOTS鍵とクレイマー(claimer)アーティファクトを使い、預託者はプロトコルのウォッチタワー機能を通じてビットコインの請求を開始できます。チャレンジ期間の後、BTCはVault作成時にコミットされたアドレスへ戻せます。
利用できないプロバイダーとの協力は不要です。
ですが、ここには気の重い責任があります。
このフォールバックは、私がそれらの回復ファイルを確実に保全できている場合に限り私を守ります。失ってしまえば、「セルフカストディ」は、最も必要なときにまさに大きく弱くなります。
それが、この設計を面白くしている理由です。
Babylonは、すべてのオペレーターが永遠に利用可能であり続けるとは前提にしません。BTCがVaultに入る前に、失敗に備えます。
私の結論:
信頼できるVaultとは、完璧な稼働率を約束するものではありません。
稼働が消えても、なお信頼できる形で私が退出できるものです。
@BabylonLabs_io $BABY $BLESS $HOME #baby
すべてが正常に動いている間は、ほぼどんな仕組みも信頼できます。
本当の試練は、オペレーターが返信をやめたときに始まります。
そのため、BabylonのTBV設計の中で、借入の見出しよりも私が重視するのは「預託者の自己主張(セルフクレーム)経路」です。
通常の終了手続きでは、私は債務を返済し、担保を引き出し、そしてVault Providerがビットコインの請求を実行します。
しかし、そのプロバイダーがオフラインになったり、処理を遅らせたり、単に行動を拒否したらどうなるでしょうか?
Babylonは、Vaultが作成されるときに別の退出ルートを用意します。
Vault固有のWOTS鍵とクレイマー(claimer)アーティファクトを使い、預託者はプロトコルのウォッチタワー機能を通じてビットコインの請求を開始できます。チャレンジ期間の後、BTCはVault作成時にコミットされたアドレスへ戻せます。
利用できないプロバイダーとの協力は不要です。
ですが、ここには気の重い責任があります。
このフォールバックは、私がそれらの回復ファイルを確実に保全できている場合に限り私を守ります。失ってしまえば、「セルフカストディ」は、最も必要なときにまさに大きく弱くなります。
それが、この設計を面白くしている理由です。
Babylonは、すべてのオペレーターが永遠に利用可能であり続けるとは前提にしません。BTCがVaultに入る前に、失敗に備えます。
私の結論:
信頼できるVaultとは、完璧な稼働率を約束するものではありません。
稼働が消えても、なお信頼できる形で私が退出できるものです。
@BabylonLabs_io $BABY $BLESS $HOME #baby