@BabylonLabs_io
私はボルドニアのホワイトペーパーにある「バルティ（vault）の特性」の章を読んでいたところ、ある短いフレーズが引っかかりました。それが「pre-set claimer（事前設定されたクレーマー）」です。最初は単なる技術的要件のように聞こえました。つまり、ビットコインを請求（claim）したり引き出したりできる当事者の集合は、バルティが作成された瞬間に定義されていなければならない、ということ。ですが、読み進めるほど、これは「誰がそもそも資金に触れようと試みられるのか」を根本から変えてしまう、静かな設計上の意思決定のようにも思えてきました。
興味深いのは、これによって実際に何が排除されるかです。あらかじめ定められたその集合の外にいる誰も、巧妙な証明（proof）や技術的なエクスプロイトを使ってさえ、請求を提出できません。というのも、バルティが単純に「資格あり」として認識しないからです。これは、暗号技術がまだ出てくる前の段階で、攻撃対象（attack surface）を縮小するように感じます。既存の鍵をより良いものにするのではなく、建物から余計な扉を取り除くのに近いようなイメージです。
ただし、完全にトレードオフがないとは言い切れません。クレーマー集合を作成時に固定してしまうことで、後から柔軟性がほとんど利きません。たとえば状況が変わったらどうなるでしょうか。貸し借り（lending）の関係が進化したり、後になってクレーマーの鍵（claimer key）が侵害されたりした場合は？ この「堅牢さ」を生む硬さは、安全性と引き換えに、動的な権限付与（dynamic permissioning）を許すシステムに比べて、ある程度不自由にもなり得るのでしょうか。
外から見ると、ボルドニアは「適応性（adaptability）」より「予測可能性（predictability）」を選んだように読めます。より小さく固定された攻撃対象の方が、ほとんどのユーザーがそもそも必要としない柔軟性よりも価値がある、と見込んだのだと思われます。TBVの上に、より複雑なDeFiプロダクトが積み上がっていく中で、その前提が本当に成り立つかどうかは、現時点ではまだ十分に判断できません。たぶん、これからが本当の試金石ですね…。いずれにせよ、時間が答えてくれるでしょう👍
$BROCCOLIF3B
$ON
$BABY
#baby
私はボルドニアのホワイトペーパーにある「バルティ（vault）の特性」の章を読んでいたところ、ある短いフレーズが引っかかりました。それが「pre-set claimer（事前設定されたクレーマー）」です。最初は単なる技術的要件のように聞こえました。つまり、ビットコインを請求（claim）したり引き出したりできる当事者の集合は、バルティが作成された瞬間に定義されていなければならない、ということ。ですが、読み進めるほど、これは「誰がそもそも資金に触れようと試みられるのか」を根本から変えてしまう、静かな設計上の意思決定のようにも思えてきました。
興味深いのは、これによって実際に何が排除されるかです。あらかじめ定められたその集合の外にいる誰も、巧妙な証明（proof）や技術的なエクスプロイトを使ってさえ、請求を提出できません。というのも、バルティが単純に「資格あり」として認識しないからです。これは、暗号技術がまだ出てくる前の段階で、攻撃対象（attack surface）を縮小するように感じます。既存の鍵をより良いものにするのではなく、建物から余計な扉を取り除くのに近いようなイメージです。
ただし、完全にトレードオフがないとは言い切れません。クレーマー集合を作成時に固定してしまうことで、後から柔軟性がほとんど利きません。たとえば状況が変わったらどうなるでしょうか。貸し借り（lending）の関係が進化したり、後になってクレーマーの鍵（claimer key）が侵害されたりした場合は？ この「堅牢さ」を生む硬さは、安全性と引き換えに、動的な権限付与（dynamic permissioning）を許すシステムに比べて、ある程度不自由にもなり得るのでしょうか。
外から見ると、ボルドニアは「適応性（adaptability）」より「予測可能性（predictability）」を選んだように読めます。より小さく固定された攻撃対象の方が、ほとんどのユーザーがそもそも必要としない柔軟性よりも価値がある、と見込んだのだと思われます。TBVの上に、より複雑なDeFiプロダクトが積み上がっていく中で、その前提が本当に成り立つかどうかは、現時点ではまだ十分に判断できません。たぶん、これからが本当の試金石ですね…。いずれにせよ、時間が答えてくれるでしょう👍
$BROCCOLIF3B
$ON
$BABY
#baby