#baby $BABY バビロンの「信頼不要のビットコイン・ボルト(Vault)」ドキュメントを読んでいて何度も立ち返った点:ボルトを作ることと、利用可能な担保を用意することは同じマイルストーンではない。システムは意図的に両者を切り離している。
どういうふうに進むかというと— $BTC が最初にロックされ、そのロックはボルト自身のルールだけで完全に統治される。検証が完了して初めて、そのロックされたBTCがアクティブな担保へと移行する。別々の状態、別々のタイミングであって、1つの結合作業ではない。
実際、その点は安心できる。つまり、プロトコルが「担保が実際に検証されているかどうか」以前に担保として使える前提を置くことがないからだ。ただし、その分、借入段階に到達する前に、ユーザーが慣れる必要のある追加のレイヤーが生まれる。
明確なトレードオフだ—シンプルさは減り、その代わりプロトコルに明示的な前提が織り込まれている。
問題は、その「ボルト作成」と「担保のアクティブ化」の間にある追加の境界が不要なオーバーヘッドなのか、それともストレス下でもモデルがより確実に成立するようにするためにまさに必要なものなのか、ということだ。
#baby @BabylonLabs_io $BABY
どういうふうに進むかというと— $BTC が最初にロックされ、そのロックはボルト自身のルールだけで完全に統治される。検証が完了して初めて、そのロックされたBTCがアクティブな担保へと移行する。別々の状態、別々のタイミングであって、1つの結合作業ではない。
実際、その点は安心できる。つまり、プロトコルが「担保が実際に検証されているかどうか」以前に担保として使える前提を置くことがないからだ。ただし、その分、借入段階に到達する前に、ユーザーが慣れる必要のある追加のレイヤーが生まれる。
明確なトレードオフだ—シンプルさは減り、その代わりプロトコルに明示的な前提が織り込まれている。
問題は、その「ボルト作成」と「担保のアクティブ化」の間にある追加の境界が不要なオーバーヘッドなのか、それともストレス下でもモデルがより確実に成立するようにするためにまさに必要なものなのか、ということだ。
#baby @BabylonLabs_io $BABY